4 ms·

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.

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.