For the ones who are worried about losing all credentials for their GitHub
account, here are some official answers from GitHub support.
---------- 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>
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
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
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.
*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
*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.
*Store a recovery token* If you use Facebook, you're now able to store a
2FA recovery token with your account. Here's how:
*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:
Let me know if you have any questions or if there's anything else we can
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
* 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):
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
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.
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:
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.
-Barry, Brett, Abhilash
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
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
== 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
This step is the opportunity to know each other, begin to create a
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
* 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
== 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
== 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
* Long term commitement
* 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:
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
Hum, it seems like the contributor has been promoted: congratulations
and welcome aboard!
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
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
Happy holidays to you and yours,
I wrote a quick & dirty parser to compute statistics on *new* CPython
core developer per year using the following page as data:
Compare these numbers to Stéphane Wirtel's statistics on 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:
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:
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
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
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:
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
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
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
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)
To recognize the good contributions of Cheryl Sabella, I gave her the
bug triage permission on bugs.python.org. (In practice, Ezio gave her
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