python-committers December 2017

python-committers@python.org

36 participants
27 discussions

Fwd: What happens if I loose my password, 2FA key and recovery key

by Victor Stinner

For the ones who are worried about losing all credentials for their GitHub account, here are some official answers from GitHub support. Victor ---------- Forwarded message ---------- From: Michael (GitHub Staff) <support(a)github.com> Date: 2017-12-12 11:05 GMT+01:00 Subject: Re: What happens if I loose my password, 2FA key and recovery key To: Victor Stinner <victor.stinner(a)gmail.com> Hi Victor, Thanks for getting in touch. To address your questions: The question is what happens if you loose your password, your 2FA key and your recovery key... Ok, it's unlikely, but it's a real question. If you were to lose access to all of your 2FA credentials, I'm afraid we wouldn't be able to disable 2FA for you, for security reasons. For this reason, we recommend setting up one or more fallbacks. One way of safeguarding recovery keys is storing them in an encrypted password manager like 1Password or LastPass, which often have cloud backup capabilities. The second question is if the email account comes into the play as the last attempt to recover access to the GitHub account. The email and password associated with an account provide one factor of authentication. If 2FA is enabled, a second factor is required. In the case of someone losing access to all 2FA credentials, but still having access to the email associated with an account, we aren't able to disable 2FA, but can release the email address from the account. This would then allow the user to register the email address to a new account. Additionally, any contributions associated with that email address would follow along to the new account. At present, we have a range of fallbacks, which I'll list below. It's a good idea to use more than one, while also being mindful of not creating too much exposure. *Download your recovery codes.* This is far and away the best way to make sure you don't get locked out of your account. If you ever disable and then re-enable 2FA, be sure to download the new codes we generate as the old ones will no longer work. https://help.github.com/articles/downloading-your-two-factor-authentication- recovery-codes *Set a fallback number.* As long as your phone wasn't lost, you'll be able to regain access to your account in the amount of time it takes to receive an SMS. https://help.github.com/articles/setting-a-fallback-authentication-number *Add a security key.* Phone got stolen *and* you lost your recovery codes? Today is turning into a rough day, but you'll still have access to your account if you have a FIDO U2F security key added to your account. https://help.github.com/articles/configuring-two-factor-authentication-via- fido-u2f *Store a recovery token* If you use Facebook, you're now able to store a 2FA recovery token with your account. Here's how: https://help.github.com/articles/generating-and-storing-an-account-recovery- token *Set up an SSH key* We’re sometimes able to recover an otherwise locked out account if there’s an SSH key set up. You can add one by heading to: https://help.github.com/articles/adding-a-new-ssh-key- to-your-github-account/ Let me know if you have any questions or if there's anything else we can help with! Best regards, Michael

3 years, 4 months

2FA: only needed at the *first* GitHub login, not needed for commits

by Victor Stinner

Hi, On the "Security: please enable 2-factor authentication on GitHub and your email" thread that I started, I see many people afraid of being annoyed everyday by 2FA (2-factor authentication, called "Authentication code" in GitHub). Let me explain how GitHub uses 2FA. * Let's say that you are not logged on GitHub (or log out to test yourself). * Log in GitHub: enter email and password, then you are asked for an "Authentication code". * You're logged in, congrats :-) * Close Firefox * Open Firefox, go to GitHub: you are already logged in. No more password nor Authentication code asked. Hum... that's it :-) I don't know how long the GitHub cookie remains valid, but it's very rare (maybe once per month? or once every 3 months??) for me to have to log in again. And usually, it's because I log out on purpose. Ok, now you can to push a pull request using SSH: * Step 1: git push (...) * There is no step 2 :-) There is no 2FA here. If I understood correctly, for HTTPS, there is no 2FA neither. So where is the 2FA? * New log in The 2FA is not needed for: * (If you are already logged in) Disabling 2FA doesn't require an authentication code. I just checked for you :-) * Adding a new SSH key to your account only requires your password, but the authentication code is also accepted instead of the password So what is the point of 2FA? It protects the log in. If an attacker has your password without the 2FA key, they are unable to log in. >From what I see, the 2FA doesn't protect against pushing commits if the attacker steal your SSH key or your HTTPS password. My understanding is that it's more common to get a password stolen than a SSH key. While you have to write the password regulary in web forms, GitHub only requires your SSH *public key* (only asked you, when adding a new key). The risk of leaking a SSH private key by mistake is much lower. For example, a browser doesn't ask you to store your SSH private key, only your password. For HTTPS: well, try to avoid HTTPS and prefer SSH? :-) A few months ago, using a Yubikey is Firefox required a plugin. Good news: since Firefox 57 (or even Firefox 56), U2F support is now builtin! But it's still experimental and so disabled by default (it's a simple flag that has to be set to true in about:config): https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/ Google has the same 2FA design. It stores a cookie and so once you are logged on your computer, the 2FA is no more used. There is a check box like "[x] Remember this computer" or something like that. The 2FA matters you someone tries to use your password on a different computer. At work, I have a different experience with 2FA. It's much more stricter. I have to use my 2FA at least once a day, or more frequently depending on the services that I have to use. So yeah, I understand that some people who already suffer from that don't want to be annoyed on the Python project. Victor

