3 ms·
Actually its shown how a dependence on people whose identities have not been confirmed and who can merge code without review can cause major problems. If you re
by vajrabum 3y ago
Actually its shown how a dependence on people whose identities have not been confirmed and who can merge code without review can cause major problems. If you restrict it to people who get paid then the nation state or other bad actor will simply send someone to get a job that gives them the privilege or blackmail someone. who already has the privilege.
- sho_hn 3y agoIndeed. I'm very frustrated by all of the "this has shown how fragile FOSS is" hot takes I see appearing. I think it has shown us how awesome FOSS is: If this were all closed source software, chances are we'd never have known about the issue, nor would an entire community now be able to have an open conversation about how to mitigate it in the future, applying their combined brain power to the problem. And there's a fair amount of obvious steps to take now: - Re-visit the pro/con of anonymous contributions. Re-visit identity verification. Maybe do a SPDX-like thing for governance/contribution work flow mechanisms for project to report how they work and what stance they take, to allow downstreams to risk-rate. Some projects will very much want to continue to allow anonymous contribs for excellent reasons, and that's fine. - Phase out build and module systems that drive published tarballs differing from repo tags. - Have distributions verify that tarball contents match repo tags on import of new versions. Yes, this requires that projects have a repository that is reachable online. I think for critical SW that's OK. - Don't accept build systems that silently disable security features when dependencies are unavailable. Not building a security feature should always be a decision point and manual opt-out. - Come up with better metrics for maintainer burnout and heartbeat signals.
- striking 3y agoWho watches the watchers? Moreover, identities on the internet are fairly easy for motivated individuals (or moneyed organizations) to fake. Finally, who's going to build and maintain everything you've proposed? Companies need to sponsor work done on FOSS. FOSS maintainers need to reject requests that don't benefit the broadest possible audience unless they're receiving a sponsorship to do it. And that's just at a bare minimum. Without aligned incentives, I personally think any attempts at fixing things will be ineffective.
- trueismywork 3y agoIdentities are even easier to fake for nation state.
- jandrewrogers 3y agoEven if all contributors have verified identities, sign their commits, etc it isn't enough. Consider the real-world case where a developer's laptop is hacked and the attacker subtly modifies their local source tree to introduce a vulnerability that is unwittingly signed and committed by that developer. I've seen cases like this in the wild caught in code review. It always made me wonder how many such cases don't get caught, since code review isn't consistently thorough.
- foul 3y agoYou're somewhat right, somewhat wrong and somewhat as out of track as Ffmpeg: Lasse Collins should have been a team, a team that meets, so the problem of "unknown rude complainer" pressuring for "some guy working without scrutiny on your behalf" would be mitigated. But nothing impedes that your well-known lads can also work for the NSA or even for Microsoft. I'm adamant on thinking that first and foremost there is a smorgasbord of crazy designs at play: a build system so messy you can slide in binary injections, an init system with dependencies, an execution chain where you can easily rewrite whatever else's functions. It's fine if somewhere down the drain someone churns garbage, the priority has to be that it should be easy to detect it, I find that it's dumb and sub-par to rely on a fragmented and laggy circle of reviews, pre-releases and releases, (yeah, everything handled by thankless and lone volunteers makes it worse), for protecting our systems.