5 ms·

Almost all programming languages now have similar standard package managers. I still remember back in the day when everybody would joke about how Maven download

Almost all programming languages now have similar standard package managers. I still remember back in the day when everybody would joke about how Maven downloads the whole internet on the first build. This is still true today for Maven, NPM, pip, composer, you name it. You are downloading hundreds of packages for which you implicitly trust their maintainer to not do anything shady. In case of Maven - and likely most others - packages are not even digitally signed by the publisher and on top of it are binaries, that you cannot easily inspect. I'd argue NPM is slightly better than that, at least it (often) includes the source code, though you still have illegible instructions in form of minified/uglified code. I think NodeJS already has a decent stdlib and there will always be the need to pull dependencies in for basic functionality (apache commons, guava etc. in the Java world). That's just how OSS works. There should be a simple way to display and verify the chain of trust though.

strken 8y ago
NodeJS has a feature-rich standard library, but it's let down by poor ergonomics. Compare, for example, the built-in http library[0] with request-promise[1]. I think the difficulty of using the standard library makes NodeJS devs feel better about downloading lots of little helper libraries. [0] https://nodejs.org/api/http.html#http_http_request_options_callback https://nodejs.org/api/http.html#http_http_request_options_c... [1] https://github.com/request/request-promise#cheat-sheet https://github.com/request/request-promise#cheat-sheet
- WorldMaker 8y ago
  I think a lot of it is NodeJS settling on its standard library a bit ahead of the larger language ecosystem itself. Promises were standardized shortly after Node bumbled into a callback-heavy design. The efforts on the ES2015 Module syntax occurred after Node settled for "CommonJS" which wasn't all that common at the time. Node's HTTP library as a specific example, particularly suffers from callbacks instead of promises. It also suffers here in that it also predates the Fetch standard making its way into browsers now. Hopefully the Node standard library will continue to converge with the overall JS ecosystem and catch up to the work that the Browsers have been leading here.
jxub 8y ago
Hopefully somebody will apply blockchain to to a trust management system for OSS.
- dane-pgp 8y ago
  I don't know if you're joking, or if the people downvoting you think that your idea isn't worth hearing, but it's actually a good idea (if we can look past our snobbishness about how over-hyped blockchain technology has become). Part of the threat model around malicious software updates requires that we implement reproducible builds and store the hashes of builds in a distributed permissionless append-only database. There are proposals like EthIKS: http://www.jbonneau.com/doc/B16b-BITCOIN-ethiks.pdf http://www.jbonneau.com/doc/B16b-BITCOIN-ethiks.pdf which implements public key transparency in the Ethereum blockchain, using smart contracts, and there are ideas for implementing the gossip feature of certificate transparency logs using blockchains: https://blog.okturtles.org/2015/03/certificate-transparency-on-blockchains/ https://blog.okturtles.org/2015/03/certificate-transparency-... Binary transparency can be thought of as just a special case of certificate transparency: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
rmc 8y ago
I think the problem is the sheer number of dependencies, which introduces more chances for something to go wrong.
symtos 8y ago
> In case of Maven - and likely most others - packages are not even digitally signed by the publisher Last time I explored the atrocious state of language-specific package managers, Maven Central was (and I'm guessing still is) the only language repo that requires that packages are signed [1][2]. Now, whether package signatures are verified on retrieval is another question... (they are not, unless you use a plugin such as pgpverify-maven-plugin [3]). Obviously anybody with the private key can still introduce malicious code even if you verify your package signatures, but at least it's better than allowing any oppressive regime with a root CA trusted by Mozilla/Microsoft to MITM rust/python/npm/ruby/whatever packages downloaded by its residents. [1] https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... [2] http://central.sonatype.org/pages/working-with-pgp-signatures.html http://central.sonatype.org/pages/working-with-pgp-signature... [3] https://github.com/s4u/pgpverify-maven-plugin https://github.com/s4u/pgpverify-maven-plugin

strken 8y ago

NodeJS has a feature-rich standard library, but it's let down by poor ergonomics. Compare, for example, the built-in http library[0] with request-promise[1]. I think the difficulty of using the standard library makes NodeJS devs feel better about downloading lots of little helper libraries. [0] https://nodejs.org/api/http.html#http_http_request_options_callback https://nodejs.org/api/http.html#http_http_request_options_c... [1] https://github.com/request/request-promise#cheat-sheet https://github.com/request/request-promise#cheat-sheet

WorldMaker 8y ago
I think a lot of it is NodeJS settling on its standard library a bit ahead of the larger language ecosystem itself. Promises were standardized shortly after Node bumbled into a callback-heavy design. The efforts on the ES2015 Module syntax occurred after Node settled for "CommonJS" which wasn't all that common at the time. Node's HTTP library as a specific example, particularly suffers from callbacks instead of promises. It also suffers here in that it also predates the Fetch standard making its way into browsers now. Hopefully the Node standard library will continue to converge with the overall JS ecosystem and catch up to the work that the Browsers have been leading here.

jxub 8y ago

Hopefully somebody will apply blockchain to to a trust management system for OSS.

dane-pgp 8y ago
I don't know if you're joking, or if the people downvoting you think that your idea isn't worth hearing, but it's actually a good idea (if we can look past our snobbishness about how over-hyped blockchain technology has become). Part of the threat model around malicious software updates requires that we implement reproducible builds and store the hashes of builds in a distributed permissionless append-only database. There are proposals like EthIKS: http://www.jbonneau.com/doc/B16b-BITCOIN-ethiks.pdf http://www.jbonneau.com/doc/B16b-BITCOIN-ethiks.pdf which implements public key transparency in the Ethereum blockchain, using smart contracts, and there are ideas for implementing the gossip feature of certificate transparency logs using blockchains: https://blog.okturtles.org/2015/03/certificate-transparency-on-blockchains/ https://blog.okturtles.org/2015/03/certificate-transparency-... Binary transparency can be thought of as just a special case of certificate transparency: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency

rmc 8y ago

I think the problem is the sheer number of dependencies, which introduces more chances for something to go wrong.

symtos 8y ago

> In case of Maven - and likely most others - packages are not even digitally signed by the publisher Last time I explored the atrocious state of language-specific package managers, Maven Central was (and I'm guessing still is) the only language repo that requires that packages are signed [1][2]. Now, whether package signatures are verified on retrieval is another question... (they are not, unless you use a plugin such as pgpverify-maven-plugin [3]). Obviously anybody with the private key can still introduce malicious code even if you verify your package signatures, but at least it's better than allowing any oppressive regime with a root CA trusted by Mozilla/Microsoft to MITM rust/python/npm/ruby/whatever packages downloaded by its residents. [1] https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... [2] http://central.sonatype.org/pages/working-with-pgp-signatures.html http://central.sonatype.org/pages/working-with-pgp-signature... [3] https://github.com/s4u/pgpverify-maven-plugin https://github.com/s4u/pgpverify-maven-plugin