5 ms·

A genuine question: Why isn't it perfectly reasonable to accept to break compatibility in order to increase security? Isn't that what we do in our lifes all the

by madez 9y ago

A genuine question: Why isn't it perfectly reasonable to accept to break compatibility in order to increase security? Isn't that what we do in our lifes all the time? When the authorities issue new fire safety regulations for buildings, then that is breaking compatibility to the older building standard. We still do it because there is good reason. Sometimes even old buildings need to be retrofitted, and that is then what is done. I don't get Linus in this point, and suspect so far that he is wrong, or that I didn't get it yet.

amluto 9y ago
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.
vacri 9y ago
> 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.
- madez 9y ago
  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.
geofft 9y ago
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.
- waynecochran 9y ago
  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.
  - tptacek 9y ago
    Nobody uses SHA-1 for encryption; it is a hash function.
    - waynecochran 9y ago
      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 https://en.wikipedia.org/wiki/SHA-1#Cryptography
      - tptacek 9y ago
        That's a list of places where SHA-1 is used as a hash function in cryptosystems.
  - geofft 9y ago
    > 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/ 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.

by madez 9y ago

amluto 9y ago

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.

vacri 9y ago

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

madez 9y ago
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.

geofft 9y ago

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.

waynecochran 9y ago
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.
- tptacek 9y ago
  Nobody uses SHA-1 for encryption; it is a hash function.
  - waynecochran 9y ago
    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 https://en.wikipedia.org/wiki/SHA-1#Cryptography
    - tptacek 9y ago
      That's a list of places where SHA-1 is used as a hash function in cryptosystems.
- geofft 9y ago
  > 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/ 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.