5 ms·

Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely ch

Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.

rich_sasha 5y ago
In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.
- cerved 5y ago
  look at diffs?
  - apetresc 5y ago
    Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
    - dane-pgp 5y ago
      Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
      - naasking 5y ago
        Nice link, thanks! Good to see Mark Miller is still working in this space.
    - cerved 5y ago
      I look at gits diffs to see what's changed between versions, but that's for fun and not diligence. > With the level of scrutiny required to detect a maliciously-obfuscated security exploit Nope. Not paid to do that and I have not been given any such responsibility. That said, I think the attack vector on this is very low. Packages are rarely updated to the latest version. We don't use a lot of packages. We mostly use packages from trusted sources. We use packages that are open source.
    - rich_sasha 5y ago
      And frankly, not just diffs. You’d need to inspect the initial state, and any new dependency added. That’s potentially hundreds of thousands of LoC.
  - deathanatos 5y ago
    I actually do this, on occasion. (Not 100%, and not to a degree I'd say "yeah, I'd've caught this colors/fakers thing." But enough to say that I've seen a decent sample.) There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality. I've had to roll-back / hard-pin dependencies from both low-quality FOSS & low-quality paid projects because of commits that — once you find & read them — are just bananas. (I have no idea how to solve the root problem here, honestly.)
    - cerved 5y ago
      > I have no idea how to solve the root problem here I'm not even sure what the problem is. If it's "updating dependencies introduces severe side effects" wich, I think, should be accounted for in the process
tablespoon 5y ago
> Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time. It seems like the problem here is more cultural than technical, specifically that the JavaScript community has fully embraced packages that are "written by randos" that are "wrappers around three-line Stack Overflow answers." I use packages, but I wouldn't use any that are developed by a rando with no reputation or "institutional oversight." An important part of choosing to use one is evaluating the maintainers. Does the JavaScript ecosystem have anything like Apache Commons? I'm guessing not, but it probably should.
- KennyBlanken 5y ago
  Not just that they've fully embraced the "written by randos" but even worse: "as soon as the rando publishes an update or change, use it!" They seem to fully automate updates because packages are so poorly written (and frankly, it probably helps with revenue stream, if their client's websites occasionally break and need them to fix it.) ...and meanwhile NPM's idea of vetting packages is basically "YOLO, BRO!"
- oblio 5y ago
  It's both technical and cultural. Javascript is used on the front end. Front end devs obsess (or at least used to obsess) over download sized. So you'd have crazy stuff like custom builds of Underscore (https://underscorejs.org/ https://underscorejs.org/) with just the functions you wanted. Think manual sandboxing, if that makes any sense. You could get a package of Underscore with just map, filter and reduceRight, if you wanted to. Now, when Node came around, people wanted as much as possible to have the same libraries available on the front end, so the same obsession with size was carried over. Ergo the micro-milli-nano-packages they make. Now, about the technical solution to this. We have this, for well defined programming languages (read: statically typed ones, or dynamically typed ones with a clear structure). It's a linker. Tech from the 1950s. Link (include) just the stuff you want, "tree shake"/"remote dead code" whatever you don't. https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-have-a-linker/ https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... Java's largely to blame for this, Sun REALLY, REALLY hated stuff that could be hooked into any OS and wasn't portable, so they didn't provide a linker. Everything was supposed to be on their JVM and you were going to install their JVM everywhere (2 billion devices!!!) and to hell with small stuff or heaven forbid, including native libraries. Javascript followed (on top of the Java restrictions they added: dynamic, poorly defined language, that would have made linking with tree shaking really hard, anyway). .Net also followed. Almost 3 decades later we're trying to undo that damage.

Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.

rich_sasha 5y ago

In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.

cerved 5y ago
look at diffs?
- apetresc 5y ago
  Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
  - dane-pgp 5y ago
    Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
    - naasking 5y ago
      Nice link, thanks! Good to see Mark Miller is still working in this space.
  - cerved 5y ago
    I look at gits diffs to see what's changed between versions, but that's for fun and not diligence. > With the level of scrutiny required to detect a maliciously-obfuscated security exploit Nope. Not paid to do that and I have not been given any such responsibility. That said, I think the attack vector on this is very low. Packages are rarely updated to the latest version. We don't use a lot of packages. We mostly use packages from trusted sources. We use packages that are open source.
  - rich_sasha 5y ago
    And frankly, not just diffs. You’d need to inspect the initial state, and any new dependency added. That’s potentially hundreds of thousands of LoC.
- deathanatos 5y ago
  I actually do this, on occasion. (Not 100%, and not to a degree I'd say "yeah, I'd've caught this colors/fakers thing." But enough to say that I've seen a decent sample.) There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality. I've had to roll-back / hard-pin dependencies from both low-quality FOSS & low-quality paid projects because of commits that — once you find & read them — are just bananas. (I have no idea how to solve the root problem here, honestly.)
  - cerved 5y ago
    > I have no idea how to solve the root problem here I'm not even sure what the problem is. If it's "updating dependencies introduces severe side effects" wich, I think, should be accounted for in the process

tablespoon 5y ago

> Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time. It seems like the problem here is more cultural than technical, specifically that the JavaScript community has fully embraced packages that are "written by randos" that are "wrappers around three-line Stack Overflow answers." I use packages, but I wouldn't use any that are developed by a rando with no reputation or "institutional oversight." An important part of choosing to use one is evaluating the maintainers. Does the JavaScript ecosystem have anything like Apache Commons? I'm guessing not, but it probably should.

KennyBlanken 5y ago
Not just that they've fully embraced the "written by randos" but even worse: "as soon as the rando publishes an update or change, use it!" They seem to fully automate updates because packages are so poorly written (and frankly, it probably helps with revenue stream, if their client's websites occasionally break and need them to fix it.) ...and meanwhile NPM's idea of vetting packages is basically "YOLO, BRO!"
oblio 5y ago
It's both technical and cultural. Javascript is used on the front end. Front end devs obsess (or at least used to obsess) over download sized. So you'd have crazy stuff like custom builds of Underscore (https://underscorejs.org/ https://underscorejs.org/) with just the functions you wanted. Think manual sandboxing, if that makes any sense. You could get a package of Underscore with just map, filter and reduceRight, if you wanted to. Now, when Node came around, people wanted as much as possible to have the same libraries available on the front end, so the same obsession with size was carried over. Ergo the micro-milli-nano-packages they make. Now, about the technical solution to this. We have this, for well defined programming languages (read: statically typed ones, or dynamically typed ones with a clear structure). It's a linker. Tech from the 1950s. Link (include) just the stuff you want, "tree shake"/"remote dead code" whatever you don't. https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-have-a-linker/ https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... Java's largely to blame for this, Sun REALLY, REALLY hated stuff that could be hooked into any OS and wasn't portable, so they didn't provide a linker. Everything was supposed to be on their JVM and you were going to install their JVM everywhere (2 billion devices!!!) and to hell with small stuff or heaven forbid, including native libraries. Javascript followed (on top of the Java restrictions they added: dynamic, poorly defined language, that would have made linking with tree shaking really hard, anyway). .Net also followed. Almost 3 decades later we're trying to undo that damage.