On Thu, Feb 11, 2021 at 8:29 PM Terry Reedy <tjre...@udel.edu> 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. > Indeed. What Terry said. There is risk in doing that. It means the solution is more rushed and hasn't been vetted nearly as well. So without a compelling severe reason we're unlikely to. I would expect distros shipping their own python runtime packages to track security issues and their fixes and backport those (generally easy) to their own packages before an official release is ready anyways. The big distros definitely do this. How to deal with this is up to the individual policies of any given OS distro's package owners. -gps 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. > > > 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. > > > I think that security fixes are important enough to justify not sticking > > to a strict release schedule. Therefore, I would like to propose that if > > vulnerability fixes are committed, new releases are made > > as frequently as necessary and as soon as possible (i.e. possibly giving > > some time for testing) rather than according to a strict schedule. > > > > Furthermore, I think that at least for branches that are in higher level > > of maintenance than security, it could make sense to actually make > > security releases (e.g. 3.9.1.x) that would include only security fixes > > without other changes. > > -- > Terry Jan Reedy > > _______________________________________________ > 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/4S5LOTVJZUA5PQ5TRGQFCWHTGA4BOXBO/ > 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/Y6KYIFEMECIMWM7BYYSCJ7AMW2FVNUWK/ Code of Conduct: http://python.org/psf/codeofconduct/
