[release-5.19 backport] Bump github.com/containers/ocicrypt to 566b808

[lsm5]

The two latest commits in c/ocicrypt get rid of OAEPDefaultHash envvar
and default to sha256.

They are waiting for confirmation on their rust side before cutting a
release. So, hoping to get this in assuming dependabot could take a
while.

Signed-off-by: Lokesh Mandvekar lsm5@fedoraproject.org

@vrothberg @mtrmac @rhatdan PTAL. This is for subsequent vendoring into podman v4.0-rhel branch.

RE: containers/podman#14102 (comment)

[mtrmac]

LGTM.

[mtrmac]

The failing tests probably need some variant of #1535 ; I’m not 100% certain that the backport branch doesn’t need to deviate (Cc: @cevich ), but my first guess is that backporting that change as is is good enough, and probably worth doing even while waiting for a confirmation.

[lsm5]

Depends on #1540

[cevich]

backporting that change as is is good enough, and probably worth doing

Ya, I generally avoid changing out VM images on release branches, and this specific repo. has extra complicating factors. However there are sometimes exceptions. If this branch is reasonably new and sufficiently related to the skopeo-repo-state where F36 was introduced, then yes. Update the VM images here so they match the skopeo branch referenced for testing (which is also currently/probably set wrong).

[mtrmac]

this branch is reasonably new and sufficiently related to the skopeo-repo-state where F36 was introduced, then yes.

It’s about a month of difference so far, and the original image is gone, so it seems easier to update to the current one than to branch and maintain another set of images, at least right now. Assuming we can actually get that working, the number of trivial changes being discovered one at a time is inching towards looking concerning.

[cevich]

It’s about a month of difference so far

Oh okay, that's not super bad, maybe it can be done.

the number of trivial changes being discovered one at a time is inching towards looking concerning.

Yes, there are differences in the images too (i.e. tooling script differences). Another reason generally I say they only move forward. I do have a super-squirrel-secret way to recover images within a 29-59-day window, but if the images age past 60-days, they're irrecoverable. I only mention that in case it's an option here, I haven't checked any CI-run dates on this branch.

[lsm5]

@mtrmac this is good to go. PTAL

[mtrmac]

Is this line really necessary? I think just bumping the version above should be enough. (And it kind of has to be enough because replace directives only work at the top level, i.e. this wouldn’t apply to a Skopeo/Podman build.)

[lsm5]

go mod download didn't let me fetch v1.1.4 so I kept the line with the version-commit as-is and got rid of the replace directive. PTAL.

[mtrmac]

go mod download isn’t supposed to update go.mod I think…

FWIW go get github.com/containers/ocicrypt@v1.1.4 worked for me, resulting in

github.com/containers/ocicrypt v1.1.4

. I didn’t realize this pre-release version actually points at a tagged version — in that case, I think using the 1.1.4 tag would be a bit safer WRT any other consumers of that.

[mtrmac]

LGTM.

Thanks for all the work to make this possible!

[lsm5]

Thanks @mtrmac .

Btw, on rawhide, I got this:

$ go get github.com/containers/ocicrypt@v1.1.4
go: github.com/containers/ocicrypt@v1.1.4: invalid version: resolves to version v1.1.5-0.20220428134531-566b808bdf6f (v1.1.4 is not a tag)

But then I simply edited go.mod to have v1.1.4 against ocicrypt, followed by only running go mod tidy (no go get), and seems to work well.

Maybe that's a new rawhide change.

[mtrmac]

Or it could be something with GOPROXY, or a pre-existing local download? I find the tool’s behavior a bit hard to understand sometimes.

[lsm5]

Or it could be something with GOPROXY, or a pre-existing local download? I find the tool’s behavior a bit hard to understand sometimes.

ack, I'll look further. Thanks a lot for the merge!!