3 years, 4 months

Official python-dev docker images

by Barry Warsaw

As part of the importlib_resources skunkworks project Brett and I have been working on (just announced), we’ve also put together a nice Docker image that we’re using for our automated testing. This image is based on Ubuntu 16.04 and provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git checkout of master, currently Python 3.7 of course. Once 3.7 is released to beta, we intend to track its release tarballs too. We also install a few other commonly needed tools, like pip, git, unzip, wget, mypy, and tox. Here’s the project repo: https://gitlab.com/python-devs/ci-images Huge shout out to Abhilash Raj who helped us clean up and compactify the image, and also for setting up automated publishing to quay.io. In case you weren’t aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a lot of Python experience, and a ton of expertise in the image space. He’s an amazing amount of work to improve the quality of this image! Brett and I want to promote this more widely within the Python community as the “official Python Docker image” that projects can use in their own testing environments, or base their own images on it. We wanted to give you guys a heads up first to get your feedback, and maybe thoughts on the best places to promote this, e.g. on the python.org website or other places. We welcome your participation too of course! I’m happy to give write access to the project to any Python committer who wants to help. Cheers, -Barry, Brett, Abhilash

3 years, 4 months

Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)

by Victor Stinner

Hi, For your information, I just sent emails to Julien, Cheryl and Sanyam to notify them that I will their mentor during one month. I asked them to ask me to double check before merging a pull request (Julien) or closing a bug (Cheryl and Sanyam). Since I'm trying for formalize the whole process to become a core dev, I kept a copy of my emails to serve as template for future mentors: https://github.com/vstinner/misc/blob/master/cpython/mentor_core_dev_email.… https://github.com/vstinner/misc/blob/master/cpython/mentor_bug_triage_emai… By the way, I'm now working on the "Process to become a core developer" document (maybe becoming a PEP later?) at: https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.r… (I almost didn't change since I sent it to python-committers) Victor

3 years, 4 months

RFC: Process to become a core developer

by Victor Stinner

Hi, I'm working on a process to describe how a contributor becomes a core developer. The purpose is to be transparent, list "requirements" and responsabilities to the contributor, and have written rules to help to take a fair decision. This document is a draft. I chose to post it on python-committers. I expect that we would have to iterate on it multiple times until we can reach a consensus to agree on the process. While the process has many details, it must be seen more as a guideline than strict rules. Note: I'm trying to avoid gender to be inclusive when mentioning a contributor by using "they" or "their". I'm not sure that it's correct in english, since english is not my first language. Is "they" acceptable to identify a single contributor, or is it restricted to the plural form (contributors)? == Introduction == The overall goal is to get more active developers working on Python to better scale horizontally: get more reviews to get better changes. The code quality is expected to be enhanced: more eyes on reviews should help to catch bugs earlier. Another less important goal is to speed up the Python development IMHO the current blocker issue is that it is too hard to become a core developer. While becoming a core developer is not required to contribute, in my experience, core developers feel more involved and better recognized for their work. Core developer first means becoming responsible of a change: maintain the code/documentation and handle any potential regression. Long term commitment and good quality reviews are also expected from core developers. The blocker issue can be explained by the very high step that should be climed at once to become a core developer. The contributor responsibilities changes at once from "no power" to "can do anything on any part of the project". A promotion is decided with a vote. If a voter doesn't know the contributor, it can be very stressful to take a decision. Building a trust relationship takes time and is not currently formalized by a process. This process is trying to address these issues. I propose to formalize a process to promote a contributor from the early newcomer step to the final core developer step. The process is made of multiple steps to help the contributor to estimate their own progress. Mentoring becomes required by the process and is a major part of the whole process. While the process explains how to "clim" steps, going backward now becomes part of the process, it is not seen as a failure but as a normal and expected change under certain conditions. The final vote to promote a contributor as a core developer is expected to become more natural and simpler. The voters are expected to know better the future candidate. == Process Steps == I propose the following steps to become a core developer: * Step 0: Newcomer * Step 1: Contributor * Step 2: Bug triage permission * Step 3: Mentoree. * Step 4: Core developer == Step 0: Newcomer == The first step is to start as a newcomer. Usually, newcomers are following the Python development without actively contributing. == Step 1: Contributor == I consider that newcomers become automatically contributors as soon as they post their first comment on the bug tracker, comment on a pull request, or a pull request. Their is no manual validation, nor additional privilege. It's just a thin distinction with a newcomer. At this step, it becomes interesting to start reading the Python Developer Guide: http://devguide.python.org/ == Step 2: Bug Triage Permission == Once a contributor becomes active enough, a core developer can propose to give the bug triage permission to the contributor. The contributors may ask themself to give this permission. The level of activity is not strictly defined, since it depends on the kind of contributions and their quality. The core developer is responsabile to estimate this. There is no formal vote to give the bug triage permission. The core developer becomes responsible of the promotion. In practice, core developers are free to discuss together ;-) Getting the bug triage permission gives more responsabilities to the contributor: the bug tracker should not be misused to not lost useful information. Taking a decision on an issue requires a certain level of knowledege of the Python development. I propose that the contributor gets a mentor during one month. The role of the mentor is to answer to any question of the mentoree, and help them to take decisions if needed. The mentor is not expected to watch closely what the contributor does on the bug tracker. If the contributor misuses the bug tracker, the mentor (or another core developer) should help the contributor to adjust their behaviour. If the contributor continue to abuse the bug tracker or misbehaves, the permission is removed and the contributor moves back to the previous step. This step is the opportunity to know each other, begin to create a trust relationship. Required skills for the contributor: * Be active on the Python project: bug tracker, pull requests and/or mailing lists like python-ideas and python-dev. There is no minimum number of contributions: it's not a matter of quantity, but more a matter of quality and the kind of contributions. * Be nice, police and respectful. * Know what they are talking about, and explain their reasoning well. Skills which are nice to have, but not required: * Know how to triage bugs. If the contributor doesn't know that, I consider that the role of the mentor is to explain this (using the devguide documentation). * Read the Python Developer Guide. This step is also a first milestone to measure the contrbutor involvment in the Python project, to later be able to estimate their "longterm commitement". == Step 3: Getting a mentor == Python project is big and has a long history. Contributors need a referrer to guide them in this wild and dangerous (!) project, and in the development workflow. The role of the mentor is to answer to contributors questions and review their work. The role is not to become the single gatekeeper merging all contributions of one specific contributor. It's perfectly fine if the mentor is unable to review a pull request, just help to find an appropriate reviewer in this case. This step is a second opportunity to build a trust relationship, maybe already started at the previous step with the same mentor. Required contributor skills: * Be active on the Python project: I would like to say "still" be active on the Python project, which is another proof of the contributor commitement in the project * Sign the CLA: at some point, getting changes merged into Git becomes mandatory, and so the CLA must be signed. * Find a mentor. Required mentor skills: * Be a core contributor. * Be available at least during one whole month. * Follow the contributor: must get an update at least once a week, especially if the contributor doesn't show up. Obviously, it's better if the contributor interest areas match with the mentor interest areas ;-) (... Maybe later we may change the process to allow non-core developers to become mentors, but I'm not sure about of this yet ...) If the contributor becomes unavailable, it's fine, it's just a small step backward, until they become available again. If the mentor becomes unavailable, maybe a different mentor can continue the process, otherwise the contributor goes back to the previous step. == Step 4: Core Developer == Once the mentor or another core developer consider that the contributor is mature enough to be promoted, a vote is organized on the python-committers mailing list. The contributor skills and contributions should be listed. Usually, any negative vote becomes a veto which blocks the promotion. While a few votes were negative in the past, I hope that this new formalized process would make the vote more natural and limit the "risk" of negative votes. Requirements to become a core developer: * Be nice and respectful * Humility * Long term commitement * Reviews * Know the CPython workflow * Know the CPython lifecycle * Know the Python C API specific issues, for contributors working on the C code * Good quality patches I described these requirements in detail at: http://cpython-core-tutorial.readthedocs.io/en/latest/core_developer.html#r… Becoming a core developer involves getting more responsabilities: * The core developer becomes the "owner" of a merged change: maintain the code and handle any potential regression * Review pull requests * Triage bugs The newly promoted core developer will followed by a mentor during one month until they become confortable enough. Obviously, the mentoring can be extended if needed. If the result of the promotion vote is negative, it's ok, move back to the previous step, and retry later. Usually the vote can be retried 6 months later, time spent to address lacking skills (maybe with a mentor). Hum, it seems like the contributor has been promoted: congratulations and welcome aboard! Victor

3 years, 4 months

Proposed schedule for next 3.4 and 3.5 releases - end of January / early February

by Larry Hastings

Howdy howdy. I know nobody's excited by the prospect of 3.4 and 3.5 releases--I mean, fer gosh sakes, neither of those versions even has f-strings! But we're about due. I prefer to release roughly every six months, and the current releases came out in early August. Here's my proposed schedule: Sun Jan 21 2017 - release 3.4.8rc1 and 3.5.5rc1 Sun Feb 04 2017 - release 3.4.8 final and 3.5.5 final Unless I'm presented with good reasons to change it, that'll be the schedule. I'll update the PEPs with the final release dates in about a week. Just for fun, I'll remind everybody here that 3.4 and 3.5 are both in security-fixes-only mode. This means two things: 1. These will be source-code-only releases; the Python core dev team won't release any more binary installers for 3.4 or 3.5. 2. I'm the only person permitted to accept PRs for 3.4 and 3.5. If you have security fixes for either of those versions, please add me as a reviewer. Happy holidays to you and yours, //arry/

3 years, 4 months

Statistics: growth of core dev number vs growth of the code size/complexity

by Victor Stinner

Hi, I wrote a quick & dirty parser to compute statistics on *new* CPython core developer per year using the following page as data: https://devguide.python.org/developers/ 2007: 15 2008: 19 2009: 11 2010: 20 2011: 12 2012: 9 2013: 4 2014: 10 2015: 2 2016: 5 2017: 2 Compare these numbers to Stéphane Wirtel's statistics on pull requests: https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests => Number of active core developerson on GitHub pull requests: 27 (stats from February 2017 to October 2017) (I'm not sure of the meaning of this number, it's the number of core developer who authored pull requests, I don't think that it counts core developers who only made reviews.) If you look at the size of the source code, it's still growing constanly since 1990: https://www.openhub.net/p/python/ 2007: around 783k lines 2010: around 683k lines 2013: around 800k lines 2015: around 875k lines 2017: around 973k lines The number of bugs is also constanly growing. Statistics on bugs since 2011: https://bugs.python.org/issue?@template=stats 2011: around 2500 open issues 2013: around 4000 open issues 2015: around 5000 open issues 2017: around 6200 open issues The size of the CPython project is constantly growing as its complexity (technical debt? what is this? :-)), but the growth of core developers is slowing down. I do consider that we need more people to handle the growing number of issues and pull requests, so the question is now how to find and "hire" (sorry, promote) them ;-) Maybe we have a problem with mentoring. Maybe the CPython code base became too hard to train newcomers? Maybe we are too conservative? I don't know. Victor

3 years, 4 months

Promote Julien Palard as core developer

by Victor Stinner

Hi, I propose to promote Julien Palard as a core developer. Julien Palard is leading the french translation of the Python documentation since 2 or 3 years. He spent a lot of time to try to get this translation online. Since he was unlucky on the python-ideas mailing list, I convinced him to write down a PEP. He wrote it with Naoki INADA (who is translated the documentation to Japanese) and me. It wasn't easy to write the PEP and get it approved: it took almost 1 year and a half! The PEP 545 was approved and implemented in Python 3.7! https://www.python.org/dev/peps/pep-0545/ Thanks to Julien (and others), translated documentations are now online at: https://docs.python.org/fr/ -- French https://docs.python.org/ja/ -- Japanese See also the What's New in Python 3.7 entry: https://docs.python.org/dev/whatsnew/3.7.html#documentation Julien spent a lot of time to fix a lot of various issues in the documentation, the docsbuild-scripts project used to build the CPython documentation, Sphinx, etc. to be able to translate properly the documentation. For me, the documentation and the docsbuild-scripts project are tightly coupled to the CPython project. Last june, I even asked to give the commit bit to Julien on the https://github.com/python/docsbuild-scripts/ project on this list, since I expected that this project was part of CPython (it isn't, it's another "team" on GitHub, if I understood correctly) :-) In the meanwhile, Julien became a "core developer" on this project as well. He also worked closely with the Python infra team to fix a few bugs when the translated documentation was published at python.org. To come back to CPython itself, Julien Palard already got 18 commits merged into the master branch since January 2016: 11 before GitHub ("patch by Julien Palard") + 7 since CPython migrated to GitHub ("Julien Palard" author). Most of his commits are related to the Python documentation content and tooling to build the documentation. He fixed "bugs" in the documentation, to clarify some documentation. Giving him the commit bit would ease his work, since too few people are looking at these areas of the code. When I reviewed his patches, they are usually good after one or two iterations, and Julien welcomes criticism. I know that Julien doesn't have the typical profile of core developers, only or mostly contribute to the code: Julien is currently focused on the doculmentation. But I believe (because he told me so ;-)) that Julien will slowly contribute to other areas of the code, once he will feel more confortable, and I may guide him in the code if needed. I think that many of us started to contribute to a project on its documentation ;-) I don't think that he needs an official menthor since he already knows well the CPython workflow, and he knows how to ask questions if needed ;-) Promoting Julien is part of my global idea/project of trying to recognize more contributions which are not strictly code, but as useful or even more useful than code! Python documentation is part of Python's success. I was told many times that Python has a good documentation, it's nice to hear that ! IMHO reducing CPython to its C and Python code is wrong and nor fair, CPython made of much more "sub-projects". Victor

3 years, 4 months

Adding Ivan Levkivskyi as a core committer

by Guido van Rossum

I'd like to propose Ivan Levkivskyi as a new core committer. He's (re-)written most of the typing.py module and will do so again for Python 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), is co-author on several more (483, 561) and has been acknowledged in yet others (557, 563). He is responsible for at least 16 commits in master. I have worked with him for a long time on typing.py and on mypy (where he is a core dev) and I can vouch for him completely. -- --Guido van Rossum (python.org/~guido)

3 years, 4 months

Cheryl Sabella was promoted to get bug triage permission

by Victor Stinner

Hi, To recognize the good contributions of Cheryl Sabella, I gave her the bug triage permission on bugs.python.org. (In practice, Ezio gave her the permission.) In the past, such "promotion" wasn't always advertized on python-committers, but my intent is to make our process more transparent and award people who deserve it! IMHO bug triage is the first step/milestone to become a core developer in the long term. FYI She pushed not less than 14 commits into the master branch since August, 2017. Congrats Cheryl! Victor

3 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers December 2017