flatcar-install: Remove unnecessary --trusted-key gpg option#123
flatcar-install: Remove unnecessary --trusted-key gpg option#123chewi merged 1 commit intoflatcar-masterfrom
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 <jlecuirot@microsoft.com>
|
Okay, I've reworked this to simply remove |
krnowak
left a comment
There was a problem hiding this comment.
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-keyregardless, 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-keycauses 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-signerwould 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)/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.