4 ms·

DNS isn't a particularly secure root of trust; Java is somewhat unique among package ecosystems for picking it as their trust anchor. It also just kicks the ca

DNS isn't a particularly secure root of trust; Java is somewhat unique among package ecosystems for picking it as their trust anchor. It also just kicks the can down the road: Amazon is the the easy case with `com.amazon`, but it isn't clear a priori whether you should trust `net.coolguy.importantpackage` or `net.cooldude.importantpackage`. These kinds of trust relationships require external communication of a kind that package indices are not equipped to supply, and should not attempt to solve haphazardly. > (I note you're part of pypa!) I am a member of PyPA, but I don't represent anyone's opinions but my own. It's a very loose collection of projects, and it would be incorrect to read a general opinion from mine.

blibble 4y ago
> Amazon is the the easy case with `com.amazon`, but it isn't clear a priori whether you should trust `net.coolguy.importantpackage` or `net.cooldude.importantpackage` this is a classic example of not letting perfect be the enemy of good there is no perfect solution, there never will be piggybacking off of DNS works extremely well for Java and Go (and the tooling is a pleasure to work with) meanwhile Python continues to be a complete disaster
- woodruffw 4y ago
  I agree there is no perfect solution. But I want a good solution, and I disagree that DNS is a good one.
  - blibble 4y ago
    I look forward to another 20 years of no progress!
    - woodruffw 4y ago
      Your cynicism isn't warranted: we've made significant improvements to PyPI over the last 4 years[1][2], and I'm currently working on additional features that will make secure publishing to PyPI easier[3]. We're also working on a codesigning implementation for PyPI, based on Sigstore[4]. Security needs to be evidence and outcome-driven, first and foremost. That takes a while, but improved outcomes make it worth it. [1]: https://pyfound.blogspot.com/2019/06/pypi-now-supports-two-factor-login-via.html https://pyfound.blogspot.com/2019/06/pypi-now-supports-two-f... [2]: https://pythoninsider.blogspot.com/2019/07/pypi-now-supports-uploading-via-api.html https://pythoninsider.blogspot.com/2019/07/pypi-now-supports... [3]: https://github.com/pypi/warehouse/issues/12465 https://github.com/pypi/warehouse/issues/12465 [4]: https://www.sigstore.dev/ https://www.sigstore.dev/
      - blibble 4y ago
        > That takes a while, but improved outcomes make it worth it. meanwhile the integrity of the supply chain continues to be compromised > Your cynicism isn't warranted it is: the python packaging situation is worse today than it was when I started writing Python in 2005 the legions of meetings, grandiose titles, conferences and mountains of unreadable proposals have produced tooling that is objectively worse than what Maven offered close to two decades ago
        woodruffw 4y ago
        In 2005, PyPI didn’t even host packages. It was an index that pointed you to the HTTP-only host that served the distribution. As far as I know, even basic hash checking wasn’t added until a decade later. I have no opinions about titles, etc. But saying that Python packaging was better in 2005 is incorrect along all axes.
charrondev 4y ago
I will note even namespaces for package management that don’t use DNS are a big step up over none. For example in PHP/composer/packagist and node/npm they just have a vendor name that can be reserved. It makes it very easy to distinguish “this package is from the (trusted vendor name here)” and prevents issues with namesquatting.

blibble 4y ago

> Amazon is the the easy case with `com.amazon`, but it isn't clear a priori whether you should trust `net.coolguy.importantpackage` or `net.cooldude.importantpackage` this is a classic example of not letting perfect be the enemy of good there is no perfect solution, there never will be piggybacking off of DNS works extremely well for Java and Go (and the tooling is a pleasure to work with) meanwhile Python continues to be a complete disaster

woodruffw 4y ago
I agree there is no perfect solution. But I want a good solution, and I disagree that DNS is a good one.
- blibble 4y ago
  I look forward to another 20 years of no progress!
  - woodruffw 4y ago
    Your cynicism isn't warranted: we've made significant improvements to PyPI over the last 4 years[1][2], and I'm currently working on additional features that will make secure publishing to PyPI easier[3]. We're also working on a codesigning implementation for PyPI, based on Sigstore[4]. Security needs to be evidence and outcome-driven, first and foremost. That takes a while, but improved outcomes make it worth it. [1]: https://pyfound.blogspot.com/2019/06/pypi-now-supports-two-factor-login-via.html https://pyfound.blogspot.com/2019/06/pypi-now-supports-two-f... [2]: https://pythoninsider.blogspot.com/2019/07/pypi-now-supports-uploading-via-api.html https://pythoninsider.blogspot.com/2019/07/pypi-now-supports... [3]: https://github.com/pypi/warehouse/issues/12465 https://github.com/pypi/warehouse/issues/12465 [4]: https://www.sigstore.dev/ https://www.sigstore.dev/
    - blibble 4y ago
      > That takes a while, but improved outcomes make it worth it. meanwhile the integrity of the supply chain continues to be compromised > Your cynicism isn't warranted it is: the python packaging situation is worse today than it was when I started writing Python in 2005 the legions of meetings, grandiose titles, conferences and mountains of unreadable proposals have produced tooling that is objectively worse than what Maven offered close to two decades ago
      - woodruffw 4y ago
        In 2005, PyPI didn’t even host packages. It was an index that pointed you to the HTTP-only host that served the distribution. As far as I know, even basic hash checking wasn’t added until a decade later. I have no opinions about titles, etc. But saying that Python packaging was better in 2005 is incorrect along all axes.

charrondev 4y ago

I will note even namespaces for package management that don’t use DNS are a big step up over none. For example in PHP/composer/packagist and node/npm they just have a vendor name that can be reserved. It makes it very easy to distinguish “this package is from the (trusted vendor name here)” and prevents issues with namesquatting.