Python 3.7.4rc1 and 3.6.9rc1 are now available. 3.7.4rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. 3.6.9rc1 is the release preview of the first security-fix release of Python 3.6. Assuming no critical problems are found prior to 2019-06-28, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.4 and security fixes in 3.6.9. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments.
You can find the release files, a link to their changelogs, and more information here:
Tuesday, June 18, 2019
PyPI Now Supports Two-Factor Login via WebAuthn
To further increase the security of Python package downloads, we're adding a new beta feature to the Python Package Index: WebAuthn support for U2F compatible hardware security keys as a two-factor authentication (2FA) login security method. This is thanks to a grant from the Open Technology Fund, coordinated by the Packaging Working Group of the Python Software Foundation.
Last month, we added the first 2FA method for users logging into the canonical Python Package Index at PyPI.org and the test site at test.pypi.org. Hundreds of project owners and maintainers have now started using that method (generating a code through a Time-based One-time Password (TOTP) application) to better secure their accounts.
Starting today, PyPI also supports (in beta) WebAuthn (U2F compatible) security keys for a second login factor. A security key (also known as a universal second factor, or U2F compatible key) is hardware device that communicates via USB, NFC, or Bluetooth. Popular keys include Yubikey, Google Titan and Thetis. PyPI supports any FIDO U2F compatible key and follows the WebAuthn standard. Users who have set up this second factor will be prompted to use their key (usually by inserting it into a USB port and pressing a button) when logging in. (This feature requires JavaScript.)
This is a beta feature and we expect that users will find minor issues over the next few weeks; we ask for your bug reports. If you find any potential security vulnerabilities, please follow our published security policy. (Please don't report security issues in Warehouse via GitHub, IRC, or mailing lists. Instead, please directly email one or more of our maintainers.) If you find an issue that is not a security vulnerability, please report it via GitHub.
We encourage project maintainers and owners to log in and go to your Account Settings to add a second factor. This will help improve the security of your PyPI user accounts, and thus reduce the risk of vandals, spammers, and thieves gaining account access. If you're not yet comfortable using a beta feature, you can provision a TOTP application for your second factor.
You'll need to verify your primary email address on your Test PyPI and/or PyPI accounts before setting up 2FA. You can also do that in your Account Settings.
2FA only affects login via the website, which safeguards against malicious changes to project ownership, deletion of old releases, and account takeovers. Package uploads will continue to work without users providing 2FA codes.
But that's just for now. We are working on implementing per-user API keys as an alternative form of multifactor authentication in the setuptools/twine/PyPI auth flows. These will be application-specific tokens scoped to individual users/projects, so that users will be able to use token-based logins to better secure uploads. And we'll move on to working on an advanced audit trail of sensitive user actions, plus improvements to accessibility and localization for PyPI. More details are in our progress reports.
Thanks to the Open Technology Fund for funding this work. And please sign up for the PyPI Announcement Mailing List for future updates.
Last month, we added the first 2FA method for users logging into the canonical Python Package Index at PyPI.org and the test site at test.pypi.org. Hundreds of project owners and maintainers have now started using that method (generating a code through a Time-based One-time Password (TOTP) application) to better secure their accounts.
Starting today, PyPI also supports (in beta) WebAuthn (U2F compatible) security keys for a second login factor. A security key (also known as a universal second factor, or U2F compatible key) is hardware device that communicates via USB, NFC, or Bluetooth. Popular keys include Yubikey, Google Titan and Thetis. PyPI supports any FIDO U2F compatible key and follows the WebAuthn standard. Users who have set up this second factor will be prompted to use their key (usually by inserting it into a USB port and pressing a button) when logging in. (This feature requires JavaScript.)
This is a beta feature and we expect that users will find minor issues over the next few weeks; we ask for your bug reports. If you find any potential security vulnerabilities, please follow our published security policy. (Please don't report security issues in Warehouse via GitHub, IRC, or mailing lists. Instead, please directly email one or more of our maintainers.) If you find an issue that is not a security vulnerability, please report it via GitHub.
We encourage project maintainers and owners to log in and go to your Account Settings to add a second factor. This will help improve the security of your PyPI user accounts, and thus reduce the risk of vandals, spammers, and thieves gaining account access. If you're not yet comfortable using a beta feature, you can provision a TOTP application for your second factor.
You'll need to verify your primary email address on your Test PyPI and/or PyPI accounts before setting up 2FA. You can also do that in your Account Settings.
2FA only affects login via the website, which safeguards against malicious changes to project ownership, deletion of old releases, and account takeovers. Package uploads will continue to work without users providing 2FA codes.
But that's just for now. We are working on implementing per-user API keys as an alternative form of multifactor authentication in the setuptools/twine/PyPI auth flows. These will be application-specific tokens scoped to individual users/projects, so that users will be able to use token-based logins to better secure uploads. And we'll move on to working on an advanced audit trail of sensitive user actions, plus improvements to accessibility and localization for PyPI. More details are in our progress reports.
Thanks to the Open Technology Fund for funding this work. And please sign up for the PyPI Announcement Mailing List for future updates.
Tuesday, June 4, 2019
Python 3.8.0b1 is now available for testing
The time has come for Python 3.8.0b1! Download it from:
https://www.python.org/downloads/release/python-380b1/
This release is the first of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0b2, currently scheduled for 2019-07-01.
Please keep in mind that this is a preview release and its use is not recommended for production environments.
The Release Manager would not be able to make this release available alone. Many thanks to the fearless duo of Pablo Galindo Salgado and Victor Stinner for spending tens of hours during the past week working on getting the buildbots green for release. Seriously, that took a lot of effort. We are all so lucky to have you both.
Thanks to Andrew Svetlov for his swift fixes to asyncio and to Yury Selivanov for code reviews, even when jetlagged. Thanks to Julien Palard for untangling the documentation configs. Thank you to Zachary Ware for help with buildbot and CI configuration. Thanks to Mariatta for helping with the bots. Thank you to Steve Dower for delivering the Windows installers.
Most importantly though, huge thanks to Ned Deily who not only helped me understand the scope of this special release but also did some of the grunt work involved.
Last but not least, thanks to you for making this release more meaty than I expected. There’s plenty of super exciting changes in there. Just take a look at “What’s New”!
https://www.python.org/downloads/release/python-380b1/
This release is the first of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0b2, currently scheduled for 2019-07-01.
Call to action
We strongly encourage maintainers of third-party Python projects to test with 3.8 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and no code changes after 3.8.0rc1, the release candidate. To achieve that, it will be extremely important to get as much exposure for 3.8 as possible during the beta phase.Please keep in mind that this is a preview release and its use is not recommended for production environments.
A new challenger has appeared!
With the release of Python 3.8.0b1, development started on Python 3.9. The “master” branch in the cpython repository now tracks development of 3.9 while Python 3.8 received its own branch, called simply “3.8”.Acknowledgments
As you might expect, creating new branches triggers a lot of changes in configuration for all sorts of tooling that we’re using. Additionally, the inevitable deadline for new features caused a flurry of activity that tested the buildbots to the max. The revert hammer got used more than once.The Release Manager would not be able to make this release available alone. Many thanks to the fearless duo of Pablo Galindo Salgado and Victor Stinner for spending tens of hours during the past week working on getting the buildbots green for release. Seriously, that took a lot of effort. We are all so lucky to have you both.
Thanks to Andrew Svetlov for his swift fixes to asyncio and to Yury Selivanov for code reviews, even when jetlagged. Thanks to Julien Palard for untangling the documentation configs. Thank you to Zachary Ware for help with buildbot and CI configuration. Thanks to Mariatta for helping with the bots. Thank you to Steve Dower for delivering the Windows installers.
Most importantly though, huge thanks to Ned Deily who not only helped me understand the scope of this special release but also did some of the grunt work involved.
Last but not least, thanks to you for making this release more meaty than I expected. There’s plenty of super exciting changes in there. Just take a look at “What’s New”!
One more thing
Hey, fellow Core Developer, Beta 2 is in four weeks. If your important new feature got reverted last minute, or you decided not to merge due to inadequate time, I have a one time offer for you (restrictions apply). If you:- find a second core developer champion for your change; and
- in tandem you finish your change complete with tests and documentation before Beta 2
Subscribe to:
Posts (Atom)