PyPI account recovery process triaging on halt

It’s not just the Python community, but pretty much everywhere in
free/libre open source communities. This was an interesting summary
that made the rounds on Friday and over the weekend:

1 Like

That’s not really the same problem… here there have actually been several people ready to volunteer some time to help and been told (obs: paraphrasing is going to make this sound harsher than it actually has been) Sorry, mate, don’t bother, you won’t be able to get past the trust barrier.

4 Likes

To be clear, the “trust barrier” isn’t simply about the PyPI admins not trusting people who offer help - it’s about whether you as an individual (along with every other Python developer) are willing to let those people have admin access to all of your projects on PyPI. And how the PyPI admins, as custodians of that level of access, respect your wishes in that matter.

Would I trust @tarekziade with access to all PyPI projects? Maybe. I know Tarek, and he is a core dev and a respected contributor to the packaging ecosystem. But it’s still a hard call, and if I get it wrong, am I willing to take responsibility for the damage that might be caused? Frankly, no. And I suspect the PyPI admins feel similarly. (Please note, by the way - I have no involvement in the actual decision making here, I’m just trying to clarify why I think this is not an easy problem to fix).

Maybe there’s a level of help that could be usefully offered by someone without giving them admin level access, and yet which isn’t something they can do right now (anyone can write a review on a github issue, for example - that needs no trust). I don’t know the answer to that.

1 Like

That’s not really the same problem… here there have actually
been several people ready to volunteer some time to help and been
told (obs: paraphrasing is going to make this sound harsher than
it actually has been) Sorry, mate, don’t bother, you won’t be
able to get past the trust barrier.

It’s shades of the same problem. The limited set of people who do
currently have the necessary trust and access to do these tasks are
busy with other tasks, at least some of which probably could be
handled by volunteers who are new on the scene, freeing up the
current admins’ time to actually focus on the things only they can
at present. Newcomers participating in those less-risky activities
can demonstrate their trustworthiness if they’re able to stick with
it for years and not burn out. Access to reset (and therefore take
over) anyone’s account and releases on PyPI understandably requires
a very high level of trust from the community and the existing
admins. What they likely need is volunteers offering to take the
boring and thankless low-trust-barrier activities off their hands.

I manage systems for some other open source communities, and this is
a challenge we all face. Onboarding a volunteer and getting them to
the point where I personally trust them with that sort of access
takes years. The people who have that sort of access have been
involved in our projects for a decade or more. New volunteers start
out with very minimal access and over time they earn our trust. All
too often people are eager to help, but disappear on you in a matter
of months after you’ve invested loads of your time mentoring and
guiding them.

It’s a vicious cycle too. If you’re already overloaded with these
responsibilities, it’s hard to force yourself to let even more of
them fall by the wayside so you can find the time necessary to train
someone up to help, or even to respond to forum discussions where
people are volunteering their time. My colleagues and I, in recent
years, made some very hard decisions to basically shut down a lot of
the services we were maintaining (and that members of our
communities were relying on) so that the admins would have time to
engage with and mentor potential volunteers, or even to just take a
vacation once in a while without worrying about being able to keep
an eye on IRC and having SSH access to the servers from wherever
we’re headed.

1 Like

Can someone who knows describe the actual discrete steps in the process to perform an account recovery? Is there some manner of investigation or verification or other legwork involved that could be triaged by a wider group of people before credentials are involved?

4 Likes

The details are at:

1 Like

This seems like the biggest issue to me. In one way it seems to have made the situation worse, in that now the volume of recovery requests is likely to increase since every project is now subject to the requirements. (In other ways, of course, it hopefully made the situation better, since now presumably there is a lower likelihood of needing emergency damage control due to a popular package being compromised.)

With regard to PyPI or other Python tasks, is there a clear place for people to find out what those low-barrier tasks are and how to do them? (Or is creating such “onboarding” docs itself something that falls by the wayside due to the same vicious cycle you mentioned? :upside_down_face: )

