Rewrite container handling internals to drop graphdriver and gpgme dependencies [RHEL-56367] - #2607
Conversation
5bf4948 to
5236abc
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
31d3292 to
e7e82a8
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
|
||
| var manifestDigest digest.Digest | ||
| if dockerAuth := cl.sysCtx.DockerAuthConfig; dockerAuth != nil { | ||
| cmd.Args = append(cmd.Args, fmt.Sprintf("--dest-creds=%s:%s", dockerAuth.Username, dockerAuth.Password)) |
There was a problem hiding this comment.
This leaks the credentials to any user running ps during a build. Is there no other way of passing these?
There was a problem hiding this comment.
I had the same thought but the only reason we have the user:pass option is because the osbuild-upload-container supports --username and --password and in that case, the original call leaks them to begin with. Maybe we should get rid of that entirely and only support auth-file.
There was a problem hiding this comment.
Let's turn this into an issue here.
There was a problem hiding this comment.
This seems to also cause a leak in the osbuild-composer workers when uploading container images. They call (*Client).UploadImage() at osbuild-composer/cmd/osbuild-worker/jobimpl-osbuild.go:1319 which results in the same argv leak under discussion here.
Given that this is a new leak affecting the library API we may want to reconsider deferring to the future. I think it would make sense to update this pull request to only support auth-file.
There was a problem hiding this comment.
Oh we do use it! Ok then, I'll take care of it in this PR.
e7e82a8 to
bb681b7
Compare
lucasgarfield
left a comment
There was a problem hiding this comment.
Overall looks great!
Only thing I caught is that the skopeo argv leak is a bit worse than we thought. I'd request that we address that somehow (if we choose to defer, that's fine, but we should be intentional about it) before approval.
I would also be curious to hear why we decided to go with distribution/distribution for the registry. Did you consider google/go-containerregistry/pkg/registry? I have no strong opinion and can see good arguments for both, just curious about you decided. distribution/distribution has more features (which I'm not sure we're taking advantage of... yet?) but also more dependencies.
I didn't spend too much time looking into the two but it seemed like it was less work to get a minimal registry running with I'll play around with it a bit more. |
|
Ok, moving everything to |
bb681b7 to
eb74836
Compare
Rewrite the resolver tests to use the new test registry functionality.
Return the image IDs that were created by the PopulateWithManifestList() function alongside the digests for the new images.
Rewrite the container client tests to use the new test registry functionality.
Rewrite the blocking resolver tests to use the new test registry functionality.
Use the new testregistry to upload a container using osbuild-upload-container and verify that it was uploaded successfully by resolving the container using our own resolver. The main() function of the osbuild-upload-resolver is split into an upload() function that does the main work so it can be testable. The main() function now only handles command line flags and then calls into the new function.
Test uploading a container with credentials (username and password).
Rewrite the container UploadImage() function to shell out to skopeo copy. It takes care of all the options we currently support by converting them to command line options. The functionality is tested by the new osbuild-upload-container tests.
Drop the parseImageName() function and the policy property of the client. They're not needed anymore.
On RHEL and CentOS, the exclude_graphdriver_btrfs tag was needed to compile without support for the btrfs driver from the containers/image dependency. That dependency is now gone and we don't need to specify the tag anymore. The same goes for the other graphdrivers: devicemapper and overlay. Even though we could support those on the two distros, we sometimes specified them to avoid needing the devel package dependency installed.
The containers/image pgp dependency is also gone.
Remove btrfs-progs-devel, device-mapper-devel, and gpgme-devel from the dependency install script.
Remove mentions of btrfs-progs-devel and device-mapper-devel. Also remove mentions of cmd/build. This README should be replaced by the Image Builder readme soon. See HMS-10586
Remove all mentions of: - gpgme-devel - btrfs-progs-devel - device-mapper-devel
Specifically, skip tests that fail in containers because of the way they access the host container storage. These weren't an issue on CentOS before, but now appear to be failing the same way they do in Fedora containers.
We use systemd-escape to generate mount unit names. On installations, this is pulled in by osbuild itself, but tests will fail at build time without it.
be9d96a to
ac9961c
Compare
|
Instead of putting credentials in the arguments of the 'skopeo copy' call (with --dest-creds) when uploading a container, write a temporary auth file and use --authfile. This prevents leaking credentials through the shell call, which is visible to any user on the system.
Now that we have an auth file creation function, let's use it instead of depending on 'skopeo login' to generate it.
ac9961c to
73c0291
Compare
This PR rewrites container-related things in order to drop our dependency on graphdrivers and gpgme. It finishes the work I started in #2346, where I changed the container resolver internals to use
skopeo.Changes in this PR, in order:
osbuild-upload-containerwith the new test registry. The upload code wasn't being tested at all before, so any testing here is an improvement.osbuild-upload-containerto useskopeo copyinternally.With these rewrites, we rely on
skopeofor almost all of our interactions with container registries, which means we don't depend on any of the filesystem libraries or gpgme.