python-committers June 2015

python-committers@python.org

14 participants
4 discussions

Co-maintainer(s) for contextlib, dis and/or runpy?
by Nick Coghlan 28 Jun '15

28 Jun '15

Hi folks, My available time for the fundamentals of stdlib module maintenance is unfortunately pretty limited these days, which means even reviewed patches for modules where I'm the sole maintainer aren't necessarily getting applied in a timely fashion (Serhiy quite rightly nudged me about this recently in relation to a languishing contextlib patch). Would anyone be interesting in taking up co-maintainership of one or more of the affected modules? Timely reviews I can generally manage (especially for other core developers), it's timely patch application and new module level development work that I struggle to find the time for :( The affected modules: * contextlib * dis * runpy Regards, Nick. P.S. In the specific case of contextlib, I'm also interested in finding someone willing to take up maintenance of the contextlib2 backport: https://pypi.python.org/pypi/contextlib2 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 9

Weak SSH keys
by A.M. Kuchling 03 Jun '15

03 Jun '15

Someone ran an experiment looking at the SSH keys used on GitHub (public keys are accessible through the API): https://blog.benjojo.co.uk/post/auditing-github-users-keys Excerpt: I remembered back to the May 2008 Debian OpenSSH bug, where the randomness source was compromised to the point where the system could only generate one of 32k keys in a set. I used g0tmi1k’s set of keys to compare against what I had in my database, and found a very large amount of users who are still using vulnerable keys, and even worse, have commit access to some really large and wide projects including: ... Crypto libraries to Python Django Python’s core ... CPython is not officially on github, so committing evil stuff to the github mirror may not matter very much, but these users may have the same key configured for hg.python.org. Should we check everyone's SSH keys? --amk

5 12

Ned Deily is release manager for Python 3.6
by Barry Warsaw 01 Jun '15

01 Jun '15

Please welcome Ned Deily as RM for Python 3.6. https://www.python.org/dev/peps/pep-0494/ Cheers, -Barry

3 2

[RELEASED] Python 3.5.0b2 is now available
by Larry Hastings 31 May '15

31 May '15

On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0b2. Python 3.5.0b1 had a major regression (see http://bugs.python.org/issue24285 for more information) and as such was not suitable for testing Python 3.5. Therefore we've made this extra beta release, only a week later. Anyone trying Python 3.5.0b1 should switch immediately to testing with Python 3.5.0b2. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. (However, there are a handful of features that weren't quite ready for Python 3.5.0 beta 2; these were granted exceptions to the freeze, and are scheduled to be added before beta 3.) This is a preview release, and its use is not recommended for production settings. Three important notes for Windows users about Python 3.5.0b2: * If installing Python 3.5.0b2 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows build for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable release designed to be deployed as part of a larger application's installer for apps using or extending Python. During the 3.5 alpha releases, this was an executable installer; as of 3.5.0 beta 1 the embeddable build of Python is now shipped in a zip file. You can find Python 3.5.0b2 here: https://www.python.org/downloads/release/python-350b2/ Happy hacking, //arry/

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers June 2015