I'd like to encourage folks to watch the following video. It's eye-opening:

https://www.youtube.com/watch?v=ZrD9MC_BXGk

To summarize, attackers are actively stealing GitHub credentials,
installing malware in the codebase, and using that to spread malware
across all active committers.

These attacks haven't hit Java yet that I know of, but I fear that's
only a matter of time. It took me about ten minutes to think of an
equivalent attack that would infect the Xerces repo starting from one
compromised committer.

There are a number of measures we can take to protect the Xerces
community from these attacks. There are probably others I haven't
thought of yet, but so far here's what I have:

1. Pay close attention on code reviews, including from known and
trusted committers. Infected PRs can be sent by bots with trusted
permissions. Pay special attention to "zero-length" string constants.
They can actually be hiding quite a lot of data.

2. Protect the main branch and require all PRs to go through code
review. That's already our convention but it should be enforced:
https://github.com/apache/xerces-j/pull/91

3. Close any other routes for commits that do not go through code
review. Not sure what the routes are yet, but I've seen this happen in
other projects. Anyone know?

4. Require two-factor authentication on GitHub for all committers.
(Done Apache wide, I think. Are there any legacy accounts without
two-factor?)

5. Move inactive committers and PMC members to emeritus status. This
would reduce the number of accounts that can be targeted. The goal is
to pause, not revoke, inactive committers' access. Or maybe we can
leave people in the PMC but remove their GitHub committer status.
Someone can always be unpaused through a simple request if they become
active again. I'm not sure of the mechanics here.

6. Reconsider our build process. In particular, jars directly checked
into the repo makes payloads easier to hide. We could be better off
relying on a pre-installed Ant and loading dependencies from the Maven
repository system with Ivy could help, even without a full migration
to Maven.

7. Configure a PR check that blocks certain suspicious Unicode
characters we shouldn't be using anyway. I'm hopeful GitHub will
implement this site-wide, but let's be on the lookout for it.

8. Split committer lists by repository. For instance, right now I'm a
committer on Xerces-C which I pay no attention to. However, I am
active on xerces-j. There's no need for me to have rights to both,
only to Xerces-J. This might require some changes on the Apache
infrastructure side, but we're hardly the only project that needs
this.

Thoughts? Any other ideas for preventing these attacks?

-- 
Elliotte Rusty Harold
[email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to