-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flatcar-install: Remove unnecessary --trusted-key gpg option #123
Conversation
We expect users to run flatcar-install from different distros, and there are also systems that use a fixed version of Flatcar stable with PXE boot and then run the latest flatcar-install from there. So we can't make this kind of change :( |
Ah, fair enough. I realised towards the end that flatcar-install creates a temporary home directory for gpg, so there shouldn't be any other keys present anyway. I'll just remove |
Using a custom key was recently broken by a GnuPG update. The Flatcar key is not imported when a custom key is given, but we still reference the Flatcar key with --trusted-key regardless, causing gpg to attempt to download the key from a keyserver. This fails because we no longer ship the necessary dirmngr binary, which is now only built when GnuPG has GnuTLS support enabled. Enabling GnuTLS support works around the problem, but it is not the proper fix. --trusted-key causes gpg to trust the given key, even though there is no secret key present. This is unnecessary, as the key would be trusted anyway, albeit with a warning. Using --assert-signer would be safer, as this ensures the file was signed specifically by the given key rather than some other key you happen to have in your keyring. It is not present in older GnuPG versions that we need to support though, and flatcar-install creates a temporary home for gpg, so no other keys would be present anyway. Closes: flatcar/Flatcar#1471 Signed-off-by: James Le Cuirot <[email protected]>
Okay, I've reworked this to simply remove |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The assert signer flag probably could be gated by detecting if gnupg is new enough. But this could be done as a follow-up if you want.
It wouldn't add much, to be honest. It would be different if we didn't start with an empty keyring. |
flatcar-install: Remove unnecessary --trusted-key gpg option
Using a custom key was recently broken by a GnuPG update. The Flatcar key is not imported when a custom key is given, but we still reference the Flatcar key with
--trusted-key
regardless, causing gpg to attempt to download the key from a keyserver. This fails because we no longer ship the necessary dirmngr binary, which is now only built when GnuPG has GnuTLS support enabled.Enabling GnuTLS support works around the problem, but it is not the proper fix.
--trusted-key
causes gpg to trust the given key, even though there is no secret key present. This is unnecessary, as the key would be trusted anyway, albeit with a warning.Using
--assert-signer
would be safer, as this ensures the file was signed specifically by the given key rather than some other key you happen to have in your keyring. It is not present in older GnuPG versions that we need to support though, and flatcar-install creates a temporary home for gpg, so no other keys would be present anyway.Closes: flatcar/Flatcar#1471
How to use
Use flatcar-install as normal, with and without a custom key. For testing a custom key, you can sign any old blob of data and host it somewhere.
You will see the following output.
Testing done
I tested this under QEMU using the current beta release. For simplicity, I installed to a dummy file.
I also tested using my own key.
changelog/
directory (user-facing change, bug fix, security fix, update)/boot
and/usr
size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.