16 ms·

New to web dev. New to node. Looks like a complete mess to me, deserves criticism, as does much of the web dev ecosystem. Package maintainer should indeed have

New to web dev. New to node. Looks like a complete mess to me, deserves criticism, as does much of the web dev ecosystem. Package maintainer should indeed have found someone to pass it onto (see Cathedral & the Bazaar). And that doesn’t include the first person he’s never heard of stepping up. BUT this applies to all package managers, maintainers, and OSS at some level. The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that. The idea that you “don’t have to trust” the authors is untrue, in the current workflow. FOSS relies entirely on trust. I’m not convinced FOSS is even a good idea at this point, but with the advent of widespread cyberwarfare we need to either introduce a sophisticated accompanying trust model, or exclude FOSS when working commercially. This is a business opportunity. Audit FOSS and sell your audit guarantees in a contract. Offer services to audit more recent versions on the proviso that you can sell that audit elsewhere. This will have the incidental benefit of encouraging clean software to be written in languages that minimise audit costs, as those projects will get used more. Some commercial arbitration of FOSS now looks inevitable.

herge 8y ago
> Audit FOSS and sell your audit guarantees in a contract Pay Redhat enough and they will do that. Although you will be limited in what you can use.
- rwmj 8y ago
  Don't know why you're being downvoted, because Red Hat does indeed audit all of the code we ship in RHEL (and believe me it's pretty tedious). We don't ship much in the way of Javascript libs though.
zAy0LfpBZLC8mAC 8y ago
> I’m not convinced FOSS is even a good idea at this point, but with the advent of widespread cyberwarfare we need to either introduce a sophisticated accompanying trust model, or exclude FOSS when working commercially. So, you are saying that we should prefer code where it is impossible to have a look at the source because that solves the problem of having to trust the developers of that code?
- randomsearch 8y ago
  1. Commercial does not imply closed source. 2. It’s about legal responsibility and recourse.
  - zAy0LfpBZLC8mAC 8y ago
    > 1. Commercial does not imply closed source. How is that relevant? > 2. It’s about legal responsibility and recourse. How is that relevant?
    - andrewflnr 8y ago
      You pay for the software, you get the source. I gather this used to be the default distribution method, and I think it still gets used for game engines.
    - peteradio 8y ago
      > you are saying that we should prefer code where it is impossible to have a look at the source Just because not everybody has access != a person inside a gated area doesn't get to see. You made that leap. If you are building software on top of software that carries no guarantees then you are liable unless you also somehow make no guarantees. Are you able to sell software without guarantees? Maybe?
      - zAy0LfpBZLC8mAC 8y ago
        > Just because not everybody has access != a person inside a gated area doesn't get to see. You made that leap. Well, I guess that was somewhat of a leap, but it doesn't really make a difference to the argument: The point is that they are suggesting that preferring code that fewer people can look at somehow solves a problem. > If you are building software on top of software that carries no guarantees then you are liable unless you also somehow make no guarantees. Well, yeah? But what does that have to do with FOSS? Neither does FOSS imply that there are no guarantees, nor does proprietary software imply that there are guarantees. Hence: What is the relevance? The only difference between FOSS and proprietary software in this regard is that with FOSS you have the option to do an audit yourself and offer guarantees on that basis without creating a huge unknown risk for yourself, or you could possibly buy auditing services on the free market that come with some sort of guarantee from a third party. There is no option that you have with proprietary software that is somehow impossible with FOSS, which is why the suggestion that not using FOSS for commercial projects somehow solves a problem is strange at best. > Are you able to sell software without guarantees? Maybe? Well, given the tons of massively broken proprietary commercial software out there? Yeah, obviously you can?
lugg 8y ago
> Package maintainer should indeed have found someone to pass it onto (see Cathedral & the Bazaar). And that doesn’t include the first person he’s never heard of stepping up. WITH NO WARRANTY. Do you not understand what this part of the licensed mean? Mainter doesn't have to do shit. That is the point. You want to start putting arbitrary ethics and morals on these developers? The "Fuck you. Pay me." talk comes to mind. FOSS works fine like this and has been for a long time. We're seeing issues now because of nodes lack of a standard library. Not trust and certainly not instead issues with free and open source software.
- andrewflnr 8y ago
  Lack of standard library only makes the trust issue manifest with more hilariously basic libraries, instead of more slowly with the libraries. We've still seen this in Python, the poster child for batteries-included.
  - lugg 8y ago
    I think it's been said elsewhere, this is true but the frequency and severity is orders of magnitude less with the languages with good standard libraries. When the entire ecosystem depends on left pad I think you have a problem. When the entire ecosystem depends on express it is less of an issue because more eyes are invested in auditing it and changes are more widely reviewed. You think a nefarious leftpad function would make it's way into express? It could, but it is way less likely. Updating the dependency to a newer version of left pad isn't going to raise an eyebrow. And that is the issue.
- randomsearch 8y ago
  It sounds like you haven’t read the Cathedral and the Bazaar, which really is one of the founding documents of OSS, and it does indeed encode ethics in its motivation. Recommended reading.
sevensor 8y ago
TANSTAAFL. You're literally getting the source code for free. I agree that it absolutely makes sense to pay a third party to audit your dependencies if you can't do so yourself. The alternative is to restrict yourself to code from a source you trust implicitly.
ttty2 8y ago
> The idea that say a startup has time to audit every line of every dependency is absurd. I kind of agree, but remember you are getting free software. Not a little, but a ton of free software and you feel like somebody should guarantee all works fine. Choices: - See what is going on in all your deps and waste a lot of time - Risk it and use the software without knowing what is doing - Pay somebody to guarantee that the software is not malicious
pessimizer 8y ago
> The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that. This may sound strange, but once tech companies actually had to either write or buy all of their software, and if they didn't have a contract in place that made someone else responsible for its quality, they were. So, basically, the world was absurd. The way FOSS works is if users agree that a common good is important enough to invest in, and then they all benefit more than they would if they invested alone; it's anti-competitive. Free (and Open Source) software should be thought of as "free as in beer" i.e., the next round is on you. If you can't audit every line, audit some of them, or pay someone else to do it. Coordinate to get code coverage. If you use a project that is inadequately covered, you're responsible for everything that goes wrong. If you don't even know what libraries your project depends on, how could that ever be thought of as anyone's fault but your own?
- the8472 8y ago
  > Coordinate to get code coverage. This may be a central part of the issue. It's a coordination problem and creating common knowledge. Each corporation might be willing to pay to have some bits of their dependencies audited as long as others cover other pieces. But to do that they need to be able to announce the audit result and scan their dependency trees for pieces that are not audited and pick from those. You'd also need some common standards what constitutes an audit and the lawyers would probably want some limits on liability so results should be considered as best-effort or whatever. There are no conventions and social protocols in place to support this.
tastroder 8y ago
I might be missing your point or simply have a hard time understanding this anti FOSS rethoric. I'm reading that you'd pay a third party so you can trust open source code and think that FOSS somehow exposes commercial code to more risk in some kind of cyber warfare? How is that not complete FUD? You already have the option to pay vendors like redhat for many open source software components if liability is your only concern, the same is true for many of the more complex libraries out there. Closed source on the other hand would mean buying every single piece of code or paying in house devs to write that code. I get the quality concerns raised here up to a point but just because a company paid somebody to write something doesn't mean it's not effectively written by a solo dev under heavy time constraints. Except with FOSS you at least have the chance to go in and inspect/fix the thing yourself if needs be.
- TimJYoung 8y ago
  Two things: 1) The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms. Personally, I prefer the commercial license/source-included model, with the emphasis on the author/company getting paid to ensure that the situations like the one described here are avoided. You can then have additional educational licenses for ensuring access to developer tools for educational purposes, but that's up to the author/company. 2) If you directly pay someone to write software, I would expect any such arrangement to include the source code as part of the work product, regardless of the ultimate visibility of the source code to outside parties.
  - starbeast 8y ago
    >The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms. And now Microsoft uses linux on the majority of their own cloud offerings. Open source beats propriety software on economic terms a lot of the time. It doesn't matter that both can work in economic terms, it matters which one is better in economic terms.
