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

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.

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.

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.

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.

Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.

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.

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.

* I swear that HN has the least-thought-through hot takes of any media in the world.*

The irony is too good.

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.

"immediately" could mean have humans swarm on the task and make a choice, as opposed to

    for commit in author_commits
        git revert $commit

Too much fallout.

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.

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?

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.

Only if you consider "this person" to be equal to "this identity".

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.

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 discussion.

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!

Yeah but people will cry "dead project" if there hasn't been a release for a week.

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

No one will do it seriously