3 ms·

I guess you could look at this as a restatement of the 'Reflections on trusting trust' paper (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Reflectio

I guess you could look at this as a restatement of the 'Reflections on trusting trust' paper (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...), in that the whole software chain needs securing ideally (though there is value in even doing parts of it). I don't think that will be possible with federated governance, rather the chain is probably best secured mathematically and in a distributed fashion. Potential use for the blockchain/merkle-clock event log/zksnarks etc. ?

fsflover 2y ago
Can't it be solved with the reproducible builds?
- alexisread 2y ago
  Somewhat yes, but compilers can inject vulnerabilities, and you also require composable code to avoid composition vulnerability.
  - fsflover 2y ago
    Here's an even better solution: https://news.ycombinator.com/item?id=41368835 https://news.ycombinator.com/item?id=41368835
saagarjha 2y ago
That’s not really what the paper is about.
- alexisread 2y ago
  As far as I can see, the article is somewhat about whether we can trust open source software, given political tensions, language barriers, and malicious actors. To that, the article suggests a central authority with global membership to create trust. If the W3C is representative of that, then regulatory capture is a real possibility, or balkanisation if there is disagreement. Trust in balkanised orgs is of course a problem, and hence trust in the code - the paper deals with a similar issue ie. How to trust code. In this case though, the idea is to be able to verify the code yourself, rather than trust an org. The paper centres on whether you can trust the compiler ie. The bootstrap problem, and while tech alone will never solve the issue, the capability to create trust in the code yourself can be a basis for better layered trust on top. To add to this, signed builds/source on their own are not a solution as a compiler or malicious actor can inject bad code. As such, yes I don't believe a central, or federated orgs alone can be a solution, you're likely to need a solid bootstrap and chain of trust (and maybe content-addressed code) to underpin the quality of the code.
  - saagarjha 2y ago
    The paper being Reflections on Trusting Trust.
kayo_20211030 2y ago
I don't think it's as much a technical problem as it is a social, or process, problem. Math and distribution won't solve those. If the introduction of an exploit is done well (e.g. the XZ exploit), the provenance of the malicious code will pass muster. It'll just be doing bad things, at least from the OSS consumer's perspective.

fsflover 2y ago

Can't it be solved with the reproducible builds?

alexisread 2y ago
Somewhat yes, but compilers can inject vulnerabilities, and you also require composable code to avoid composition vulnerability.
- fsflover 2y ago
  Here's an even better solution: https://news.ycombinator.com/item?id=41368835 https://news.ycombinator.com/item?id=41368835

saagarjha 2y ago

That’s not really what the paper is about.

alexisread 2y ago
As far as I can see, the article is somewhat about whether we can trust open source software, given political tensions, language barriers, and malicious actors. To that, the article suggests a central authority with global membership to create trust. If the W3C is representative of that, then regulatory capture is a real possibility, or balkanisation if there is disagreement. Trust in balkanised orgs is of course a problem, and hence trust in the code - the paper deals with a similar issue ie. How to trust code. In this case though, the idea is to be able to verify the code yourself, rather than trust an org. The paper centres on whether you can trust the compiler ie. The bootstrap problem, and while tech alone will never solve the issue, the capability to create trust in the code yourself can be a basis for better layered trust on top. To add to this, signed builds/source on their own are not a solution as a compiler or malicious actor can inject bad code. As such, yes I don't believe a central, or federated orgs alone can be a solution, you're likely to need a solid bootstrap and chain of trust (and maybe content-addressed code) to underpin the quality of the code.
- saagarjha 2y ago
  The paper being Reflections on Trusting Trust.

kayo_20211030 2y ago

I don't think it's as much a technical problem as it is a social, or process, problem. Math and distribution won't solve those. If the introduction of an exploit is done well (e.g. the XZ exploit), the provenance of the malicious code will pass muster. It'll just be doing bad things, at least from the OSS consumer's perspective.