3 ms·
Exactly that is my fear, too. It's like zero trust in everything. - Don't trust that any other party do the security testing for you - Don't trust any develope
by y_xc 3y ago
Exactly that is my fear, too. It's like zero trust in everything.
- Don't trust that any other party do the security testing for you
- Don't trust any developer, it could have malicious intents
- Don't trust the patches, they could introduce bugs/backdoors/...
So we're straight going in the direction of protectionism and isolation. Wouldn't that be a big step back for the whole OSS/FOSS community?
One thing I read the xc-writeups last days (I think it was here https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...) was that we at least shouldnt trust any devs/maintainers that have no online identity. Though the argument that you could create a fake ID is possible. So I'm still obsessed from the question, what are the lessons learned for the community from this and how restrictive the participation in OSS will become.
- ajross 3y agoI don't think that's quite right: Trust the community. Trust the process. Sure, any one actor might be compromised, but that will be rare and exceptional. So build layers such that their bad actions get detected and corrected. Some parts of that aparatus worked poorly in this case, it's true: xz had a single maintainer who turned out to be susceptible to a deliberate human engineering attack, and yet was trusted to be linked into the some of the highest-trust parts of the system. That's bad, and we should work to avoid that kind of situation in the future. But other bits worked very well: multiple downstreams detected the flaw (though only Andres saw it for the attack it really was), and it was corrected before it reached any production releases. The community as a whole is set up in the right way and doing the right things.