Add --sign-by-sq-fingerprint #2645
Conversation
contrib/cirrus/runner.sh
Outdated
| } | ||
|
|
||
| _run_build() { | ||
| if [[ "$BUILDTAGS" =~ containers_image_sequoia ]]; then |
There was a problem hiding this comment.
@Luap99 This is broadly the kind of thing I’m thinking of doing in CI, also in Buildah/Podman to have a smoke-test.
Until we have a better packaging of the Rust code, I expect we would not opt into the build tag by default.
There was a problem hiding this comment.
Uh, I really really dislike this. Runtime installs like this are going to flake and break CI eventually. Rust compile times are slow so the CI times get longer.
Sure c/image and skopeo don't have much activity so maybe it can be accepted here but for podman buildah what would be the point? Just build testing seems pointless if we know it builds in c/image?
I feel like without a packaging story there is no point to ship this at all right now and try to rush this out the door. So this is hard hard blocker for me personally.
IMO the order must be find a proper place for the c -> rust library bindings, then release that as c library, then package it into fedora and then we can install it in our upstream VM images and link against it in the builds.
There was a problem hiding this comment.
for podman buildah what would be the point?
I intend to add a smoke-test for a new CLI option (skipped if Sequoia is not enabled). I think that can happen in any case.
And yes, then the discussion whether to enable Sequoia in CI at all, whether to enable Sequoia in releases by default, whether to test only Sequoia in CI, can happen, and I am open to any of the outcomes.
I agree it makes no sense to ship Sequoia enabled upstream by default until the library is easy to install.
Enabled in RPMs? Enabled in CI? Well, maybe?
There was a problem hiding this comment.
02:47 build
for the normal Skopeo Test while
11:57 build
For Skopeo test w/ Sequoia
To me that alone is not acceptable for any merge in any CI anywhere. We can't just make the dev experience an all repos so much worse just because there is one small lib that is not even in use anywhere as it is not packaged.
You can add the code but compiling this in CI on every PR is just plain wasted time/resources. To me the packaging step must happen first for the library. Then we add it into the CI images and then we can link it in build just like the other c libs without this huge overhead.
Whenever the fedora skopeo/buildah/podman rpm builds use libgpgme or Sequoia that is not a discussion I care about.
There was a problem hiding this comment.
Here, I think the more relevant comparison is 12:41 vs. ~22:… for the whole task; the relative difference is not as important.
Anyway, I hear you.
We always have the option of doing the build once in automation_images instead of in primary project repos like this PR is now doing. Given the expected RPM packaging, I don’t think that’s worth the effort right now, but it’s an option. Or I can test things locally and submit ~ineffective tests upstream, to be enabled later.
There was a problem hiding this comment.
Now updated to rely on a RPM installed in containers/automation_images#411 .
(Still blocked on both the automation_images PR, and c/image implementation, being merged.)
mtrmac
force-pushed
the
sequoia-cli
branch
10 times, most recently
from
d1e0d83 to
507e44c
Compare
|
Ephemeral COPR build failed. @containers/packit-build please check. |
2 similar comments
|
Ephemeral COPR build failed. @containers/packit-build please check. |
|
Ephemeral COPR build failed. @containers/packit-build please check. |
mtrmac
force-pushed
the
sequoia-cli
branch
5 times, most recently
from
0700cfb to
954d692
Compare
…oia-PGP This API is proven end-to-end in containers#2876 and containers/skopeo#2645 , but it is not yet convenient to use becahse the Rust dependency has to be compiled manually. So, for now, add the API as a stub only; that allows building the CLIs and tests on top, and they will light up once the backend is added. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
…oia-PGP This API is proven end-to-end in containers#2876 and containers/skopeo#2645 , but it is not yet convenient to use becahse the Rust dependency has to be compiled manually. So, for now, add the API as a stub only; that allows building the CLIs and tests on top, and they will light up once the backend is added. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac
force-pushed
the
sequoia-cli
branch
3 times, most recently
from
817605f to
f0d6d0c
Compare
mtrmac
force-pushed
the
sequoia-cli
branch
3 times, most recently
from
e57169b to
b3113cc
Compare
mtrmac
changed the title
|
Ready for review, PTAL. |
|
Rebased, and added a commit to update tests for |
integration/copy_test.go
Outdated
| assertSkopeoFails(t, ".*Source image rejected: (Invalid GPG signature|.* was not found).*", | ||
| // "Invalid GPG signature" is reported by the gpgme mechanism; "$fingerprint was not found" by Sequoia with rust-python-sequoia 0.1.0, | ||
| // "Missing key: $fingerprint" by Sequoia with rust-python-sequoia 0.2.0. The "was not found" case should eventually be removed | ||
| assertSkopeoFails(t, ".*Source image rejected: (Invalid GPG signature|.* was not found|Missing key:).*", |
There was a problem hiding this comment.
I think because the string and comment is duplicated 4 times here it would be cleaner to extarct into a shared constant that only has the be document once?
There was a problem hiding this comment.
Yes, but, also, after containers/automation_images#416, I plan to check whether that image already contains 0.2.0, and remove one of the branches as well as at least half of the comment again.
There was a problem hiding this comment.
I plan to check whether that image already contains 0.2.0
It does. Well … this PR is bumping the CI image already, let me see if I can update that here directly.
There was a problem hiding this comment.
OK updated with more recent images, and dropped the 0.1.0 variants.
NewEphemeralSigningMechanism() may, with Sequoia, return a mechanism which !SupportsSigning(); so, to determine that, test with a non-ephemeral mechanism instead. (That's likely actually faster, because we create a GNUPGHOME in these tests anyway, so we avoid creating an deleting a separate temporary directory.) Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... from containers/automation_images#416 That requires updating tests to also work with rust-podman-sequoia 0.2.0: ueno/podman-sequoia@d41fefa changed how the error is reported. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Relies on containers/automation_images#411 . Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
containers/skopeo#2645 has updated the expected outputs of Skopeo to match podman-sequoia-0.2.0, so we need to be running with an updated image that includes that version, not 0.1.0. Otherwise, all tests in this repo are failing. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
containers/skopeo#2645 has updated the expected outputs of Skopeo to match podman-sequoia-0.2.0, so we need to be running with an updated image that includes that version, not 0.1.0. Otherwise, all tests in this repo are failing. Use /var/tmp for graph driver tests on Debian, because /tmp is on a tmpfs and we are using an older kernel which does not support extended attributes on tmpfs. This adds 20-30 extra seconds to the test runs. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
3 participants
This is containers/image#2876, integrating with the build system, and it will include new CLI and a smoke test.
Do not merge: Depends on #2681 and containers/image#2876 in c/image.