6 ms·

Every single commit this person ever did should immediately be rolled back in all projects.

by eigenvalue 3y ago

gopher_space 3y ago
It's weird and disturbing that this isn't the default perspective.
- freedomben 3y ago
  Well, it is much easier said than done. Philosophically I agree, but in the real world where you have later commits that might break and downstream projects, etc, it isn't very practical. It strikes me as in a similar vein to high school students and beauty pageant constestants calling for world peace. Really great goal, not super easy to implement. I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
- deleted 3y ago
  [deleted]
- maxcoder4 3y ago
  Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.
- concordDance 3y ago
  Some of those commits might fix genuine vulnerabilities. So you might trade a new backdoor for an old vulnerability that thousands of criminal orgs have bots for exploiting. Damage wise, most orgs aren't going to be hurt much by NSA or the Chinese equivalent getting access, but a Nigerian criminal gang? They're far more likely to encrypt all your files and demand a ransom.
  - mysidia 3y ago
    Still.. At this point the default assumption should be every commit is a vulnerability or facilitating a potential vulnerability. For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.
    - KeplerBoy 3y ago
      Surely this is happening right now. A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.
- bananapub 3y ago
  it's not weird at all? randomly reverting two years of things across dozens of repositories will break them, almost definitely make them unbuildable, but also make them unreleasable in case any other change needs to happen soon. all of their code needs to be audited to prove it shouldn't be deleted, of course, but that can't happen in the next ten minutes. I swear that HN has the least-thought-through hot takes of any media in the world.
  - datascienced 3y ago
    Yeah if you tried to revert stuff that was done weeks ago on a relatively small team you know how much painstaking work it can be.
  - ryanwaggoner 3y ago
    * I swear that HN has the least-thought-through hot takes of any media in the world.* The irony is too good.
- kaliqt 3y ago
  You can't just go and rip out old code, it'll break everything else, you have to review each commit and decide what to do with each.
  - maerF0x0 3y ago
    "immediately" could mean have humans swarm on the task and make a choice, as opposed to for commit in author_commits git revert $commit
- crest 3y ago
  Too much fallout.
andruby 3y ago
Hoe will you do that practically though? That’s probably thousands of commits upon which tens or hundred thousand commits from others were built. You can’t just rollback everything two years and expect it not to break or bring back older vulnerabilities that were patched in those commits.
- kjs3 3y ago
  Likely part of what the attacker(s) are counting on. Anyone want to place odds this isn't the only thing that's going to be found?
  - School-Cotton 3y ago
    I’d bet you at even odds that nothing else malicious by this person is found in 1 month, and at 1:2.5 odds that nothing is found in a year.
    - kjs3 3y ago
      Only if you consider "this person" to be equal to "this identity".
neurostimulant 3y ago
Rolling back two years worth of commits made by a major contributor is going to be hell. I'm looking forward to see how they'll do this.
- joeyh 3y ago
  Not really. xz worked fine 2 years ago. Roll back to 5.3.1 and apply a fix for the 1 security hole that was fixed since that old version. (ZDI-CAN-16587) Slight oversimplification, see https://bugs.debian.org/1068024 https://bugs.debian.org/1068024 discussion.
  - kelseydh 3y ago
    This seems true with so many of these core libraries. Change for the sake of change introduces attack vectors. If it ain't broke, don't fix it!
    - account42 3y ago
      Yeah but people will cry "dead project" if there hasn't been a release for a week.
planb 3y ago
I don’t thinks that’s necessary: there are enough eyes on this person’s work now.
- hcks 3y ago
  No one will do it seriously

Every single commit this person ever did should immediately be rolled back in all projects.

gopher_space 3y ago

It's weird and disturbing that this isn't the default perspective.

freedomben 3y ago
Well, it is much easier said than done. Philosophically I agree, but in the real world where you have later commits that might break and downstream projects, etc, it isn't very practical. It strikes me as in a similar vein to high school students and beauty pageant constestants calling for world peace. Really great goal, not super easy to implement. I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
deleted 3y ago
[deleted]
maxcoder4 3y ago
Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.
concordDance 3y ago
Some of those commits might fix genuine vulnerabilities. So you might trade a new backdoor for an old vulnerability that thousands of criminal orgs have bots for exploiting. Damage wise, most orgs aren't going to be hurt much by NSA or the Chinese equivalent getting access, but a Nigerian criminal gang? They're far more likely to encrypt all your files and demand a ransom.
- mysidia 3y ago
  Still.. At this point the default assumption should be every commit is a vulnerability or facilitating a potential vulnerability. For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.
  - KeplerBoy 3y ago
    Surely this is happening right now. A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.
bananapub 3y ago
it's not weird at all? randomly reverting two years of things across dozens of repositories will break them, almost definitely make them unbuildable, but also make them unreleasable in case any other change needs to happen soon. all of their code needs to be audited to prove it shouldn't be deleted, of course, but that can't happen in the next ten minutes. I swear that HN has the least-thought-through hot takes of any media in the world.
- datascienced 3y ago
  Yeah if you tried to revert stuff that was done weeks ago on a relatively small team you know how much painstaking work it can be.
- ryanwaggoner 3y ago
  * I swear that HN has the least-thought-through hot takes of any media in the world.* The irony is too good.
kaliqt 3y ago
You can't just go and rip out old code, it'll break everything else, you have to review each commit and decide what to do with each.
- maerF0x0 3y ago
  "immediately" could mean have humans swarm on the task and make a choice, as opposed to for commit in author_commits git revert $commit
crest 3y ago
Too much fallout.

andruby 3y ago

Hoe will you do that practically though? That’s probably thousands of commits upon which tens or hundred thousand commits from others were built. You can’t just rollback everything two years and expect it not to break or bring back older vulnerabilities that were patched in those commits.

kjs3 3y ago
Likely part of what the attacker(s) are counting on. Anyone want to place odds this isn't the only thing that's going to be found?
- School-Cotton 3y ago
  I’d bet you at even odds that nothing else malicious by this person is found in 1 month, and at 1:2.5 odds that nothing is found in a year.
  - kjs3 3y ago
    Only if you consider "this person" to be equal to "this identity".

neurostimulant 3y ago

Rolling back two years worth of commits made by a major contributor is going to be hell. I'm looking forward to see how they'll do this.

joeyh 3y ago
Not really. xz worked fine 2 years ago. Roll back to 5.3.1 and apply a fix for the 1 security hole that was fixed since that old version. (ZDI-CAN-16587) Slight oversimplification, see https://bugs.debian.org/1068024 https://bugs.debian.org/1068024 discussion.
- kelseydh 3y ago
  This seems true with so many of these core libraries. Change for the sake of change introduces attack vectors. If it ain't broke, don't fix it!
  - account42 3y ago
    Yeah but people will cry "dead project" if there hasn't been a release for a week.

planb 3y ago

I don’t thinks that’s necessary: there are enough eyes on this person’s work now.

hcks 3y ago
No one will do it seriously