4 ms·

I don't get it, who is going to pay for the time and energy required to audit everything? I presume the big package maintainers already have eyes on their stuff

by deanc 5y ago

I don't get it, who is going to pay for the time and energy required to audit everything? I presume the big package maintainers already have eyes on their stuff - symfony etc. In theory we should always diff upstream package changes - in practice hardly anybody does. There's a trade-off between using OSS code and the cost of maintaining it yourself. That said I guess this adds an option to the ecosystem that wasn't there, or possible before.

goalieca 5y ago
I do wonder if companies like snyk could somehow incorporate some sort of assurance model into their service. Hashing and lock files are a pretty common practice and perhaps for the bigger packages they could maintain a list of trusted hashes.
- deanc 5y ago
  Imagine a scenario where an OSS developer with a package with millions of downloads a week is getting paid a few beers worth of money a month for all their work. And then a company like Snyk is building a verification service on top of this and making bank. Do you not think the money should be going to the OSS community?
  - CiPHPerCoder 5y ago
    These are two separate things, and it's perilous to conflate them. The OSS developer is providing software that anyone can use under whatever license terms for free. How they monetize this is entirely their responsibility. Choosing a permissive license makes them generally indistinguishable from the developers who don't want to monetize their work at all. Solving the "how do we ensure they get paid?" problem is nontrivial, but certainly out of scope for this discussion. The verification service is provided by a company to protect their customers from malicious changes to said OSS software. (Yes, even if they were deliberate changes by the original developer!) In some sense, you could try to frame the verification services as somehow predatory, but that's like saying that safety inspectors are predatory to independent carpenters. (I'm not happy with that last analogy, but it's the best I could come up with on the spot. Real-world analogies to software problems are always messy, so feel free to suggest a better one if you think of any.)
    - deanc 5y ago
      I'm afraid we'll have to agree to disagree on this one Scott, on a philosophical level. We have companies like pullrequest.com monetizing code quality (currently only private but I presume they'll enter the OSS market at some point), and then other companies who are monetizing security audits. None of this money trickles down to the distributed teams of developers writing the software in the first place. This makes me uncomfortable - and you are right we do have to find ways to help with this.
      - CiPHPerCoder 5y ago
        I think I understand why it makes you uncomfortable. I do think they're two separate problems, and must be solved independently. Left unsolved, what you're experiencing is mostly bad optics rather than a dependent nastiness. It's a bad look, and it leaves a bad taste in one's mouth. That being said, we both agree it's worth solving. However, I'm not an economist, by any measure, so I don't have any insight into what a solution looks like.
CiPHPerCoder 5y ago
> I don't get it, who is going to pay for the time and energy required to audit everything? Not everything has to be audited. That's why there's different levels of attestations. In terms of economic incentives: If you're a company bit by one of the recent supply chain issues (colors.js, etc.), you might be able to justify hiring a security vendor to audit the code that your company depends on. This would provide a net-positive benefit to the entire ecosystem, even if it's only a small set of audited code. Maybe one day, we can even make this an expectation of large players. But that's a discussion for down the road. On the opposite end of things, you have independent security consultants that want to establish their reputation so they can get paid engagements with software companies. One avenue available to everyone is review open source software, report vulnerabilities to their maintainers. This can be thankless or even traumatic; i.e. https://github.com/opencart/opencart/pull/1594 https://github.com/opencart/opencart/pull/1594 Gossamer would open an alternative approach: Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. Anti-malware vendors (e.g. WordFence) could even issue weaker positive assertions (spot-check) for WordPress plugin/theme updates after vetting the known-good releases. Security companies depend heavily on their ability to earn trust to thrive, and that's a hard market to break into; this offers another way in. In short, the economic challenges you're imagining aren't the ones that this project will face. (Although, there will assuredly be challenges.) Companies acting in their own self-interest can be leveraged to cover the hot paths of the universal dependency graph, and security up-starts can be leveraged to cover their blind spots. Given enough time, the ecosystem will eventually reach some sort of equilibrium, and many new opportunities will be made in the process. > I presume the big package maintainers already have eyes on their stuff - symfony etc. Read the discussion on the Symfony Encryption component: https://github.com/symfony/symfony/pull/39344 https://github.com/symfony/symfony/pull/39344 Just because they have eyes on their stuff doesn't mean that those eyes have the necessary domain-specific expertise to identify problems. If it weren't for Paragon (paragonie-security on Github) and their associates in the security industry, the issues identified in the earlier versions of the module would likely have persisted and been shipped.
- deanc 5y ago
mixologic 5y ago
The vast majority of code would end up with no attestations. Theres simply no incentive for anybody to do so. It's tragedy of the commons, but now with more visibility in to how tragic it is.
- some_furry 5y ago
  Then we'd have insight into how true or false Linus's Law really is, and can have future open source debates better informed.

by deanc 5y ago

goalieca 5y ago

I do wonder if companies like snyk could somehow incorporate some sort of assurance model into their service. Hashing and lock files are a pretty common practice and perhaps for the bigger packages they could maintain a list of trusted hashes.

deanc 5y ago
Imagine a scenario where an OSS developer with a package with millions of downloads a week is getting paid a few beers worth of money a month for all their work. And then a company like Snyk is building a verification service on top of this and making bank. Do you not think the money should be going to the OSS community?
- CiPHPerCoder 5y ago
  These are two separate things, and it's perilous to conflate them. The OSS developer is providing software that anyone can use under whatever license terms for free. How they monetize this is entirely their responsibility. Choosing a permissive license makes them generally indistinguishable from the developers who don't want to monetize their work at all. Solving the "how do we ensure they get paid?" problem is nontrivial, but certainly out of scope for this discussion. The verification service is provided by a company to protect their customers from malicious changes to said OSS software. (Yes, even if they were deliberate changes by the original developer!) In some sense, you could try to frame the verification services as somehow predatory, but that's like saying that safety inspectors are predatory to independent carpenters. (I'm not happy with that last analogy, but it's the best I could come up with on the spot. Real-world analogies to software problems are always messy, so feel free to suggest a better one if you think of any.)
  - deanc 5y ago
    I'm afraid we'll have to agree to disagree on this one Scott, on a philosophical level. We have companies like pullrequest.com monetizing code quality (currently only private but I presume they'll enter the OSS market at some point), and then other companies who are monetizing security audits. None of this money trickles down to the distributed teams of developers writing the software in the first place. This makes me uncomfortable - and you are right we do have to find ways to help with this.
    - CiPHPerCoder 5y ago
      I think I understand why it makes you uncomfortable. I do think they're two separate problems, and must be solved independently. Left unsolved, what you're experiencing is mostly bad optics rather than a dependent nastiness. It's a bad look, and it leaves a bad taste in one's mouth. That being said, we both agree it's worth solving. However, I'm not an economist, by any measure, so I don't have any insight into what a solution looks like.

CiPHPerCoder 5y ago

> I don't get it, who is going to pay for the time and energy required to audit everything? Not everything has to be audited. That's why there's different levels of attestations. In terms of economic incentives: If you're a company bit by one of the recent supply chain issues (colors.js, etc.), you might be able to justify hiring a security vendor to audit the code that your company depends on. This would provide a net-positive benefit to the entire ecosystem, even if it's only a small set of audited code. Maybe one day, we can even make this an expectation of large players. But that's a discussion for down the road. On the opposite end of things, you have independent security consultants that want to establish their reputation so they can get paid engagements with software companies. One avenue available to everyone is review open source software, report vulnerabilities to their maintainers. This can be thankless or even traumatic; i.e. https://github.com/opencart/opencart/pull/1594 https://github.com/opencart/opencart/pull/1594 Gossamer would open an alternative approach: Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. Anti-malware vendors (e.g. WordFence) could even issue weaker positive assertions (spot-check) for WordPress plugin/theme updates after vetting the known-good releases. Security companies depend heavily on their ability to earn trust to thrive, and that's a hard market to break into; this offers another way in. In short, the economic challenges you're imagining aren't the ones that this project will face. (Although, there will assuredly be challenges.) Companies acting in their own self-interest can be leveraged to cover the hot paths of the universal dependency graph, and security up-starts can be leveraged to cover their blind spots. Given enough time, the ecosystem will eventually reach some sort of equilibrium, and many new opportunities will be made in the process. > I presume the big package maintainers already have eyes on their stuff - symfony etc. Read the discussion on the Symfony Encryption component: https://github.com/symfony/symfony/pull/39344 https://github.com/symfony/symfony/pull/39344 Just because they have eyes on their stuff doesn't mean that those eyes have the necessary domain-specific expertise to identify problems. If it weren't for Paragon (paragonie-security on Github) and their associates in the security industry, the issues identified in the earlier versions of the module would likely have persisted and been shipped.

deanc 5y ago

mixologic 5y ago

The vast majority of code would end up with no attestations. Theres simply no incentive for anybody to do so. It's tragedy of the commons, but now with more visibility in to how tragic it is.

some_furry 5y ago
Then we'd have insight into how true or false Linus's Law really is, and can have future open source debates better informed.