> When the authorities issue new fire safety regulations for buildings, then that is breaking compatibility to the older building standard.

Do the old buildings automagically get updated to the new standard everyone is using? Does the city shut down every business in a building that doesn't match standard (= break software) until that building is retrofitted (which is time-consuming and costly)? That's what breaking backwards compatability does, it stops people from doing their thing until someone fixes it (sometimes it's on them, sometimes it's on you). And not everyone can afford a 'drop everything now to fix the issues brought up by the kernel release'.

In any case, a good way to get people to not use your product is to keep breaking it.

> Sometimes even old buildings need to be retrofitted, and that is then what is done.

Is it? There was a very famous fire in London just a couple of weeks ago, of a building which wasn't up to standard, yet filled with people. Dozens of people died.

The example of the recent fire in London strengthens my point. If we neglect security, then there is a price to pay for it. And now in London they do fix up buildings, because it's what makes sense.

Linux including a breaking change to increase security does not stop any business. If you are not patched to the new version, don't upgrade. The breaking change could be announced well ahead, and people would have time to fix their stuff.

That would be akin to the government releasing a new regulation but not forcing anybody to upgrade directly, but by offering tax relieve to anybody who did.

It is acceptable to break compatibility to fix a security problem, but it needs to be a minimal break. The problem with this particular issue is that it's breaking compatibility with major applications, which is no good.

It is, and he's wrong, and he's usually wrong when security comes up.

See also git using SHA-1: people warned him about this, and he argued passionately and incorrectly that git doesn't use SHA-1 as an integrity measure. He also argued passionately and incorrectly that SHA-1 was unlikely to be broken and worrying about it was a waste of effort. And now other people are doing a lot of slow work to dig ourselves out of literally every single git repo in the world relying on a broken crypto primitive.

Security in git is done by signing tags with GPG. This signs the whole tree state as in all of commit IDs and blobs. To break that, you need to collide a blob hash and commit hash or potentially pack file hash. Much harder than doing it for one file. (Albeit git used to be lax with its compression allowing garbage at the end.)

It signs the whole tree state, which is a collection of SHA-1 hashes. If I'm interested in introducing a backdoor in an application, I'm basically only interested in colliding the hash of one file; colliding a SHA-1 signature on a file is exactly as hard as colliding the SHA-1 hash of a single file inside a git tree inside a git commit signed with a stronger-than-SHA-1 signature. That is, if I've collided the file's SHA-1 hash, the tree that contains the file is going to have the exact same hash because the tree contains the SHA-1 of the file.

Git is not really using SHA-1 for encryption, just as unique hashes. I think it is unlikely to get a collision in a non-contrived instance. Eventually git will move off of SHA-1, but I imagine it will never matter.

> Git is not really using SHA-1 for encryption, just as unique hashes.

By "encryption" do you mean "cryptography"?

If I sign a git tag, I am signing a data structure that consists of SHA-1 hashes of other data structures. Any attack on SHA-1 means that the thing I'm signing can be subverted.

So, yes, git is using SHA-1 for cryptographic purposes.

> I think it is unlikely to get a collision in a non-contrived instance.

Why do you think this? Usually in engineering we prefer to back up statements like this with evidence.

In particular, practical SHA-1 collisions have been demonstrated: https://shattered.io/

And an attacker is going to be trying to contrive a collision, are they not?

And none of this explains why git didn't use SHA-256 back when it was easy to change. Even if SHA-1 isn't broken in practice (which it is), there's no downside to using SHA-256.

Nobody uses SHA-1 for encryption; it is a hash function.

It certainly has been used for encryption and probably still is. I wouldn't lose any sleep hashing my passwords with it since most mortals couldn't break it. https://en.wikipedia.org/wiki/SHA-1#Cryptography

That's a list of places where SHA-1 is used as a hash function in cryptosystems.

Actually this is true on some level:

- He argues and argues that everything is fine

- Weeks later he fixes the issue

Conclusion: he was wrong