-
Notifications
You must be signed in to change notification settings - Fork 33
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
Propose following every Ubuntu LTS #310
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I worry about this creating more work than we as a team can handle.
3.) I'd also be curious if you could elaborate on the security improvements of releasing twice as often. The way I read the RFC, there is an implication that our present release cycle may have security drawbacks. I think it would be good to more clearly state these drawbacks. My understanding is that the present stack release cycle we follow keeps us in the Ubuntu patch cycle, but that what we miss out on are low/minor patches (sometimes Ubuntu defers these to the next release) and new/updated libraries (not security related). This is what we have documented on the website anyway, https://paketo.io/docs/concepts/stacks/#when-are-paketo-stacks-updated. In regards to 2.), I've not observed that personally. The question I usually get is do you have X stack, where X is some other non-Ubuntu distribution of Linux. Debian, UBI, Alpine, or some other base that promises to have marginally smaller images. I'd be curious to hear from users on what they want/expect/need in this regard. |
I am a bit surprised to read this, because I recall this has been a topic in a past WG meeting (quite a while ago though) and I thought the only thing missing was materializing the decision from then in an RFC.
Anyway, regarding your points. Regarding 2. & 3. I suppose users usually don't care much about the stack, that's why they use buildpacks and not Dockerfiles in the first place. However, we've seen in the past that the number of known CVEs on Ubuntu LTS releases grows over time. This might not be an immediately worrying concern, as Ubuntu indeed patches critical vulnerabilities throughout the five years an LTS is maintained. But there are CVEs in the security advisory that have been rated low priority while they show a CVSS score >7. Using 🔍 Vulnerabilities of
|
digest | sha256:981912c48e9a89e903c89b228be977e23eeba83d42e2c8e0593a781a2b251cba |
vulnerabilities | |
size | 31 MB |
packages | 143 |
🔍 Vulnerabilities of ubuntu:24.04
📦 Image Reference ubuntu:24.04
digest | sha256:cdc507f6026a62440bc601815bba185960e93f8b971112722cebe3cae1e125a0 |
vulnerabilities | |
size | 29 MB |
packages | 130 |
Description
Description
| ||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||
Description
|
Yes @loewenstein-sap - That would alleviate my concerns for 1.) and if it's not materially increasing the amount of work the project needs to do, then I'm less inclined to be picky about 2.). I do agree that there is a subset of users where the non-critical unpatched vulnerabilities in our Ubuntu buildpacks are a bit annoying. If it's not a lot of work, and we can make things better for them, then 👍 |
|
||
## Motivation | ||
|
||
Users of Paketo rely on us to provide an up-to-date root file system for their applications. This includes the latest security patches and software updates. While Ubuntu LTS releases are supported for 5 years, it is important to provide the latest LTS release to our users as soon as possible to ensure they can benefit from the latest features and security updates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users of Paketo rely on us to provide an up-to-date root file system for their applications. This includes the latest security patches and software updates. While Ubuntu LTS releases are supported for 5 years, it is important to provide the latest LTS release to our users as soon as possible to ensure they can benefit from the latest features and security updates. | |
Users of Paketo rely on us to provide an up-to-date root file system for their applications. This includes the latest security patches and software updates. While Ubuntu LTS releases are supported for 5 years, it is important to provide the latest LTS release to our users as soon as possible to ensure they can benefit from the latest features and security updates. This also provides a longer period of time for users to transition from one release to the next. |
|
||
## Detailed Explanation | ||
|
||
In late April of every even year, Ubuntu releases a new LTS version. Once the new LTS version is released, the Stacks team will begin work on providing the new build and run images. Once build and run images are available, the Builders team will begin work on providing the corresponding builders. Once the buildpackless builders are available, the individual buildpack teams will begin to evaluate and test their buildpacks on the new builders and work on fixes or mitigations should they be needed. Once all buildpacks have been confirmed to work on the new builders, the Builders team releases the buildpackfull builders. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to wait until every last buildpack has been verified before we release the builders with buildpacks? If one buildpack team is not responsive, this can delay the whole process with no limit.
I could see some other possibilities like:
-
Buildpack teams have three months to verify and apply any fixes required to make their buildpack compatible. After three months, we release the builders with all the buildpacks that have been verified, omitting any that have not been marked as verified. As buildpack teams confirm compatibility the builder will be updated to include those buildpacks as well.
-
The builder team will release the builders with buildpacks in beta mode when we have confirmed that 50% of the buildpacks are compatible. After that, as buildpack teams confirm compatibility the builder will be updated to include those buildpacks as well. The builder will exit beta when 100% of the buildpacks have been verified.
Thoughts?
Summary
This is to propose to
Use Cases
Having an up-to-date root file system.
Checklist