Skip to content
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

Merged
merged 1 commit into from
Jun 25, 2024

Conversation

chewi
Copy link
Contributor

@chewi chewi commented Jun 21, 2024

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.

Current version of Flatcar Container Linux stable is 3815.2.3
Downloading the signature for https://stable.release.flatcar-linux.net/amd64-usr/3815.2.3/flatcar_production_image.bin.bz2...
2024-06-21 10:07:35 URL:https://stable.release.flatcar-linux.net/amd64-usr/3815.2.3/flatcar_production_image.bin.bz2.sig [594/594] -> "/tmp/flatcar-install.R2nQpYRQ5A/flatcar_production_image.bin.bz2.sig" [1]
Downloading, writing and verifying flatcar_production_image.bin.bz2...
2024-06-21 10:08:33 URL:https://stable.release.flatcar-linux.net/amd64-usr/3815.2.3/flatcar_production_image.bin.bz2 [467667717/467667717] -> "-" [1]
gpg: Signature made Tue May 21 11:39:55 2024 UTC
gpg:                using RSA key E9426D8B67E35DF476BD048185F7C8868837E271
gpg:                issuer "[email protected]"
gpg: Good signature from "Flatcar Buildbot (Official Builds) <[email protected]>" [unknown]
gpg: WARNING: The key's User ID is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F88C FEDE FF29 A5B4 D952  3864 E25D 9AED 0593 B34A
     Subkey fingerprint: E942 6D8B 67E3 5DF4 76BD  0481 85F7 C886 8837 E27

Testing done

I tested this under QEMU using the current beta release. For simplicity, I installed to a dummy file.

fallocate -l 4G test.img
sudo losetup -f test.img
sudo ./flatcar-install -C stable -d /dev/loop6

I also tested using my own key.
 

  • Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
  • Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

@chewi chewi requested a review from a team June 21, 2024 10:12
@jepio
Copy link
Member

jepio commented Jun 21, 2024

IMPORTANT! The --assert-signer is only supported from GnuPG 2.4.1, which we have in our alpha and beta releases, but not yet in stable.

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 :(

@chewi
Copy link
Contributor Author

chewi commented Jun 21, 2024

IMPORTANT! The --assert-signer is only supported from GnuPG 2.4.1, which we have in our alpha and beta releases, but not yet in stable.

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 --trusted-key instead of replacing it.

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]>
@chewi chewi force-pushed the chewi/custom-key branch from 24cdd55 to c55eca1 Compare June 21, 2024 14:18
@chewi chewi changed the title flatcar-install: Use --assert-signer rather than --trusted-key with gpg flatcar-install: Remove unnecessary --trusted-key gpg option Jun 21, 2024
@chewi
Copy link
Contributor Author

chewi commented Jun 21, 2024

Okay, I've reworked this to simply remove --trusted-key and tested it as before. I also manually tested GnuPG 2.0.22 from CentOS 7 to check the exit statuses in that version.

Copy link
Member

@krnowak krnowak left a 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.

@chewi
Copy link
Contributor Author

chewi commented Jun 25, 2024

It wouldn't add much, to be honest. It would be different if we didn't start with an empty keyring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

custom signing key for images does not work gnupg 2.4 / flatcar beta
3 participants