Excellent write up, Rusty, thank you. Peer review is always a good thing, period. It's surprising to me that anyone is allowed to push to any component directly without the opportunity to vet commit quality and other things that are hard to automate into the build. Even the very best sometimes make mistakes and even the very best sometimes miss issues during PR review, but on balance risk of code churn or worse is reduced dramatically by a thorough review process. Cheers, Fred
On Sun, 9 Feb 2025 at 20:59, Slawomir Jaranowski <s.jaranow...@gmail.com> wrote: > Hi, > > On Fri, 7 Feb 2025 at 14:52, Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > > This is an early draft of something I plan to publish for more open > > source projects, but I wanted to send this out here first since I'm > > more directly involved. > > > > Open source projects, especially widely used ones like Maven, need to > > be aware of and protect against the growing risk of threat actors > > actively seeking committer privileges on projects as a precursor to > > installing backdoors in the source code. > > > > In particular, it seems that one or more nation states are playing the > > long game by targeting specific open source projects. Someone (likely > > a team of people) begins sending legitimate patches and PRs and > > participating in the mailing lists and other fora until they earn > > committer privileges. Then they insert the back door using inobvious > > code, wait for it to ship, and proceed with the attack against their > > targets. > > > > Last year xz utils was very nearly compromised in this way and only > > avoided shipping with the backdoor because one engineer at Microsoft > > noticed something funky in a beta release: > > > > https://en.wikipedia.org/wiki/XZ_Utils_backdoor > > > > This is not the first time this has happened, and it almost certainly > > won't be the last. For all we know there could be active exploits no > > one has noticed already shipped by popular open source software. > > > > What should Maven (and everyone else) do about this? There are a > > number of things. > > > > Most importantly, we need to make sure that all PRs and commits are > > reviewed before merge. Directly committing to master (as many people > > including myself currently have the ability to do) is not safe. It > > makes it far too easy to hide malicious commits. If I were an attacker > > I would seek out projects like Maven that allow direct commits without > > review or PRs. Every commit needs to go through code review, and we > > need to enforce this at the repo level so it cannot be bypassed. > > Even we don't strictly enforce PR requirements we have: > > - each commit is reported on ML - > https://lists.apache.org/list.html?comm...@maven.apache.org > - before release next version of ASF component we have a VOTE, we can > check what is deliverable > > > > > > Second, we need to verify the identities of new committers. If > > possible, new committers should be met in person at ApacheCon or other > > convenient events. That's probably not feasible for everyone involved > > in a widely dispersed project like Maven, but a quick video chat > > should at least verify that a real person exists. I'm not sure how > > long that's likely to help given the rapid advances in genAI > > impersonation. Nonetheless, we should do what we can to establish a > > chain of trust between actual human beings. > > > > Third, we should remove commitership from the large numbers of folks > > who haven't contributed to the project for 5+ years. They can still > > remain official PMC members, and can be reactivated if they one day > > decide to participate again. However, right now their Github accounts > > and Apache SVN credentials are extra risks we don't need. > > Compromising existing committers accounts is another attack vector > > that has been used in the past and will be used in the future. > > We have a simple statistic > > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-committers-stats.html > > To remove somebody we need a procedure for it. > > > > > Fourth, we should require all committer Github accounts to turn on two > > factor authentication. We might already be doing this. I don't have > > access to check. But if we're not, it's an easy fix to reduce the risk > > of hacked and stolen Github accounts being used to compromise us. > > > > There's one other technical change I'd like to consider to protect > > Maven users more than the Maven project itself. We should eliminate, > > or at the very least warn, when version ranges are used in dependency > > elements. See https://jlbp.dev/JLBP-14 for the rationale for this one. > > I don't know of an attack using this vector in Java (yet) but it has > > been used multiple times in other ecosystems to steal bitcoins and > > install malware. Java has been lucky so far, but we are by no means > > immune to it. > > > > There might be other things we can do to improve our security posture. > > This is just what I've seen used elsewhere. Like a lot of security > > measures, they're not without inconvenience, but they are necessary > > given the evolving threat landscape. We've made more invasive changes > > in the past to increase security, most notably requiring https for > > downloading artifacts, so I'm confident we can do this too. > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- > Sławomir Jaranowski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
