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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Removing PGP from PyPI

187 点作者 dlor将近 2 年前

21 条评论

tzs将近 2 年前
&gt; In the last 3 years, about 50k signatures had been uploaded to PyPI by 1069 unique keys. 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>Why not include the public key in the package?<p>99% of the time what I want out of package signing is to know that the new version of the package I&#x27;m downloading is from the same people as the old version. I don&#x27;t actually need to know <i>who</i> those people are...just that they are the same people as before.
评论 #36045953 未加载
评论 #36045901 未加载
评论 #36050894 未加载
Arnavion将近 2 年前
&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.<p>I don&#x27;t know if it applies to any of those 1069 keys, but note that there is a way of hosting PGP keys that does not depend on key servers: WKD <a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-koch-openpgp-webkey-service&#x2F;16&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-koch-openpgp-webkey-s...</a> . You host the key at a .well-known URI under the domain of the email address. It&#x27;s a draft as you can see, but I&#x27;ve seen a few people using it (including myself), and GnuPG supports it.
评论 #36045088 未加载
评论 #36047065 未加载
usr1106将近 2 年前
Isn&#x27;t that throwing out the baby with the bathwater? There seem to be non-neglible risks of installing malware from PyPI according to various headlines recently. But instead of improving security measures that don&#x27;t work well they just remove them?
评论 #36045618 未加载
评论 #36046375 未加载
评论 #36048157 未加载
评论 #36045697 未加载
eduction将近 2 年前
So they examined everything uploaded to PyPi with a signature over <i>three years</i>, including old versions, and classify those packages whose signing key is expired <i>today</i>, possibly years later, as &quot;impossible to meaningfully verify.&quot; Never mind that the package may have been verifiable with a valid key for a full year or two before the key expired, and in the meantime may have been superseded by a newer version.<p>They also say they can&#x27;t &quot;meaningfully verify&quot; packages if the key does not have &quot;binding identify information,&quot; by which they presumably mean automatically verifiable binding identity information, which usually means someone verified an email from keys.openpgp.org. This is a really narrow way to establish &quot;binding identity information.&quot; For example someone who is a PyPi author and publicly links their PGP key from a (https) website on the same domain as the email on the key would not count. A well known longtime PyPi author with a well known key would not count.<p>The ad hoc, out of band nature of how PGP keys are trusted is not remotely new - PyPi would have known from the very start of adopting PGP that many keys would not be automatically verifiable. It makes little sense to turn around now and act like this is some surprising thing.<p>This has the smell of &quot;we didn&#x27;t want to bother supporting PGP any more because it&#x27;s hard so we came up with an excuse.&quot;<p>No need for an excuse, though: Just be honest about it and let the chips fall where they may, if you really don&#x27;t want to support PGP. God knows there are valid reasons for not having the energy to deal with PGP. (FWIW I think it&#x27;s a good solution for packages, for those who can navigate the tooling, but on the other hand I&#x27;m not volunteering my time to run PyPi.)<p>P.S. There is a link in their post saying PGP has &quot;documented issues.&quot; The specific issue described in the linked document is &quot;packaging signing is not the holy grail&quot; and a list of known things about PGP, like that verification of keys is ad hoc. It also concludes that there is no known better alternative.
评论 #36048678 未加载
评论 #36048373 未加载
rwmj将近 2 年前
So they&#x27;re removing PGP signatures, which certainly have some issues, and replacing them with ... nothing?
评论 #36045608 未加载
评论 #36045678 未加载
评论 #36048289 未加载
评论 #36047336 未加载
zzzeek将近 2 年前
&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) 2.<p>so...*reject those packages*. if you use a PGP key that isn&#x27;t properly available or verifiable, reject it. That way every package with a PGP key will have 100% &quot;key is properly discoverable&quot; rate.<p>it&#x27;s not really reasonable to just drop this feature because most packages don&#x27;t use it. Packages with tens of millions of downloads (like mine) make up a small percentage of total packages, but this small number of packages makes up a huge proportion of actual downloads, and package signing is most useful for these kinds of packages.<p>if the adoption of &quot;proper PGP keys&quot; were ranked <i>by packages&#x2F; downloads</i> rather than &quot;packages&quot; alone, these rates would be much different.
评论 #36048575 未加载
评论 #36054822 未加载
jpgvm将近 2 年前
I don&#x27;t understand how Java can get this right with Maven Central and co but newer languages can&#x27;t.<p>Having a slight barrier to entry which is essentially &quot;you must learn why signing is important for users of your library and this is how to do it&quot;, a) really isn&#x27;t that bad and b) doesn&#x27;t result in less quality packages being uploaded c) if it acts like any sort of filter that seems to be a good thing.<p>Maven Central isn&#x27;t short of high quality packages and no high quality OSS Java libraries are missing so the filter aspect isn&#x27;t culling anything important.<p>Java, Apt, RPM, etc all have this and have absolutely gigantic numbers of packages so the argument that it&#x27;s too hard really just doesn&#x27;t hold water.<p>Doing so requires reading&#x2F;understanding these ~3 pages of docs: <a href="https:&#x2F;&#x2F;central.sonatype.org&#x2F;publish&#x2F;requirements&#x2F;gpg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;central.sonatype.org&#x2F;publish&#x2F;requirements&#x2F;gpg&#x2F;</a>
评论 #36052727 未加载
评论 #36050355 未加载
评论 #36050194 未加载
westurner将近 2 年前
Now that you have removed GPG ASC signature upload support, is there any way for publishers to add cryptographic signatures to packages that they upload to pypi? FWIU only &quot;the server signs uploads&quot; part of TUF was ever implemented?<p>Why do we use GPG ASC signatures instead of just a checksum over the same channel?
评论 #36044974 未加载
评论 #36045020 未加载
jwilk将近 2 年前
Two days ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36021172" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36021172</a> (&quot;PGP signatures on PyPI: worse than useless&quot;, &gt;150 comments)
WhyNotHugo将近 2 年前
When many developers didn&#x27;t use 2FA they pushed for them to enable 2FA within a deadline. It sounds like the same approach could have been used for PyPI. E.g.: an attempt to make the feature useful before declaring it dead forever.
评论 #36047381 未加载
评论 #36047983 未加载
bryanlyon将近 2 年前
I came here thinking they were removing the PGP package from PyPi, but they&#x27;re just removing a barely-used signature system? I don&#x27;t know why they have to remove it though. I doubt it requires much maintenance now that it&#x27;s already in place.<p>Even if only 37% of keys are verifiable, that&#x27;s infinitely more than will be verifiable if they remove the PGP support.
评论 #36047236 未加载
评论 #36047234 未加载
zokier将近 2 年前
At least you can&#x27;t blame pypi for ignoring the report, and tbh I find this response time remarkably quick. It wouldn&#x27;t have been far fetched to imagine someone in their position just trying to ignore&#x2F;downplay&#x2F;dispute this sort of reports.
评论 #36048025 未加载
评论 #36047430 未加载
jxy将近 2 年前
I don&#x27;t understand the argument. Isn&#x27;t the whole point of PGP establishing some kind of chain of trust? If pypi.org has it&#x27;s public key, it could sign a few major distributors&#x27;s keys, and for smaller&#x2F;individual packages I could either choose to always trust the same public key or don&#x27;t use the package. It&#x27;s not a centralized system to begin with. It&#x27;s not pypi.org&#x27;s responsibility to identify and verify all the keys belong to who say they belong. Pypi.org&#x27;s unable to verify individual identities shouldn&#x27;t impact the overall usefulness of the PGP for package distribution and verification.
NotYourLawyer将近 2 年前
Interesting timeline. The Yossarian article that TFA cites and that I assumed was the impetus here was published two days ago on 5&#x2F;21. But the audit was two days <i>earlier</i> on 5&#x2F;19.
评论 #36047684 未加载
reidrac将近 2 年前
I have been thinking about this in the context of Java libraries (really using Scala, but bear with me).<p>If the repo requires a GPG signature, they could also ask for the public key of the developer making the releases (e.g. when they make the account), and they could sign it with their key at that point.<p>Then make available the package, the signature, and the signed public key. Then I only need to trust the repo&#x27;s key (in this case PyPi).<p>Does this make any sense?
评论 #36046285 未加载
KRAKRISMOTT将近 2 年前
What are we switching to? Does Pypi support ECDSA?
评论 #36045205 未加载
评论 #36045231 未加载
评论 #36045230 未加载
sacnoradhq将近 2 年前
So how are Python packages signed? Are they just shipping rando code without any sort of E2E assurance?<p>FWIW, Ruby also did a piss-poor job of handling gem signing by making it both difficult and optional.<p>How fucking hard is it to get to the level of code release assurance as Debian or Fedora? Manage GPG keys, signfest them, and enforce a policy.
rvz将近 2 年前
PGP is a solution in search of a problem. We have given it decades for it to be useful and it turns out that it is an enormous security failure. It needed to go.<p>Sigstore [0] on the other hand makes more sense to use instead of problem.<p>[0] <a href="https:&#x2F;&#x2F;www.sigstore.dev" rel="nofollow">https:&#x2F;&#x2F;www.sigstore.dev</a>
评论 #36048185 未加载
评论 #36048484 未加载
7to2将近 2 年前
Trust on first use is absolutely a valid use of PGP signatures that is being used in many real world systems (ask me how I know). You finding that PGP isn&#x27;t being used they way you think it should does not justify removing it without providing a replacement.<p>Why on earth wasn&#x27;t the community asked before you implemented this change?<p>&gt; Given all of this, the continued support of uploading PGP signatures to PyPI is no longer defensible. While it doesn&#x27;t represent a massive operational burden to continue to support it, it does require any new features that touch the storage of files to be made aware of and capable of handling these PGP signatures, which is a non zero cost on the maintainers and contributors of PyPI.<p>This uninformed reasoning is what&#x27;s indefensible.
forgotmypw17将近 2 年前
What an amazing opportunity for someone to add a new way of integrating PGP authentication by writing two short scripts:<p>One to compile a list of file hashes and PGP-sign them.<p>One to validate these hashes against the provided signatures.
lgxz将近 2 年前
Replace a 31% effective solution with no solution? very impressive