Conversation
|
I'm not for this but I won't actively oppose it for now. It feels like security theatre at the airport because it assumes you'll get an in depth review by a someone trained in the relevant issue at hand. |
|
What it means is that a single individual, including a compromised account, can't unilaterally submit and merge a PR. It's not everything we need, but it is something we need. I.e. necessary but not sufficient. What most concerns me about the new class of attacks is that it's no longer necessary for a product to ship with the malware to infect people. Committing it to the repo is sufficient to infect other developers who simply checkout and build the code. |
|
I am curious what Apache Infrastructure's take is on all of this. I would think that this concern applies to all ASF projects, not just Xerces and that there should be a foundation wide policy for the actions to take for protecting all of our repositories. |
|
Yes, I would like to look into foundation wide policies too. That shouldn't delay us from protecting our repo today. I will note that protecting main branches and requiring code reviews was standard and required practice at Google and many other organizations and companies probably ten years ago or more. Apache is way behind the curve on this. |
Agreed. That is certainly the norm for the other projects I work on. |
I'm trying to lock down the repo a bit more to protect against increasing supply chain attacks including ones that steal GitHub credentials and use it to launch not just malware but self-propagating worms:
https://www.youtube.com/watch?v=ZrD9MC_BXGk
This hasn't hit Java yet that I know of, but I fear that's only a matter of time. This PR won't completely resolve the problem, but maybe gives us a bit more chance of noticing a nefarious worm.