swiftcoder 8y ago
> The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that. Big business absolutely do that. Code quality review, security review, legal review. Every line of every 3rd party dependency. Of course, for the most part big business doesn't take 3rd party dependencies. If you have a big enough software org, you write everything above the std library in-house. Why do you think so many of the big open-source frameworks are vended by big 10 tech firms?
- ttty2 8y ago
  > Big business absolutely do that. If would be true somebody would have noticed this hack before. Has been online for 2 months and they only found out because of a deprecation message. > Of course, for the most part big business doesn't take 3rd party dependencies. I worked for many big companies, definitively they use 3rd party deps. > std library in-house And that contains 3rd party deps. Big companies have some 3rd party to check the libraries but it looks like they are not good enough because they didn't catch this one.
  - swiftcoder 8y ago
    Maybe this particular dependency just isn't used by many big firms? I've had to go through code, security, and legal reviews at both Amazon and Facebook when desiring to import 3rd party libraries. They were fairly thorough.

herge 8y ago

> Audit FOSS and sell your audit guarantees in a contract Pay Redhat enough and they will do that. Although you will be limited in what you can use.

rwmj 8y ago
Don't know why you're being downvoted, because Red Hat does indeed audit all of the code we ship in RHEL (and believe me it's pretty tedious). We don't ship much in the way of Javascript libs though.

zAy0LfpBZLC8mAC 8y ago

> I’m not convinced FOSS is even a good idea at this point, but with the advent of widespread cyberwarfare we need to either introduce a sophisticated accompanying trust model, or exclude FOSS when working commercially. So, you are saying that we should prefer code where it is impossible to have a look at the source because that solves the problem of having to trust the developers of that code?

randomsearch 8y ago
1. Commercial does not imply closed source. 2. It’s about legal responsibility and recourse.
- zAy0LfpBZLC8mAC 8y ago
  > 1. Commercial does not imply closed source. How is that relevant? > 2. It’s about legal responsibility and recourse. How is that relevant?
  - andrewflnr 8y ago
    You pay for the software, you get the source. I gather this used to be the default distribution method, and I think it still gets used for game engines.
  - peteradio 8y ago
    > you are saying that we should prefer code where it is impossible to have a look at the source Just because not everybody has access != a person inside a gated area doesn't get to see. You made that leap. If you are building software on top of software that carries no guarantees then you are liable unless you also somehow make no guarantees. Are you able to sell software without guarantees? Maybe?
    - zAy0LfpBZLC8mAC 8y ago
      > Just because not everybody has access != a person inside a gated area doesn't get to see. You made that leap. Well, I guess that was somewhat of a leap, but it doesn't really make a difference to the argument: The point is that they are suggesting that preferring code that fewer people can look at somehow solves a problem. > If you are building software on top of software that carries no guarantees then you are liable unless you also somehow make no guarantees. Well, yeah? But what does that have to do with FOSS? Neither does FOSS imply that there are no guarantees, nor does proprietary software imply that there are guarantees. Hence: What is the relevance? The only difference between FOSS and proprietary software in this regard is that with FOSS you have the option to do an audit yourself and offer guarantees on that basis without creating a huge unknown risk for yourself, or you could possibly buy auditing services on the free market that come with some sort of guarantee from a third party. There is no option that you have with proprietary software that is somehow impossible with FOSS, which is why the suggestion that not using FOSS for commercial projects somehow solves a problem is strange at best. > Are you able to sell software without guarantees? Maybe? Well, given the tons of massively broken proprietary commercial software out there? Yeah, obviously you can?

lugg 8y ago

> Package maintainer should indeed have found someone to pass it onto (see Cathedral & the Bazaar). And that doesn’t include the first person he’s never heard of stepping up. WITH NO WARRANTY. Do you not understand what this part of the licensed mean? Mainter doesn't have to do shit. That is the point. You want to start putting arbitrary ethics and morals on these developers? The "Fuck you. Pay me." talk comes to mind. FOSS works fine like this and has been for a long time. We're seeing issues now because of nodes lack of a standard library. Not trust and certainly not instead issues with free and open source software.

andrewflnr 8y ago
Lack of standard library only makes the trust issue manifest with more hilariously basic libraries, instead of more slowly with the libraries. We've still seen this in Python, the poster child for batteries-included.
- lugg 8y ago
  I think it's been said elsewhere, this is true but the frequency and severity is orders of magnitude less with the languages with good standard libraries. When the entire ecosystem depends on left pad I think you have a problem. When the entire ecosystem depends on express it is less of an issue because more eyes are invested in auditing it and changes are more widely reviewed. You think a nefarious leftpad function would make it's way into express? It could, but it is way less likely. Updating the dependency to a newer version of left pad isn't going to raise an eyebrow. And that is the issue.
randomsearch 8y ago
It sounds like you haven’t read the Cathedral and the Bazaar, which really is one of the founding documents of OSS, and it does indeed encode ethics in its motivation. Recommended reading.

sevensor 8y ago

TANSTAAFL. You're literally getting the source code for free. I agree that it absolutely makes sense to pay a third party to audit your dependencies if you can't do so yourself. The alternative is to restrict yourself to code from a source you trust implicitly.

ttty2 8y ago

> The idea that say a startup has time to audit every line of every dependency is absurd. I kind of agree, but remember you are getting free software. Not a little, but a ton of free software and you feel like somebody should guarantee all works fine. Choices: - See what is going on in all your deps and waste a lot of time - Risk it and use the software without knowing what is doing - Pay somebody to guarantee that the software is not malicious

pessimizer 8y ago

> The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that. This may sound strange, but once tech companies actually had to either write or buy all of their software, and if they didn't have a contract in place that made someone else responsible for its quality, they were. So, basically, the world was absurd. The way FOSS works is if users agree that a common good is important enough to invest in, and then they all benefit more than they would if they invested alone; it's anti-competitive. Free (and Open Source) software should be thought of as "free as in beer" i.e., the next round is on you. If you can't audit every line, audit some of them, or pay someone else to do it. Coordinate to get code coverage. If you use a project that is inadequately covered, you're responsible for everything that goes wrong. If you don't even know what libraries your project depends on, how could that ever be thought of as anyone's fault but your own?

the8472 8y ago
> Coordinate to get code coverage. This may be a central part of the issue. It's a coordination problem and creating common knowledge. Each corporation might be willing to pay to have some bits of their dependencies audited as long as others cover other pieces. But to do that they need to be able to announce the audit result and scan their dependency trees for pieces that are not audited and pick from those. You'd also need some common standards what constitutes an audit and the lawyers would probably want some limits on liability so results should be considered as best-effort or whatever. There are no conventions and social protocols in place to support this.

tastroder 8y ago

I might be missing your point or simply have a hard time understanding this anti FOSS rethoric. I'm reading that you'd pay a third party so you can trust open source code and think that FOSS somehow exposes commercial code to more risk in some kind of cyber warfare? How is that not complete FUD? You already have the option to pay vendors like redhat for many open source software components if liability is your only concern, the same is true for many of the more complex libraries out there. Closed source on the other hand would mean buying every single piece of code or paying in house devs to write that code. I get the quality concerns raised here up to a point but just because a company paid somebody to write something doesn't mean it's not effectively written by a solo dev under heavy time constraints. Except with FOSS you at least have the chance to go in and inspect/fix the thing yourself if needs be.

TimJYoung 8y ago
Two things: 1) The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms. Personally, I prefer the commercial license/source-included model, with the emphasis on the author/company getting paid to ensure that the situations like the one described here are avoided. You can then have additional educational licenses for ensuring access to developer tools for educational purposes, but that's up to the author/company. 2) If you directly pay someone to write software, I would expect any such arrangement to include the source code as part of the work product, regardless of the ultimate visibility of the source code to outside parties.
- starbeast 8y ago
  >The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms. And now Microsoft uses linux on the majority of their own cloud offerings. Open source beats propriety software on economic terms a lot of the time. It doesn't matter that both can work in economic terms, it matters which one is better in economic terms.

swiftcoder 8y ago

> The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that. Big business absolutely do that. Code quality review, security review, legal review. Every line of every 3rd party dependency. Of course, for the most part big business doesn't take 3rd party dependencies. If you have a big enough software org, you write everything above the std library in-house. Why do you think so many of the big open-source frameworks are vended by big 10 tech firms?

ttty2 8y ago
> Big business absolutely do that. If would be true somebody would have noticed this hack before. Has been online for 2 months and they only found out because of a deprecation message. > Of course, for the most part big business doesn't take 3rd party dependencies. I worked for many big companies, definitively they use 3rd party deps. > std library in-house And that contains 3rd party deps. Big companies have some 3rd party to check the libraries but it looks like they are not good enough because they didn't catch this one.
- swiftcoder 8y ago
  Maybe this particular dependency just isn't used by many big firms? I've had to go through code, security, and legal reviews at both Amazon and Facebook when desiring to import 3rd party libraries. They were fairly thorough.