[3.4] Issues #27850 and #27766: Remove 3DES from ssl default cipher list an… #224
Conversation
|
The change fixes the security vulnerability "Sweet32": |
|
FYI I created a second PR based on this one: PR #226. Let's see how it works :-) Ah, it seems like the Merge button is restricted to release managers on the 3.4 branch. |
|
ping @larryhastings and @ned-deily |
|
@Haypo, This change is already in 3.6 and 3.5 already, correct? So the only issue is 3.4? If so, you need a review from @larryhastings, not me! And, in general, if there is a release blocker issue, you need to flag it as such on the bug tracker, not here. |
|
Updated URL:
Right.
Yes. In branches still accepting security fixes, it seems like only 3.4 remains vulnerable:
I created this PR 16 days ago, and Larry didn't reply yet. IMHO it's an important security vulnerability, so I would prefer to merge this fix quickly. Then the question will be when a new 3.4 version can be released with the security fix :-/ About the bug tracker: the Priority field has no version, "release blocker" is not specific to the 3.4 branch. I looked at http://bugs.python.org/issue27850 which is a single issue for all branches. |
|
All you need to do is set the version to 3.4 only (which it is already) and then set "release blocker". Please continue to follow our long-standing policy about release blockers because otherwise issues are going to fall through the cracks. As far as merging goes and producing a 3.4.x security release, that's up to Larry. This has been open now for months so I guess it can wait a few more days, no? |
Ah, when an issue affect multiple versions, I prefer to keep all versions selected. But well, since someone already removed 2.7, 3.5 and 3.6, it works for me :-)
Ok, done. |
|
I'm not qualified for security review work, so I'm a poor choice of reviewer for this. |
|
Security wise this is a good change. I think the only question is whether it's OK for it to land in 3.4 (which IMO it should)? AFAIK the RM has to be the one to OK a merge into a security only branch? |
|
Larry: I am not asking you for a review, the change was already reviewed
and approved. But it seems like only you can push the Merge button on the
3.4 branch.
Once this fix is merged, would it be possible to get a release quickly?
|
|
"Once this fix is merged, would it be possible to get a release quickly"
My plan is to make sure that all known vulnerabilities are fixed in all
maintained branches. Sorry, I forgot to say that this fix may only be the
first one of a serie. I have to check the list of vulnerabilities.
My question was more a general questions. I don't understand how minor
releases (3.x.y) are scheduled.
|
|
By default I schedule releases every six months, which I gather is nicer for downstream maintainers like Linux distributions. I make emergency releases for the-sky-is-falling security holes. I haven't been convinced that "remove an old and increasingly broken encryption standard from a list of approved defaults" merits the cost to the world of a new 3.4 release. |
|
I don't think that getting rid of 3DES by default is a big enough deal to warrant an emergency release. |
|
Larry:
By default I schedule releases every six months, which I gather is nicer
for downstream maintainers like Linux distributions.
From my point of view, a release is a Git tag and a tarball, but I probably
miss many points. Why not releasing more often?
|
|
Eh, it's a balance. Every release changes some behavior so every release risks regressions to someone. The more of them you have the more variable behaviors you're going to see in the wild (e.g. we have pip bugs that only reproduce on specific versions of Python down to an X.Y.Z). In addition other people consume these releases so each release you make adds additional work for them to integrate that release within their own tooling (for example, Debian, Red Hat, etc pulling in the latest version). At the end of the day when to release is a balancing act between churn and not holding up features or improvements for extended periods of time. |
|
Ok I see, it makes sense.
|
_common: add type hint to files()
…d add ChaCha20 Poly1305.
Backport: replace 3.5.3 with 3.4.7 in the doc versionchanged.
(cherry picked from commit 03d13c0)