Mike Miller writes:
> Sounds like automating until it is "just a push of a button,"
> should be a goal. According to Victor there has been progress, but
> always room for more.
When XEmacs was releasing betas regularly, everything from tagging the
local authoritative repo to pushing to the public repo to making
tarballs to signing and authenticating them to Mad-Libbing the form
for announcement was invocation of a single script. "Somehow" the
typical release was a me-day's work and three calendar days (and unlike
GNU Emacs with its "kitchen sink" standard library or Python with its
batteries from CR-25s to Prius power replacements, XEmacs was just the
Lisp interpreter and basic editor functions).
What takes the time?
1. A courtesy pre-announcement to core devs that the release was
coming (yes, it's on the schedule, no, they don't check their
calendars).
2. Triaging incomplete tasks other folks labeled as "important" or above.
3. Writing news (somebody always forgets, and typically the choice was
write it myself or delay the release).
4. Triaging last-minute "urgent" commits. (They rarely were.)
5. Triaging and where possible fixing test failures.
6. Rolling back premature commits.
7. Scheduling future work that didn't *need* to be in a beta release
(we had a couple of developers who were trying but couldn't write
documentation grammatically to save their commits; it just didn't
make sense to force them to do work I could do in 1/10 the effort).
8. Coordination with the dev who built Windows installers. (A few
Windows users could get pretty cranky if they didn't get an
installer within a couple hours after the Unix-oriented tarball
releases.)
The Python process is more disciplined, and has a lot of automation to
help with the QA stuff. But there's always last-minute "people work",
which is what Brooks would call an "essential difficulty." It's
pretty irreducible. I would imagine the same is true for Python RMs.
> I would argue that security releases are of higher importance than
> most,
*Some* of them are, but this just isn't true most of the time. Take
the very recent CVE-2021-3177, rated 9.8 ("critical", 9.8 out of 10, I
believe) because it *might* lead to remote code execution (RCE) under
(implausible, AFAICS) conditions in current Python. There is no RCE
exploit for arbitrary Python webapps: there are a bunch of other
conditions that must be satisfied. It might be possible to create a
denial of service for some webapps, but that still depends on only
somewhat more plausible conditions.
Then, why 9.8? Well, "remote code execution". The critical rating is
a *threat* assessment, based on *everything* going right for the
attacker, not a *risk* assessment, based on likelihood and degree of
damage. Most reported vulnerabilities have no known exploit and
potential RCE is not the common case: risk is quite small.
Such vulnerabilities must be fixed: as time goes on, risk increases.
Not just more time = more time for the black hats, but the hazard rate
increases too. The particular currently implausible kill chain may be
generalized or others may arise in future versions of Python, or more
webapps may incorporate the risky behavior, etc. But there's no
reason to believe it will be a known exploit soon, and anybody with a
million dollars at risk can (and should) keep a couple of hours of
junior developer time on call to assess risk and apply the patch if
needed. Not to mention that in 2025 there will still be a bunch of
vulnerable 3.8 and 3.9 installations online, which are still whatever
the patchlevel was when they were originally installed.
I believe that had they let this one wait until the scheduled release,
the odds are 1000:1 that *no harm whatsoever* would have been done in
that window. Nevertheless, the relevant release managers (3.8, 3.9,
and Windows) chose to make a quick release. I think "customer
relations" (which are important, I'm not deprecating them!) had as
much to do with the decision as the assessment of risk to Python
users. I am not going to second-guess the actual decision, but I do
think that this is very much a case by case issue not very different
from any "urgent" defect, and in many cases "wait for scheduled
release" is going to be a no-brainer, and in others that will be the
outcome chosen.
Some of the time, there will be an emergency release. That has been
demonstrated to be possible and realistic, even in a case like this
where the need is not open-and-shut. I don't see a need for anything
except more love for the release managers. Of course IWBNI we had the
resources to pay release managers. But we're doing OK.
Steve
_______________________________________________
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/LJ3E2UQBPDSFEH7ULNF3QVOYEQYRSAGI/
Code of Conduct: http://python.org/psf/codeofconduct/