1 Like

Thanks. I see some steps that can be performed by a volunteer that does not have fuill access to PyPI admin.

A copy of the steps:

  1. Look up User in PyPI admin
  2. Ensure that the report and status of their 2FA enrollment match up. If alternative 2FA method exists (TOTP, WebAuthn, or Recovery Codes) notify user to use one of those.
  3. Determine what projects the User has Owner/Maintainer status on. If no projects are associated with the User, immediately perform 2FA reset.
  4. Determine how many unique public source code repositories are associated with the Users Projects based on releases of the Project from before the request. For each security boundary such as a GitHub org or code hosting service.
  5. Send email template below requesting that a branch with a randomly generated secret is pushed to a repository in each security boundary.
  6. Once the user has responded to confirm that the branches have been pushed, go through and verify that each branch exists on the source code repository from the metadata of a release from before the request.
  7. Issue 2FA reset and password reset for the issue.

As a volunteer this is what I could do:

  1. ask the user if they have recovery codes. maybe not, but I can ask directly. because right now, PyPI admins look at that in the DB and tells the user “use your recovery code” — and then the user is most likely to answer “I lost them” and we are back to square one for months
  2. look up the list of projects the user own and maintain, if none, it’s triaged to “no risk of reset” – if PyPI admins wants to verify later, or just trust that was true. Heck, this step can be automated with a script!
  3. look up the open source projects and give instructions to the user to set up a branch and wait for confirmation. Once done, triage it “verification ready”

I think people that have been around for a bit can be trusted to do that, that won’t access the admin and once it’s done, the work remaining for PyPI admins is minimal.

WDYT?

At least it helps maintaining the communication with the users before they give up and start coding in Rust instead :wink:

2 Likes

Thinking about it again, I don’t see any reason why someone with no project released on PyPI can’t have its 2FA reseted automatically. What am I missing ? Not sure if this is a bit percentage but it is easy to automate

Do you want someone else to be able to reset your account’s 2FA without your permission? If not, how do you ensure that only YOU can get your account’s 2FA reset?

1 Like

I am talking about the people who asked for it. I am not sur to understand how it is different from the step the PyPI admin takes. You would still need to perform normal authentication.

Please, pretty please @dustin @EWDurbin or @dstufft can you answer to my proposal?

What can I do to help. If it means taking some of your boring day-to-day work for a while so you have time to triage those bugs, I will do it.

Telling me I can’t help because I am not trusted is not an answer I will take anymore. This is not how the Python community works.

1 Like

I don’t know what you are implying, but as a member of the Python community, I do NOT trust you with my account credentials at PyPI. Trust has to be earned, not demanded.

I am not here to earn your trust, Chris, I am here to point out that if this process relies on people that clearly don’t have time to do it, it is broken. Same goes for PEP 541 PEP 541 Request: Kconfiglib · Issue #2526 · pypi/support · GitHub

So I won’t stop this thread until we find a solution where I can help (without your trust)

5 Likes

Just curious, which authenticator app were you using? Why didn’t you restore the phone data to another device?

(FWIW, Tarek has substantially contributed to packaging in the past so he’s not just some random user.)

3 Likes

I was using Google Authenticator but changed work in the interim (so different account/email).
I had the recovery codes on a backup and on the phone, and thought I copied them in a secure note in bitwarden as well but it’s not the case. So it’s an unfortunate sequence.

Regardless of the issue of lacking volunteers, if Tarek happens to come to Paris I can meet him and vouch for his identity (though I haven’t meant him for years and @tarekziade may also be a talented impersonator :slight_smile: ). Perhaps that would ease the 2FA recovery process…

2 Likes

haha it’s just me older Antoine :wink:

1 Like

What do you mean by ‘in the interim’? Did you change your email before the phone crash or after the phone crash?

You should try restoring them from the last email you used on your phone.