Add Docker Plugin RPMs to Update Policy Exception List #3394
Labels
No labels
document it
fast track
meeting
next release
nonresponsive maintainer
packager revocation
pending announcement
provenpackager
python 2 exception
self contained change
stalled
Status
Accepted
Status
Duplicate
Status
Insufficient data
Status
Invalid
Status
Rejected
system wide change
updates policy exception
vote-in-progress
No milestone
No project
No assignees
7 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fesco/tickets#3394
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Synopsis
Add the docker-compose, docker-buildx, and docker-buildkit plugins to the update policy exception list. Only the latest release for each plugin plus the development branch receives security and bug fixes in addition to new features.
Benefit
Provides supported and maintained versions of these three (3) Docker cli plugins to Fedora users.
Additional Information
Three Docker plugins are provided as Fedora rpms: docker-compose, docker-buildx, and docker-buildkit. The applications in these rpms work with the Docker command line client provided in the docker-cli package (subpackage to moby-engine rpm).
All 3 plugins have a relatively rapid update cycle. Docker-compose for example currently has these versions available: F43 - v2.35.0, F42 - v2.33.1, F41 - v2.30.3, F40 - v1.29.2. Only v2.35.0 is supported leaving all supported Fedora releases with unmaintained versions. There are open CVE bugzilla issues for some of these unsupported versions.
The docker-buildx and docker-buildkit rpms are in similar circumstances with a rarely used caveat from upstream:
Once a new feature release is cut, no support is offered for the previous feature release. An exception might be if a security release suddenly appears very soon after a new feature release.Potential limitation:
It is possible that the oldest, supported Fedora release (e.g. F40 at this time) will not provide a suitable version of the Go language needed to build these plugins. If this condition occurs, an announcement to Fedora developers and user Forums will be made.
Version support links
Buildkit: https://github.com/moby/buildkit/blob/master/PROJECT.md#release-milestones
Buildx: https://github.com/docker/buildx/blob/master/PROJECT.md#types-of-releases
Compose: https://github.com/docker/compose?tab=security-ov-file
This is a reasonable permanent exception. +1
Metadata Update from @ngompa:
Other than a v1 -> v2 bump in F40, updating the other branches should be semver compatible and thus already allowed under the updates policy.
So - you're saying this is not needed yet, or at least a permanent one is not needed, and we can just grant a one-off exception for F40? (F40 is going EOL in less than a month, in which case is it even worth updating)
+1 to make a permanent exception. (I think it's fine to make this explicit, even if most of the time the update would be allowed anyway under the generic rules.)
I'm +1 as well
Are those projects actually following SemVer though? If yes, then I agree that those updates from 2.x to 2.y should be fine even without an exception. But in general, I'm fine with +1 to a general exception too ... (and it might be too late for F40 anyway).
Yes, these three projects are more or less following SemVer with frequent increments in the "minor" version. Their record to date are few patch releases before another minor release.
The v1 to v2 change for Docker Compose was comprehensive. V1 was a standalone program written in Python. V2 is deploy as a plugin to docker (also usable by podman) and written in Go. V2 also comes with a V2 compose file format (which is different from the legacy 2.x and 3.x formats supported by Compose V1.
So shouldn't it be okay to perform the updates you want in F41-F42 under the existing Guidelines without an exception?
The update from v1 -> v2 is a complete rewrite. Is that really something we want in F40, especially with it going EOL soon?
I'd be more inclined to get an exception to update moby-engine itself since the version in F40 is quite old and not supported upstream and may have unpatched vulnerabilities.
Both Buildx and Buildkit are version 0.x.x and the semantic versioning standard says:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.So this could potentially result in some churn for the user community and seems to potentially conflict with the Fedora notion of "stable" releases. Given the policies for these products that only the current release is supported, however, seems compelling and I think worth checking in with FESCo.
I am not planning on doing anything for F40 and Compose.
I do have a draft PR to do just that. I have been negligent is submitting the ticket to FESCo.
Ah, I see. So it seems this request makes sense for buildx and buildkit until they have a stable release but not for compose which has already had a stable v2 release for some time.
Since they were all plug-ins as part of the same docker ecosystem I thought it best to be inclusive.
Metadata Update from @fale:
APPROVED (6,0,-0)
Metadata Update from @fale:
Metadata Update from @ngompa:
This needs to be documented before closing since this is a permanent exception.
Metadata Update from @ngompa:
https://pagure.io/fesco/fesco-docs/pull-request/106
Metadata Update from @zbyszek:
Done.
Metadata Update from @zbyszek: