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.

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.

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.

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

Too much fallout.

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.

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?

No one will do it seriously