3 ms·

> I agree that it’s ultimately the developers fault for allowing code to be automatically injected Let's not do victim blaming here. This is ultimately the fa

by Beldin 5y ago

> I agree that it’s ultimately the developers fault for allowing code to be automatically injected Let's not do victim blaming here. This is ultimately the fault of the person deliberately updating their package to break other people's software.

ahtihn 5y ago
Nah, open source software is "use at your own risk" and there's 0 guarantee for anything. All responsibility lies with the user. If you don't like that responsibility, don't use open source software without reviewing it first.
- rich_sasha 5y ago
  It’s one side of the coin. The other is, to do anything at all of practical use in 98% of jobs, day 1 is installing a tonne of OS stuff. It’s not practical to expect pretty much every dev to inspect 100% of that, even if that’s what they implicitly agree to do in the license.
  - pc86 5y ago
    We're not talking about "a ton of OS stuff," we're talking about NPM packages. If you have your package manager set up in a way that allows it to automatically upgrade/break your code, that's 100% on you.
    - rich_sasha 5y ago
      I have a medium-sized data science project in Python. Nothing crazy. It's 180 packages, apparently, and 2.9M lines of code (whitespace, comments and all). Charitably let's call it 1m SLOC. Seriously, you expect anyone to audit all this? It's basically impossible for any solo dev / small org, and as I say, it's not even a big project. A vulnerability is like half a line, or sometimes a typo. Clearly, very different proposal for a large org, but even then, no small task.
- Chris2048 5y ago
  "0 guarantee" might apply to accidental bugs, but a developer maliciously sabotaging their packages?
pc86 5y ago
"Victim blaming" is a little harsh when it's literally a developer not doing their job and letting arbitrary code get inserted into their product. Do your job and make sure the code that's running is what you expect. There's no valid excuse not to.
collinmanderson 5y ago
> This is ultimately the fault of the person deliberately updating their package to break other people's software. Ultimately the 2017 Equifax data breach was the fault of the people who hacked into Equifax's website. We need systems in place to defend against people doing malicious things, but yes ideally individual developers shouldn't be the ones tasked with reviewing all of their dependencies' code. Operating System provided packages, for example, are generally reviewed by someone other than the author, which can lead to a more secure supply chain. Rust's cargo-crev review system also seems like a possible solution the problem.

by Beldin 5y ago

ahtihn 5y ago

Nah, open source software is "use at your own risk" and there's 0 guarantee for anything. All responsibility lies with the user. If you don't like that responsibility, don't use open source software without reviewing it first.

rich_sasha 5y ago
It’s one side of the coin. The other is, to do anything at all of practical use in 98% of jobs, day 1 is installing a tonne of OS stuff. It’s not practical to expect pretty much every dev to inspect 100% of that, even if that’s what they implicitly agree to do in the license.
- pc86 5y ago
  We're not talking about "a ton of OS stuff," we're talking about NPM packages. If you have your package manager set up in a way that allows it to automatically upgrade/break your code, that's 100% on you.
  - rich_sasha 5y ago
    I have a medium-sized data science project in Python. Nothing crazy. It's 180 packages, apparently, and 2.9M lines of code (whitespace, comments and all). Charitably let's call it 1m SLOC. Seriously, you expect anyone to audit all this? It's basically impossible for any solo dev / small org, and as I say, it's not even a big project. A vulnerability is like half a line, or sometimes a typo. Clearly, very different proposal for a large org, but even then, no small task.
Chris2048 5y ago
"0 guarantee" might apply to accidental bugs, but a developer maliciously sabotaging their packages?

pc86 5y ago

"Victim blaming" is a little harsh when it's literally a developer not doing their job and letting arbitrary code get inserted into their product. Do your job and make sure the code that's running is what you expect. There's no valid excuse not to.

collinmanderson 5y ago

> This is ultimately the fault of the person deliberately updating their package to break other people's software. Ultimately the 2017 Equifax data breach was the fault of the people who hacked into Equifax's website. We need systems in place to defend against people doing malicious things, but yes ideally individual developers shouldn't be the ones tasked with reviewing all of their dependencies' code. Operating System provided packages, for example, are generally reviewed by someone other than the author, which can lead to a more secure supply chain. Rust's cargo-crev review system also seems like a possible solution the problem.