donaldstufft

6 ms·

1.
by donaldstufft 3y ago
There is zero chance we require biometrics on PyPI.
2.
by donaldstufft 3y ago
You can have multiple accounts associated with a single project, so each person can have their own account and you just add them all as owners to the projects. That can be annoying to keep in sync if you have a lot of projects, but we'
3.
by donaldstufft 3y ago
That's great! While we strive to make PyPI useful for everyone we totally understand that sometimes the trade offs we have to make just don't work for everyone so we try really hard to enable folks like yourself to be able to set
4.
by donaldstufft 3y ago
TOTP is a good choice, and helps a lot on keeping everyone's account safe! Thanks a lot for taking the time to investigate your options I do feel want to mention though (largely because I think it's pretty cool), that those securi
5.
by donaldstufft 3y ago
One important thing to remember here is that PyPI was originally started in 2002 as a weekend hack project that grew overtime to become the piece of critical infrastructure it is today. There's a lot of stuff in PyPI that exists as his
6.
by donaldstufft 3y ago
So there's a few things here: Firstly, Debian's mirror network URLs allow a mirror operator to attack the base Debian.org site if they rely on cookies on debian.org (they may not, I'm not sure). Specifically the `ftp.<coun
7.
by donaldstufft 3y ago
The root of trust for uploads is the listed of signatures maintained by the archive administrators, flat out. The requirement for having individual keys signed by Debian Developers just makes it easier for the archive administrators to deci
8.
by donaldstufft 3y ago
Well, AFAIK it's not clear that in the US the courts have the right to compel someone to modify their software in that way. The FBI holds that it does, but so far it's been fought and they've given up when they've tried
9.
by donaldstufft 3y ago
> Before you can submit packages to Debian you have to get an existing Debian developer to sign your PGP key. In Debian the trust flows downward from older developers to newer developers. This is not how signing works in Debian at a tech
10.
by donaldstufft 3y ago
This post is pretty misleading. PyPI still fully supports mirrors (though it is becoming increasingly hard to run a full mirror of PyPI, last I looked a full copy of PyPI is about 30TB). The only thing we ever removed was designating any pa
11.
by donaldstufft 3y ago
I would resign from PyPI before I ever allowed a backdoor to be installed. I haven't explicitly asked, but I would be very surprised if any of the other PyPI admins felt differently.
12.
by donaldstufft 3y ago
I agree that long lived GPG keys are a bad idea, which is yet another reason why the feature was a bad one, because it could only ever work with non expiring GPG keys.
13.
by donaldstufft 3y ago
Well PGP signatures has been part of PyPI for 18 years now, if someone was going to build a secure system on top of that, they would have by now. PyPI should implement it though, because fundamentally the question of who is authorized to re
14.
by donaldstufft 3y ago
Sometimes? There's no global policy of doing it in Debian, it's up to individual package maintainers inside of Debian to enable it (it defaults to off AFAIK) and to hardcode the key that they expect the package to be signed by. In
15.
by donaldstufft 3y ago
I don't believe that Maven Central's use of GPG is providing a meaningful security control here, so I would dispute the idea that they're doing it "right".
16.
by donaldstufft 3y ago
The current documented plans revolve around TUF ( https://peps.python.org/pep-0458/ , https://peps.python.org/pep-0480/ ). Those links have probably bit rotted a bit by now, progress has been slow o
17.
by donaldstufft 3y ago
> The PyPI admins can provide their own rationale, but this is my best understanding: they have known for years that PGP is bad, and have more or less tolerated it as a legacy feature because removing it was a low priority. The post I wr
18.
by donaldstufft 3y ago
The current expectation is it will be a combination of sigstore and TUF, but if someone proposes something better then we're open to that. Implementing those things takes time though.
19.
by donaldstufft 3y ago
I'm not a huge expert on Sigstore, but I believe it's better to think of sigstore as similar to Certificate Transparency than similar to GPG signatures. The idea being that signatures on sigstore are on a public log, so you can&#x
20.
by donaldstufft 3y ago
With my PyPI administrator hat on, we have absolutely zero desire to ban anyone from PyPI for anything other than their actions on PyPI and in the Python ecosystem (uploading malware, etc). If some class of users cannot use whatever signing
21.
by donaldstufft 3y ago
It is true that an unverified TLS session does prevent passive attacks it does not prevent against "active" attacks. The general consensus is that it's not a useful property to differentiate passive from active here, since
22.
by donaldstufft 3y ago
I wonder if the domain being `blog.pypi.org` tipped them off?
23.
by donaldstufft 3y ago
Assuming of course that the other attacker doesn't just MITM the first attacker. But this is a very silly threat model, "I want exactly one person to be able to attack me at a time".
24.
by donaldstufft 3y ago
With self signed certificates your ISP can just serve their own self signed certificate, and then inject ads into the recipe blog.
25.
by donaldstufft 3y ago
I don't believe they would. Looking at the top 20 packages in the last month by download (packages with hundreds of millions of downloads), only 1 of them shipped a GPG signature with their most recent release. I haven't asked the
26.
by donaldstufft 3y ago
The problem with TOFU is that it assumes long lived keys (itself a bad practice) OR it assumes that the end user will be fine with regular notices that the keys that have signed their packages have changed, and will be able to correctly dif
27.
by donaldstufft 3y ago
Nobody at PyPI is opposed to package signing, and removing or minimizing the damage that compromised infrastructure can do. However, GPG is not a good tool to build those features on top of, and the vestigial support for GPG signing that Py
28.
by donaldstufft 3y ago
Removing security features that don't work is a separate concern from making security features that do work. Nobody who has done any serious work on PyPI security in the past 15 years thinks that GPG will play a part in the future of
29.
by donaldstufft 3y ago
2005, https://github.com/pypi/legacy/commit/600f9383f8e7e0a2e60860...
30.
by donaldstufft 3y ago
Also, minisign, signify, sigstore are all much better than gpg for the problem of signing packages.

More ›