4 ms·

For now I'm only handling people for which I recognize the account or can confirm recent commits.

• brobdingnagians 6y ago
  I assume you mean that you are only handling people for whom you can confirm their recent php username AND can verify that the specific username connects to/is owned by the same person as the github account provided? 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.
  • johannes1234321 6y ago
    For most contributors we know GitHub identities, as PHP was using pull requests etc already from GitHub.
    • brobdingnagians 6y ago
      Aah, k, makes sense :)
• radicalbyte 6y ago
  Are you requiring signed commits? If you're not, I strongly suggest that you do in the future.
  • gocartStatue 6y ago
    I've been pointed out once that only tags should be signed - and referred to this: [1] https://news.ycombinator.com/item?id=12290873 https://news.ycombinator.com/item?id=12290873
    • radicalbyte 6y ago
      The whole part of signing commits is providing proof that you are who you say you are with the same level of trust provided by other systems built using Public Key Crypto. You need people to properly secure their keys of course, but it makes life a lot harder for an attacker.
      • _wldu 6y ago
        I sign my work-based git commits. I've been using GPG since the late 90s. It's not a silver bullet (especially when a git server has been owned). 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.
        • kenmacd 6y ago
          Can you walk me a scenario where you and I are hosting our code on a malicious git server and Chuck can get their code in our our codebase? (assuming only signed commits)
          • Sebb767 6y ago
            See: > 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.
            • Angius 6y ago
              But how does the hacker's commit goes through in the first place, if all PRs with unsigned commits are rejected outright?
              • Sebb767 6y ago
                If he hacked the server (which was assumed in the grand parent), he can probably shut off that check rather easily
• JimDabell 6y ago
  The notice starts out by saying: > 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?
  • deleted 6y ago
    [deleted]
  • pas 6y ago
    There will be increased scrutiny on this repo anyway. It's not necessarily the safest, but probably a low-risk and easy way to migrate committers.
• tgragnato 6y ago
  Can you provide more details about the breach? Did they get in via munin?