For 3.4, please review my pending security fixes :-) There are more of them. About the cipher list in ssl, the change itself is simple but it's to blacklist DES and 3DES since it has been proved that these ciphers are really too weak nowadays: http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des_... By the way, is Larry the only one to be able to merge changes in 3.4? Before GitHub, all core dev were technically allowed to push in security-only branches. I would be interested to be allowed to push my own security fixes, but also to enable Travis CI and maybe AppVeyor on the 3.4 and 3.3 branches. Victor Le 22 juin 2017 04:58, "Larry Hastings" a écrit :

It's time to start planning the next 3.5 release, 3.5.4. Note that this will be the last 3.5 "bugfix" release; after 3.5.4, the 3.5 branch will only be open for security fixes. 3.5.4 will also be the last release of 3.5 with binary installers.

I propose to tag and release 3.5.4 on these dates:

3.5.4rc1 tag Sat July 22 2017 release Sun July 23 2017

3.5.4 final tag Sun Aug 6 2017 release Mon Aug 7 2017

Thus rc1 would be tagged in just over four weeks.

As for 3.4--

Lately I've been releasing new versions of 3.5 and 3.4 at the same time. But I'm not sure it's worth the effort to release another 3.4 right now. There have only been two (2) checkins into the 3.4 branch since 3.4.6 was released back in January:

f37b0cb230069481609b0bb06891b5dd26320504 bpo-25008: Deprecate smtpd and point to aiosmtpd

fa53dbdec818b0f2a0e22ca12a49d83ec948fc91 Issues #27850 and #27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.

The first was a documentation-only change which is already live on docs.python.org. The second changes the _DEFAULT_CIPHERS and _RESTRICTED_SERVER_CIPHERS constants in Lib/ssl.py. A reasonable change, but minor. I'm not convinced it's worth spending the time of many people in the community at large to update 3.4 just for this.

If you have any feedback / concerns about this schedule, or if you think it's important that I release 3.4.7 with these minor changes, please reply here. If I don't hear anything back in a day or two I'll go ahead and make this the official schedule.

Your friendly neighborhood release manager,

*/arry*

_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

On Thu, 22 Jun 2017 at 02:32 Larry Hastings wrote:

On 06/22/2017 01:04 AM, Victor Stinner wrote:

About the cipher list in ssl, the change itself is simple but it's to blacklist DES and 3DES since it has been proved that these ciphers are really too weak nowadays:

http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des_...

Not "blacklist"--IIUC the user can still manually specify whatever cipher suites they like. And not DES... who knows how long ago that was removed from the list.

This change in 3.4 removes 3DES from the *default* permissible cipher list, changing those entries to use "HIGH cipher suites" instead (OpenSSL's term for "cipher suites with key sizes >= 128 bytes"). It also adds ChaCha20 to the default cipher list.

By the way, is Larry the only one to be able to merge changes in 3.4? Before GitHub, all core dev were technically allowed to push in security-only branches.

Oh? Am I? **insert evil laugh** Ladies and gentlemen, get out your checkbooks! 3.4 is about to get... expensive.

Seriously, though, I was mostly hoping other people would handle the security stuff and just keep me informed. If I'm the only one permitted to accept PRs into 3.4 (and soon 3.5), okay, I can work with that. I'm still probably gonna delegate the actual judgment of the validity of the PRs. But obviously it'll mean I'll have to be more hands-on, where so far I was assuming I could just let other people handle it.

Currently the security-only branches are set so that only release managers can merge PRs since they technically are on the hook if some compatibility breaks due to some patch (e.g. I expect Ned to use this for 3.7 once we hit rc to really control what goes in last minute). It's easy enough to turn this protection off, though, if people want.

On 06/23/2017 01:55 AM, Victor Stinner wrote:

Larry: would you be ok to turn this protection off on the 3.4 branch? Or would you feel more confortable if only a few people would be allowed to push to the 3.4 branch, so add me a whitelist group or something like that?

Actually I kind of like the idea of the branch being restricted. Let's try it for now and see if it works.

As I wrote, my plan is not only to merge my security fixes, but also to work on a CI. I would feel more confortable to see the Travis CI test result on my security PRs.

Do you need write access to the branch in order to get Travis CI working? //arry/

2017-06-23 15:19 GMT+02:00 Larry Hastings :

Do you need write access to the branch in order to get Travis CI working?

As soon as someone reviews my proposed 3.4 patches, no :-) I will work on a PR. Victor