Skip to content

Conversation

@mtrmac
Copy link
Collaborator

@mtrmac mtrmac commented Jul 21, 2025

This is on top of #2876 , adding a test that a signature using a Sequoia-PGP key generated using the default options is accepted using any mechanism.

Right now that fails:

  • with gpgme: []string{"50DDE898DF4E48755C8C2B7AF6F908B6FA48A229"} does not contain AC99AAF67A588DF381A6A95C7ADD16BD41D829B6" (signature using a subkey)
  • with openpgp: openpgp: unsupported feature: public key type: 22 (EdDSA signature)

This adds a new OpenPGP signing mechanism based Sequoia-PGP[1]. As
Sequoia-PGP is written in Rust and doesn't provide a stable C FFI,
this integration includes a minimal shared library as a "point
solution".

To build, first follow the instruction in signature/sequoia/README.md
and install `libimage_sequoia.so*` into the library path, and then
build with the following command from the top-level directory:

  $ make BUILDTAGS="btrfs_noversion containers_image_sequoia"

Note also that, for testing on Fedora, crypto-policies settings might
need to be modified to explictly allow SHA-1 and 1024 bit RSA, as the
testing keys in signature/fixtures are using those legacy algorithms.

1. https://sequoia-pgp.org/

Signed-off-by: Daiki Ueno <[email protected]>
@mtrmac mtrmac force-pushed the sequoia-interop branch 5 times, most recently from b58084d to 7c7ecdc Compare July 25, 2025 20:24
@mtrmac mtrmac force-pushed the sequoia-interop branch 2 times, most recently from 9af15eb to 6908aaf Compare August 7, 2025 18:39
mtrmac added 22 commits August 7, 2025 21:54
Encapsulate the wanted/recorded tuples a bit more, to prepare for
changes to the signatureAcceptanceRules type.

Should not change (test) behavior.

Signed-off-by: Miloslav Trmač <[email protected]>
…ryKeyFingerprints

Move more code into the centralized function, to allow us to change
the implementation in the future.

Signed-off-by: Miloslav Trmač <[email protected]>
Document how the key identities from NewEphemeralGPGSigningMechanism
and SigningMechanism should relate.

For the GPGME implementation where the relationship isn't as desired, introduce
signingMechanismWithVerificationIdentityLookup .

For the openpgp implementation, just fix the returned value to match
new expecations.

Currently, the simple signing verifyAndExtractSignature rejects
subkey signatures for both mechanism implementations, so this does not
change behavior for any previously-accepted signatures (but it might
affect theoretical external direct callers of SigningMechanism).

We will actually use this in the next commit.

WARNING: Adding support for subkeys makes subkey revocation relevant.
Revocation is always messy - to support long-term signature validity
(which is very relevant for container image signing), smooth
handling of revocation might require trusted timestamps (not natively
supported in OpenPGP).

In practice, this library (partially out of necessity) lets the underlying
OpenPGP implementations impose their own policy, and that handling DIFFERS
between various SigningMechanism implementations: it seems that GnuPG
and refuses to use a revoked subkey regardless of revocation time, while
Sequoia-PGP decides based on the revocation reason whether the revocation
applies to all signatures or only to signatures (supposedly!!) made after the
revocation happened.

It is STRONGLY recommended to avoid all of this complexity, and to plan
for workflows where subkey revocation never happens. Just revoke and reissue
the whole key - either way you'll need to distribute an updated key to all
consumers.

Signed-off-by: Miloslav Trmač <[email protected]>
This does not change behavior for mechanisms which already always return the
primary key fingerprint (after a recent change, openpgp); for the others,
add support for signingMechanismWithVerificationIdentityLookup .

Signed-off-by: Miloslav Trmač <[email protected]>
- Use the correct library name
- Allow specifying a library path at compile time

Example usage:
> make BUILDTAGS="btrfs_noversion containers_image_sequoia" SEQUOIA_SONAME_DIR=$(pwd)/signature/internal/sequoia/rust/target/release

Signed-off-by: Miloslav Trmač <[email protected]>
... to match the recent more specific subkey validation
semantics.

Should not change behavior.

Signed-off-by: Miloslav Trmač <[email protected]>
Should not change test behavior, merely to be more similar
to the rest of the codebase.

Signed-off-by: Miloslav Trmač <[email protected]>
It can be handled in callers - and it's better to do based on .Init()
outcomes.

Signed-off-by: Miloslav Trmač <[email protected]>
- Allow using c/image without loading sequoia if
  GO_SEQUOIA_ENABLE_DLOPEN is used, and nothing uses
  the Sequoia code at runtime.
- Allow adding ~independent users of signature/internal/sequoia,
  without having to coordinate to call Init at least once.
  We will add signature/simplesequoia to benefit from this.

Signed-off-by: Miloslav Trmač <[email protected]>
We can't reasonably unit-test the $HOME variant; tested manually.

Signed-off-by: Miloslav Trmač <[email protected]>
By default, the Rust logging output is silently discarded.

Signed-off-by: Miloslav Trmač <[email protected]>
Signed-off-by: Miloslav Trmač <[email protected]>
Add missing tests, or add comments where that's not practical.

Should not change behavior.

Signed-off-by: Miloslav Trmač <[email protected]>
Should not change behavior.

Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac added 6 commits August 7, 2025 22:13
For now only local tests, we should also do this for test_skopeo,
but that ~requires a corresponding Skopeo update.

WIP: We want to use distribution packages instead of compiling
Rust code ourselves.

Signed-off-by: Miloslav Trmač <[email protected]>
Requires an unmerged Skopeo PR.

Signed-off-by: Miloslav Trmač <[email protected]>
... to save on irrelevant cloud costs and noise, for now.

Signed-off-by: Miloslav Trmač <[email protected]>
Notably, if the format is armored and the contents are unsupported,
don't just complain about invalid binary format ("tag byte does not
have MSB set") but report the unsupported value.

Signed-off-by: Miloslav Trmač <[email protected]>
…ature

This fails with openpgp: openpgp: unsupported feature: public key type: 22
(EdDSA signature). Do we need to migrate to a fork?

Signed-off-by: Miloslav Trmač <[email protected]>
@jankaluza
Copy link
Member

Hi, and thank you for your contribution!

We’ve recently migrated this repository into a new monorepo: containers/container-libs along with other repositories

As part of this migration, this repository is no longer accepting new Pull-Requests and therefore this Pull-Request is being closed.

Thank you very much for your contribution. We would appreciate your continued help in migrating this PR to the new container-libs repository. Please let us know if you are facing any issues.

You can read more about the migration and the reasoning behind it in our blog post: Upcoming migration of three containers repositories to monorepo.

Thanks again for your work and for supporting the containers ecosystem!

@jankaluza jankaluza closed this Aug 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants