On Fri, Feb 19, 2021 at 2:16 AM Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote: > > On 2/11/2021 3:23 PM, Michał Górny wrote: > > > Hello, > > > > > > I'm the primary maintainer of CPython packages in Gentoo. I would like > > > to discuss possible improvement to the release process in order to > > > accelerate releasing security fixes to users. > > > > > > I feel that vulnerability fixes do not make it to end users fast > enough. > > > > When we introduce a bad regression in a release, including a > > severe-enough security vulnerability, and discover it soon enough, we > > have sometimes made immediately releases. > > > > Beyond that, your proposal to add several releases per Python version, > > perhaps double what we do now, runs up against the limits of volunteer > > time and effort. As it is now, becoming a release manager is a 7 year > > commitment, with at least one release about every other month for the > > first 4. There are also the 2 people who produce the Windows and macOS > > installers. I believe each has done it for at least 7 or 8 years > > already. Releases are not just a push of a button. Make the release > > job too onerous, and there might not be any more volunteers. > > While I understand your concerns and sympathize with them, I don't think > it's fair to play the volunteer card here. After all, I am a volunteer > too, and many distribution packagers are as well. We also have limited > time and many other duties, and it just feels unfair for you to be > dumping the security work on us. > I also don't think it's fair to say anyone is "dumping security work" on you. Volunteerism is about accepting that I can't ask anything of you while you can't ask anything of me. We all do our best here, but it's making choices with very finite resources and our release and security approach is the one we have made based on what we have to work with. If people would like to see more frequent releases then it will most likely require people volunteering to help with the security workload as well as with the release process, both of which are rather thankless jobs unfortunately. But simply because we have differing views on how to handle security doesn't mean anyone is actively "dumping" anything on anyone. > > The thing is, CPython upstream has the opportunity to do the central > work that benefits everyone. You get the first indication > of the vulnerability, you have the first fix and backport to all > branches. It is only the natural next step to make a release with it. > While I realize it means more work, not doing that means more work for > a number of other people who are impacted by your prior work. > > That said, if the regular release process is too much work, then maybe > a process similar to security-supported branches would work? After all, > I think it reasonable to assume that a large number of CPython users are > using it via distribution packages and having Python 3.8.x.y source-only > release will be already a big help to people making these packages. > But a very large number of people get their releases from python.org, so if we do source-only releases without pushing out an install that then causes a schism between what users get on one platform versus another that goes beyond simply the delivery mechanism (and this isn't hypothetical; downstream packages by Linux distros have caused issues for users due to differing from what python.org pushes out, so we do need to consider this impact). -Brett > > > > For example, according to the current release schedules for 3.9 and > 3.8, > > > the bugfix releases are planned two months apart. While the release is > > > expected to happen in the next few days, both versions are known to be > > > vulnerable for almost a month! > > > > > > Ironically, things look even worse for security-supported versions. > > > Please correct me if I'm wrong but both 3.7 and 3.6 seem to be behind > > > schedule (planned for Jan 15th), and they are known to be vulnerable > > > since mid-October. > > > > > > In my opinion, this causes three issues: > > > > > > 1. Users using official releases are exposed to security > vulnerabilities > > > for prolonged periods of time. > > > > > > 2. When releases happen, security fixes are often combined with many > > > other changes. This causes problems for distribution maintainers who, > on > > > one hand, would like to deploy the security fixes to production > versions > > > ASAP, and on the other, would prefer that the new version remained in > > > testing for some time due to the other changes. > > > > > > 3. Effectively, it means that distribution developers need to track > > > and backport security fixes themselves. In the end, this means a lot of > > > duplicate work. > > > > Perhaps people doing duplicate work could get together to eliminate some > of > > the duplication. It should be possible to filter security commits from > the > > python-checkins list by looking at the news entries and if need be, the > bpo > > issues. > > This makes me think of the 'systemd-stable' repository (where another > maintainer is making bugfix releases to previous versions of systemd). > I suppose this could work as a last resort but only if it was officially > supported and endorsed by CPython. However, at this point it's not > really clear why not go the one step further and make the official > releases. > > -- > Best regards, > Michał Górny > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/I52QGQVA55BXF425V5IZLF3GYYPWLOKW/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V27EKQD23DY4LQ7NKKBUYKT25UFLPFEH/ Code of Conduct: http://python.org/psf/codeofconduct/
