-
Notifications
You must be signed in to change notification settings - Fork 395
Sequoia-PGP interoperability test #2903
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
Conversation
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]>
b58084d to
7c7ecdc
Compare
9af15eb to
6908aaf
Compare
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]>
…iners-image into signature-sequoia
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]>
Signed-off-by: Miloslav Trmač <[email protected]>
Signed-off-by: Miloslav Trmač <[email protected]>
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]>
…Mechanism 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]>
…ner API Signed-off-by: Miloslav Trmač <[email protected]>
Should not change behavior. Signed-off-by: Miloslav Trmač <[email protected]>
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]>
|
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! |
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:
[]string{"50DDE898DF4E48755C8C2B7AF6F908B6FA48A229"} does not contain AC99AAF67A588DF381A6A95C7ADD16BD41D829B6"(signature using a subkey)openpgp: unsupported feature: public key type: 22(EdDSA signature)