4 ms·

I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use. However, there is one serious problem

I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use. However, there is one serious problem with Cargo's packages: They simply aren't authenticated. Cargo's developers acknowledge this issue and there is a proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to enjoy the attention it deserves. As a person living in a country that increasingly edging towards going the Kazakhstan route where all secure traffic will be MITMed, simply relying on transport security as a way to secure crates is not sufficient. and that's ignoring compromises due to server security failures. At present, my only options are to include the entire dependency tree in crate or avoid dependencies altogether. Even ignoring my problem (which wouldn't effect a large number of rust developers), Mixing transport security with authentication and integrity shouldn't happen in vital infrastructure like a language package system. There are other problems like not representing system libraries that a crate depends on in the project manifest, but unauthenticated crates are a ar more serious problem. [1]:https://github.com/rust-lang/crates.io/issues/75 https://github.com/rust-lang/crates.io/issues/75

wuch 11y ago
Is there a language package manager that you would consider a good role model in this respect?
- viraptor 11y ago
  Not the OP, but both rpm and deb have a pretty good validation story. Deb repositories (== package hashes) are gpg-signed for verification, but are usually provided over http for better caching. Nothing stops you from putting them on https either. Rpms can be signed at the package level as well.
- goodplay 11y ago
  I'm not aware of any language-specific package manager that gets close to having developer-package authentication, but chromium's add-on system comes pretty close as it requires add-ons be signed by the developer's private key (at least, that was the case before I stopped developing for it). I believe android's packages are secured in a similar fashion.
  - eurg 11y ago
    IIRC Common Lisp's asdf-install did use GPG signing from developers; IIRC-again, most people disliked it. Now quicklisp exists, which does _not_ use GPG; a quick google didn't reveal any info on package authentication. Maybe a lisper can chime in?
- afshin 11y ago
  npm allows using git+ssh URLs which would work with ssh keys, but I'm not sure if that scales to whole organizations.

wuch 11y ago

Is there a language package manager that you would consider a good role model in this respect?

viraptor 11y ago
Not the OP, but both rpm and deb have a pretty good validation story. Deb repositories (== package hashes) are gpg-signed for verification, but are usually provided over http for better caching. Nothing stops you from putting them on https either. Rpms can be signed at the package level as well.
goodplay 11y ago
I'm not aware of any language-specific package manager that gets close to having developer-package authentication, but chromium's add-on system comes pretty close as it requires add-ons be signed by the developer's private key (at least, that was the case before I stopped developing for it). I believe android's packages are secured in a similar fashion.
- eurg 11y ago
  IIRC Common Lisp's asdf-install did use GPG signing from developers; IIRC-again, most people disliked it. Now quicklisp exists, which does _not_ use GPG; a quick google didn't reveal any info on package authentication. Maybe a lisper can chime in?
afshin 11y ago
npm allows using git+ssh URLs which would work with ssh keys, but I'm not sure if that scales to whole organizations.