TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Removing PGP from PyPI (2023)

72 点作者 harporoeder7 个月前

16 条评论

woodruffw7 个月前
This is slightly old news. For those curious, PGP support on the modern PyPI (i.e. the new codebase that began to be used in 2017-18) was always vestigial, and this change merely polished off a component that was, empirically[1], doing very little to improve the security of the packaging ecosystem.<p>Since then, PyPI has been working to adopt PEP 740[2], which both enforces a more modern cryptographic suite and signature scheme (built on Sigstore, although the design is adaptable) and is bootstrapped on PyPI&#x27;s support for Trusted Publishing[3], meaning that it doesn&#x27;t have the fundamental &quot;identity&quot; problem that PyPI-hosted PGP signatures have.<p>The hard next step from there is putting verification in client hands, which is the #1 thing that actually makes any signature scheme actually useful.<p>[1]: <a href="https:&#x2F;&#x2F;blog.yossarian.net&#x2F;2023&#x2F;05&#x2F;21&#x2F;PGP-signatures-on-PyPI-worse-than-useless" rel="nofollow">https:&#x2F;&#x2F;blog.yossarian.net&#x2F;2023&#x2F;05&#x2F;21&#x2F;PGP-signatures-on-PyPI...</a><p>[2]: <a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0740&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0740&#x2F;</a><p>[3]: <a href="https:&#x2F;&#x2F;docs.pypi.org&#x2F;trusted-publishers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.pypi.org&#x2F;trusted-publishers&#x2F;</a>
评论 #41875939 未加载
politelemon7 个月前
This feels like perfect being the enemy of good enough. There are examples where the system falls over but that doesn&#x27;t mean that it completely negates the benefits.<p>It is very easy to get blinkered into thinking that the specific problems they&#x27;re citing absolutely need to be solved, and quite possibly an element of trying to use that as an excuse to reduce some maintenance overhead without understanding its benefits.
评论 #41874198 未加载
评论 #41874289 未加载
jacques_chester7 个月前
I performed a similar analysis on RubyGems and found that of the top 10k most-downloaded gems, less than one percent had valid signatures. That plus the general hassle of managing key material means that this was a dead-end for large scale adoption.<p>I&#x27;m still hopeful that sigstore will see wide adoption and bring authorial attestation (code signing) to the masses.
评论 #41874263 未加载
bjornsing7 个月前
Does it matter much if the key can be verified? I mean it seems like a pretty big step up security wise to know that a new version of a package is signed with the same key was previous versions.
评论 #41874734 未加载
SethMLarson7 个月前
I&#x27;ve authored a proposal to deprecate the expectation of PGP signatures for future CPython releases. We&#x27;ve been providing Sigstore signatures for CPython since 3.11.<p><a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0761&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0761&#x2F;</a>
rurban7 个月前
On the other hand PGP keys were widely successful for cpan, the perl5 repo. It&#x27;s very simple to use, not as complicated as with pypi.
评论 #41874424 未加载
upofadown7 个月前
&gt; Of those 1069 unique keys, about 30% of them were not discoverable on major public keyservers, making it difficult or impossible to meaningfully verify those signatures. Of the remaining 71%, nearly half of them were unable to be meaningfully verified at the time of the audit (2023-05-19).<p>A PGP keyserver provides no identity verification. It is simply a place to store keys. So I don&#x27;t understand this statement. What is the ultimate goal here? I thought that things like this mostly provided a consistent identity for contributing entities with no requirement to know who the people behind the identities actually were in real life.
评论 #41874649 未加载
评论 #41874636 未加载
hiatus7 个月前
Should be tagged 2023.
badgersnake7 个月前
Most people do security badly so let’s not do it at all.<p>Right.
评论 #41874455 未加载
aborsy7 个月前
What’s the current best solution for associating a public key to an identity or person?<p>This is not related to cryptography protocols.<p>OpenPGP key server verifies email. Keybase was a good idea but seems dead. Maybe identity providers?
评论 #41875876 未加载
评论 #41877177 未加载
dang7 个月前
Discussed at the time:<p><i>Removing PGP from PyPI</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36044543">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36044543</a> - May 2023 (187 comments)
opello7 个月前
Wouldn&#x27;t another very good answer be for PyPI to have a keyserver and require keys be sent to it for them to be used in package publishing?
评论 #41874253 未加载
评论 #41874175 未加载
nonameiguess7 个月前
I feel like there is a broader issue being pushed aside here. Verifying a signature means you have a cryptographic guarantee that whoever generated an artifact possessed a private key associated with a public key. That key doesn&#x27;t necessarily need to be published in a web-facing keystore to be useful. For packages associated with an OS-approved app store or a Linux distro&#x27;s official repo, the store of trusted keys is baked into the package manager.<p>What value does that provide? As the installer of something, you almost never personally know the developer. You don&#x27;t really trust <i>them</i>. At best, you trust the operating system vendor to sufficient vet contributors to a blessed app store. Whoever published package A is actually a maintainer of Arch Linux. Whoever published app B went through whatever the heck hoops Apple makes you go through. If malware gets through, some sort of process failed that can potentially be mediated.<p>If you&#x27;re downloading a package from PyPI or RubyGems or crates.io or whatever, a web repository that does no vetting and allow anyone to publish anything, what assurance is this giving? Great, some package was legitimately published by a person who also published a public key. Who are they exactly? A pseudonym on Github with a cartoon avatar? Does that make them trustworthy? If they publish malware, what process can be changed to prevent that from happening again? As far as I can tell, nothing.<p>If you change the keystore provider to sigstore, what does that give you? Fulcio just requires that you control an e-mail address to issue you a signing key. They&#x27;re not vetting you in any way or requiring you to disclose a real-world identity that can be pursued if you do something bad. It&#x27;s a step up in a limited scope of use cases in which packages are published by corporate entities that control an e-mail domain and ideally use their own private artifact registry. It does nothing for public repositories in which anyone is allowed to publish anything.<p>Fundamentally, if a public repository allows anyone to publish anything, does no vetting and requires no real identity disclosure, what is the basis of trust? If you&#x27;re going to say something like &quot;well I&#x27;m looking for .whl files but only from Microsoft,&quot; then the answer is for Microsoft to host its own repository that you can download from, not for Microsoft to publish packages to PyPI.<p>There are examples of making this sort of simpler for the consumer to get everything from a single place. Docker Hub, for instance. You can choose to only ever pull official library images and verify them against sigstore, but that works because Docker is itself a well-funded corporate entity that restricts who can publish official library images by vetting and verifying real identities.
bee_rider7 个月前
I dunno, not all projects are equally important or popular, so it seems to me that the number of <i>downloads</i> which had keys is the better metric to look at.<p>But, if there are fundamental issues with the key system anyway, the percentages don’t matter anyway.
评论 #41874682 未加载
troismph7 个月前
I am curious why we still need PyPI to hold packages: it may be better to install from github.<p>Github provides much better integrated experience: source code, issues, docs, etc.
评论 #41875805 未加载
exabrial7 个月前
Not Invented Here!