371–379 of 379 posts
Earlier quoted context omitted.
Thanks for your thoughtful reply. > "Every contributor is dangerous" is spectacularly toxic type of attitude. I view this from the lens of "How well can people reason about probabilities?" and research has shown, more or less, "not very well". In the short term, therefore, it is wise to tailor communications so as to avoid predictable irrational reactions. In the medium term, we need to _show_ people how to think abo…
In the end you can never fully trust anyone , including yourself. This has always been true for anything: people get drunk, have psychotic episodes or have other mental health issues, things like that. It happens. Remember that Malaysian pilot flying the passenger plane in the ocean? Every pilot in the world will agree that we need to think about risk management to prevent that sort of thing. I think a lot of them wi…
What should professionals in cybersecurity do? (Not my field, so I could be off-target here) My recommendation: communicate a risk model [1], encourage people to update it for their situation, and demand that people act on it [2]. Not too different from what the field of cybersecurity recommends now. (Or am I wrong?)
[1] based on a set of attack trees (right?)
[2] based on the logic that if you get pwned, you become a zombie to attack me
Earlier quoted context omitted.
You seem to think that vetting contributors or reviewing all code commits for malicious actions or code is some unreasonable ask. That should be standard practice. If someone is getting angry that you actually check their code for vulns, or that you don't let them make changes to certain core areas of a large app without establishing some credibility first, you probably don't want them working on your project. You ca…
It has been standard practice for decades. Sometimes this goes wrong, because everything can go wrong. It happens. Casting doubt on any contributor, any maintainer, and any long-term maintainer with fantastical stories is just throwing shade. Of course no one can be trusted absolutely; that has always been true for anything from software to child care to launching nuclear bombs. Anyone and anything can become suspect…
It literally just happened.
And no, being cautious is never throwing shade, unless you're doing it in a discriminatory way, like assuming that Chinese or Russian contributors are more dangerous.
Earlier quoted context omitted.
That person might just be a regular Java developer who works on a project which onboarded Checkstyle, and can't disable it's MagicNumber check. https://checkstyle.sourceforge.io/checks/coding/magicnumber....
Man, I hate such tools. Do I run into problems when I try to convert seconds to minutes? Larger problem than magic numbers ever could be.
Earlier quoted context omitted.
> Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it. The rust project does it. There's a repo with all [active] members and their permissions on github, etc. These get synchronized and updated every time there's a change.
The major projects aren't on github.
Earlier quoted context omitted.
That's great that you are considering this more now. But the xy story taught us, that every contributor is dangerous, the most dangerous ones are probably the most helpful and most skilled contributors. If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor. Another thing that was not talked about a lot: There are many ways to compromise existing maintainers. Compromising…
> Another thing that was not talked about a lot: There are many ways to compromise existing maintainers. Also not talked about a lot - there are many ways to compromise existing software engineers who are paid to work on proprietary software systems.
- Open-source subversion has the big advantage of having the code, testing and build processes in the open which allows for the attack surface to be exhaustively studied, whereas closed source requires code exfil, reverse engineering, inside intel on processes etc.
- Closed-source subversion can hide in other places -- binaries can be corrupted on a compromised server etc. Seeking to influence the code-based development seems like the hardest road IMO.
- Open-source maintenance (at least the kind under discussion here) stops at the maintainer, whereas most corporate dev is in a hierarchy with non-uniform commit authority. None of the same social techniques would apply.
I'm a maintainer (one of many) of an open source project, and this topic has been on my mind a lot lately as I review PRs. I am more suspicious of PRs from new contributors by default now. Of course I keep these suspicions to myself, but besides simply reviewing code for all the regular things, I now ask myself "what sort of sneaky thing could they be doing that appears benign on the surface?"