4 ms·

I will say for all the (sometimes valid) complaints about NPM and the ecosystem, I don’t hear about Go. Go encourages package authors to simply link to their g

I will say for all the (sometimes valid) complaints about NPM and the ecosystem, I don’t hear about Go. Go encourages package authors to simply link to their git repository. It is quite literally cloning source files onto your computer without much thought

skydhash 2y ago
No code execution during dependency fetching. And the dependency tree is very shallow for most project, making it easier to audit.
- no_wizard 2y ago
  still no guard rails, simply raw source code. It would be easy for anything to be hiding within. Given observed behavior I doubt most people are auditing the source either It’s ripe for an exploit
  - robertlagrant 2y ago
    That's a different issue, which most libraries will have - when you run their code, they may do extra things. This is talking about the same thing, but at install time as well.
    - no_wizard 2y ago
      Two differences: Best practice now is to not run postinstall scripts by default. Yarn and pnpm allow you to do this (and pnpm at least won’t run them by default) and I believe npm now does too, and is looking at a future where it won’t run them by default. The other difference is Go had several chances to do better, and they didn’t take any steps to do so. The maintainers of NPM (the registry and tool) I’m sure would love to make a lot of changes to the ecosystem but they can’t make some of them without breaking too much, and at the scale that NOM operates it’s going to always be playing catch up with work around a and such for previous choices so they don’t say, break hundreds of thousands of CI runs simultaneously. Go iterated on its package ecosystem several times and ultimately did very little with it. They didn’t make it vastly more secure by default in any way, they were actually going to get rid of vendoring at one point, and a whole host of other SNAFUs. Go’s packaging and distribution model while simple is extremely primitive and they have yet to really adopt anything in this area that would be beneficial for security

skydhash 2y ago

No code execution during dependency fetching. And the dependency tree is very shallow for most project, making it easier to audit.

no_wizard 2y ago
still no guard rails, simply raw source code. It would be easy for anything to be hiding within. Given observed behavior I doubt most people are auditing the source either It’s ripe for an exploit
- robertlagrant 2y ago
  That's a different issue, which most libraries will have - when you run their code, they may do extra things. This is talking about the same thing, but at install time as well.
  - no_wizard 2y ago
    Two differences: Best practice now is to not run postinstall scripts by default. Yarn and pnpm allow you to do this (and pnpm at least won’t run them by default) and I believe npm now does too, and is looking at a future where it won’t run them by default. The other difference is Go had several chances to do better, and they didn’t take any steps to do so. The maintainers of NPM (the registry and tool) I’m sure would love to make a lot of changes to the ecosystem but they can’t make some of them without breaking too much, and at the scale that NOM operates it’s going to always be playing catch up with work around a and such for previous choices so they don’t say, break hundreds of thousands of CI runs simultaneously. Go iterated on its package ecosystem several times and ultimately did very little with it. They didn’t make it vastly more secure by default in any way, they were actually going to get rid of vendoring at one point, and a whole host of other SNAFUs. Go’s packaging and distribution model while simple is extremely primitive and they have yet to really adopt anything in this area that would be beneficial for security