flatcar / Flatcar

Flatcar project repository for issue tracking, project documentation, etc.
https://www.flatcar.org/
Apache License 2.0
653 stars 27 forks source link

custom signing key for images does not work gnupg 2.4 / flatcar beta #1471

Closed juliantaylor closed 6 days ago

juliantaylor commented 2 weeks ago

Description

since 3913.1.0 in the beta channel gnupg 2.4 is used, this seems to break usage of custom signing keys due to dirmngr not being present in the installer image and the installer using hardcoded key in the --trusted-key argument despite running flatcar-install -k customkey

Impact

self signed images cannot be installed

Environment and steps to reproduce

gnupg 2.4 on flatcar 3941.1.0

# gpg --version
gpg (GnuPG) 2.4.4
libgcrypt 1.10.3-unknown
Copyright (C) 2024 g10 Code GmbH

gpg --import Flatcar_Image_Signing_Key.asc 
gpg: directory '/root/.gnupg' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key C99502A9B080DAF6: public key "testt" imported
gpg: Total number processed: 1
gpg:               imported: 1

# some arbitrary trusted key that does not exist locally (hardcoded in flatcar installer)
# gpg --dirmngr-program /doesnotexist --batch --trusted-key 06B7853EF0C91158 --verify flatcar_production_image.bin.bz2.sig flatcar_production_image.bin.bz2 && echo SUCCESS
gpg: Signature made Fri Jun 14 13:58:05 2024 UTC
gpg:                using RSA key 6B7853EF0C91158A4A9401B8C99502A9B080DAF6
gpg: error running '/doesnotexist': probably not installed
gpg: failed to start dirmngr '/doesnotexist': Configuration error
gpg: can't connect to the dirmngr: Configuration error
gpg: key 06B7853EF0C91158: no public key for trusted key - skipped
gpg: key 06B7853EF0C91158 marked as ultimately trusted
gpg: Good signature from "testt" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6B78 53EF 0C91 158A 4A94  01B8 C995 02A9 B080 DAF6

verification failed here despite gpg: Good signature from "testt" [unknown], it exited with code 2

in comparison on flatcar 3874.1.0:

# gpg --version
gpg (GnuPG) 2.2.35
libgcrypt 1.10.2-unknown

# gpg --import Flatcar_Image_Signing_Key.asc
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key C99502A9B080DAF6: public key "testt" imported
gpg: Total number processed: 1
gpg:               imported: 1

# gpg --dirmngr-program /doesnotexist --batch --trusted-key 06B7853EF0C91158 --verify flatcar_production_image.bin.bz2.sig flatcar_production_image.bin.bz2 && echo SUCCESS
gpg: Signature made Fri Jun 14 13:58:05 2024 UTC
gpg:                using RSA key 6B7853EF0C91158A4A9401B8C99502A9B080DAF6
gpg: key 06B7853EF0C91158: no public key for trusted key - skipped
gpg: key 06B7853EF0C91158 marked as ultimately trusted
gpg: Good signature from "testt" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6B78 53EF 0C91 158A 4A94  01B8 C995 02A9 B080 DAF6
SUCCESS

verification succeeded

Expected behavior

self signed images can be installed with verification

If we could override the --trusted-key in the flatcar installer gnugpg would not try to invoke dirmngr and it would work but the trusted key is hardcoded in the installer.

chewi commented 2 weeks ago

I can't comment on overriding the trusted key, but dirmngr is missing because gnupg has been built with USE="-ssl" due to the ssl flag being masked against this package. The reason given in the package.use.mask file is that Flatcar doesn't ship with gnutls by default, but I don't think that's true anymore. I can see libgnutls.so on my test VM.

juliantaylor commented 1 week ago

thanks, removing the masking of ssl in sdk_container/src/third_party/coreos-overlay/profiles/coreos/base/package.use.mask and thus having dirmngr installed allows self signed images to install again.

chewi commented 1 week ago

I may make that change, but it's not the proper fix here. I understand the issue now and am discussing the solution. We probably want --assert-signer rather than --trusted-key and it obviously needs to be adjusted for custom keys.