A defunct project of mine has been categorized as "critical"

And as counterpoint, upload tokens can be created without enabling
2FA, right? At least presently, PyPI gives me a button I can click
to “Add API token” even though I haven’t enabled 2FA. (Note I’m not
arguing against using 2FA, just that it appears to still be a
workaround/loophole there at the moment.)

Will that be changing as well?

This would seem to be a feature, not a bug, no, as it means maintainers don’t have to enable 2FA to gain the security benefits of using a per-project token rather than a username/password to upload distributions? Obviously the happy path would be that everyone uses 2FA (which will, as I understand it, is or will be required for maintainers of critical packages), but I’m not sure its a net positive to restrict other security features from those who don’t have it yet.

1 Like

Feature yes, but then that makes the mass notification we received
doubly wrong if API tokens can be used to upload packages, and
therefore “create releases” for critical projects, even if 2FA has
not been enabled at the time it becomes required (and assuming
username/password based uploads are also disallowed at that time).

I get that some advance notification of the upcoming 2FA requirement
was warranted, and the encouragement for maintainers of critical
packages to start using it, but inaccuracies in the messaging leave
me uncertain of the intended future behaviors for the platform.

Update… I’ve been in touch with two people (Ethan and Doug) and removed them with their consent. That leaves me, openstackci, and one other person (Richard). @fungi is that who you were liasing with? Note that if OpenStack peeps are still interested in maintaining the package, I’m happy to remove myself as an owner.

I don’t know Richard. Doug is the colleague I was thinking of.

I doubt OpenStack contributors will need to fix anything in lockfile
given how long it’s been since we originally migrated off of it
(from what I can see, the library seems to have crept back into our
indirect dependencies several years later in 2018 when a project
started to use ansible-runner for some things).

I’m still trying to use this as a way to get the folks using
ansible-runner to help move it or python-daemon off lockfile, but
I’ll see what they think about us removing the openstackci account
from lockfile’s maintainer list as a near term step.

The maintainers for the OpenStack subproject relying on
ansible-runner have confirmed they’re comfortable with the OpenStack
project no longer having access to upload new releases for lockfile,
so I’m good with removal of the openstackci owner role now.
Unfortunately it looks like Warehouse won’t allow an account to remove
itself as a collaborator, so @smontanaro please feel free to remove
it at your convenience. Thanks for all your work, help and patience
with this over the years!

Thanks. I removed openstackci. I had no way to get in touch with rpmoseley, and lockfile was his only project.

That leaves me. Now to try and figure out what other stuff still relies on lockfile so I can try and deprecate the package.

1 Like