> If you trust the repository to deliver to you the expected signing key and the package to be verified you’ve gained nothing and introduced complexity. If yo

> If you trust the repository to deliver to you the expected signing key and the package to be verified you’ve gained nothing and introduced complexity. If you've been using a package for some time and suddenly the key changes, that's auditable. It won't impact anyone whose first use is after that point, and it's unlikely that end users will care, but for an organization, sure, that's meaningful. I'd go open an issue and ask why that happened, and pay attention to that commit. > What you’re not doing, and what there is no method of doing to my knowledge, is gaining any assurance that the person whose identity you’ve verified has any right to sign the package you’re verifying. Presumably we can just do what the web does with certificates tied to domains. > Another suggestion I’ve seen is adopting a model similar to that of SSH, that is the first time you install a package you’re prompted to accept the key and from then on out it will remember that and use that as the trusted key. Ah nice, this addresses my first point. > Packages on PyPI change hands, get deleted, or even have multiple authorized releasers. This is a feature :P I definitely want to know if a package changes hands! As for having multiple keys valid for a single package, I feel like that isn't much of an issue? I think we can look at certificates again for how this would work. > If they go to PyPI to find out then we are back again at trusting the repository implicitly. If they don’t go to PyPI they are most likely to just hit whatever lets them install, training them to just do what it takes to install and ignore the warnings and prompts For users, yes. For organizations, no. I'll absolutely investigate why a key changed. And when I see that it's malicious I'll let users know, just cause I'm so nice. > Even if we wave our hands and give ourselves the perfect way to transmit trust, as long as PyPI is the authority over who owns a particular name then we must implicitly trust PyPI to tell us who is allowed to release which packages. I'm confused by this part. Why is that the case? If I sign on my machine before I push to PyPI, how would PyPI be the authority? Unless this is referring to "PyPI can change the public key", which is true, but as I mentioned that's auditable and will raise lots of flags. > It’s important to remember that the only thing any of these systems are able to verify is that the package you’ve fetched is the package you wanted, nothing more. For sure. > This isn’t an already solved problem nor is it an easy to solve one. Yeah, unfortunately the tooling just isn't really there, so the UX is weak, so no one does it... and it's hard to go back and retroactively do so. In an ideal world this would all sort of Just Work, and it would be universal, so you could cryptographically verify your packages, your commits, your builds, your binaries, your containers, etc. I wouldn't blame anyone for not doing these things today. There's no support for it. But if we got support, it would be a win.