On May 17, 2018, at 04:24, Paul Moore <p.f.mo...@gmail.com> wrote: > On 17 May 2018 at 04:46, Alex Walters <tritium-l...@sdamon.com> wrote: >>> 1. Producing binaries (to the quality we normally deliver - I'm not >>> talking about auto-built binaries produced from a CI system) is a >>> chunk of extra work for the release managers. >> >> This is actually the heart of the reason I asked the question. CI tools are >> fairly good now. If the CI tools could be used in such a way to make the >> building of binary artifacts less of a burden on the release managers, would >> there be interest in doing that, and in the process, releasing binary >> artifact installers for all security update releases. >> >> My rationale for asking if its possible is... well.. security releases are >> important, and it's hard to ask Windows users to install Visual Studio and >> build python to use the most secure version of python that will run your >> python program. Yes there are better ideal solutions (porting your code to >> the latest and greatest feature release version), but that’s not a zero >> burden option either. >> >> If CI tools just aren't up to the task, then so be it, and this isn't >> something I would darken -ideas' door with. > > I honestly don't know if we're at a point where an auto-built security > release would be sufficient and/or useful. That's mostly a question > for the release manager(s). One sticking point might be that I believe > the Windows installers (at least) are signed, and only the release > managers have the signing key. It's probably *not* OK to leave the > security releases unsigned ;-) So there would be a key management > issue to address there.
IMO, the idea of having either the current CI system or a third party produce binary artifacts for Python releases to be downloadable from python.org is a non-starter for lots of reasons, primarily because of the security risks. The release team *could* produce those artifacts for releases in security mode and, while it would be some extra work, there are so few of them. The question is should we. Once a release moves from bugfix/maintenance mode to security mode, in some ways we are doing a disservice to our users to encourage them to not upgrade to a more recent maintained release. Release branches in security mode do not get any fixes other than, based on past experience, at most a small number of security issues that might arise. In particular, security mode release branches receive no platform-support fixes to support newer OS releases and/or newer hardware support and receive no buildbot testing. Security mode releases today are really for downstream distributors and DIYers who are comfortable building and maintaining their own versions of software. -- Ned Deily n...@python.org -- [] _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
