Migrating accounts of PHP core developers by asking them for their username over unencrypted email? What could go wrong? A security incident already occurred, so we should be good on that front for a few years, right?
Just to make sure that someone doesn't go in and find a PHP account with recent commits, then email you with a third party github account.
You need people to properly secure their keys of course, but it makes life a lot harder for an attacker.
When you git pull, then do your work and git commit/push, if you are not careful and you do not examine git status/diff you could sign and commit the hackers change (that you pulled from the repo initially) along with your new changes. So care is required even with PGP signed commits.
This is another good reason to not interrupt developers while they are working. Doing so, makes mistakes such as this more likely.
> if you are not careful and you do not examine git status/diff you could sign and commit the hackers change
I assume he meant that you pull, get an auto merge and then inattentively sign it. With this, you confirm the hackers change with your signature.
You could add a push hook to only allow fully signed chains, but given that we are talking about a compromised server, this does not help.
Even if we assume the git server is completely malicious, I'm still not seeing a case where an attacker can hide a change because I didn't 'status/diff'. I'm open to considering attacks I haven't thought of though.
Requiring two-factor auth for the GitHub account should be good for this though.
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself.
…and ends by saying:
> We're reviewing the repositories for any corruption beyond the two referenced commits. Please contact security@php.net if you notice anything.
Are you sure that using recent commits as confirmation is a good idea?
Combine that with a spoofed/typo'd sender and you're good to go.
In a perfect world, this would be fine, yes. But when adding work on top of a probably already very stressful workday, the likelihood of this creating additional problems is there.
Doesn't GitHub require e-mail validation before it associates commits with that e-mail address?
> Or they could have had different e-mails for php.net and GitHub, i.e. something like php@xy.com and github@xy.com.
Then require them to add their php.net mail address to their GitHub account.
> the likelihood of this creating additional problems is there.
That I agree with.
IIRC, nope! You can say your email is Linus Torvalds’, and GitHub will not question it (and even link to his GitHub profile in the commit history!)
That's the other way around though -- claiming the victims GitHub profile made a commit controlled by the attacker, instead of claiming the attackers GitHub profile made a commit controlled by the victim.
1. Look for a contributor without GitHub account (i.e. xy@gmail.com )
2. Add xy@gmail.com to your GitHub account/create one with that address [0]
2.1 The commits made by the victim will now link to your account on GitHub
3. Send a mail to Nikita with your faked GitHub-profile
None of this will survive a thorough check, but under pressure this will easily pass a surface-level check.
[0] I think you need to confirm your primary E-Mail, but not secondary ones. Alternatively, you could look for commits made from an now deleted mail account.
Although the victim would be notified that their address was added to a rogue account, the notification mail says: "If this wasn’t you, please ignore this email." Ugh.
Given that the attacker managed to push unauthorised commits, I don’t see how recent commits can be considered a reliable method of authentication.
(Yes, this still has holes, but it's a far smaller attack surface than "hello, it's me, trust me because I say so".)