3 ms·

In my opinion, it's much much better that this was corrected! If there were to be any bug of any kind, -CURRENT is the best place in freebsd to have it. I'm no

In my opinion, it's much much better that this was corrected! If there were to be any bug of any kind, -CURRENT is the best place in freebsd to have it. I'm not sure what you're trying to argue for/against unless you are looking at things from a pure number theory/computer science research point of view? What would people do then? Create perfect flawless code that never malfunctions even as they write it? Code that never has bugs does not exist. Perfect algorithms don't exist either. -CURRENT is exactly the place for this because RNG bugs exist in reality. If you read emaste's post above, this bug "potentially generates easily crackable crypto keys" for the safe to a monopoly game that holds monopoly money. It's a development kernel.

mikeash 12y ago
The only thing I'm arguing here is that dealing with crashes does not imply you can deal with severe crypto compromises. In short, that the above-quoted tweet is completely bogus. That's all.
- coldtea 12y ago
  How are "severe crypto compromises" any worse than crashes and potential data corruption and business interruption?
  - detaro 12y ago
    A crashing test environment is no real danger, a compromised test environment could be the source of a lot of trouble (stealing code deployed to it, ...). Of course, it shouldn't be exposed enough to be successfully attacked in the first place...
  - nitrogen 12y ago
    Any ssh key generated with a bad RNG could be easily crackable, as an example.
  - mikeash 12y ago
    Because it poisons data produced on that machine in an invisible way. Normally you could use a system like this on a trial basis and keep the results. For example, you might run some image processing on it. You'd want to make sure the output was good, but having done so you could then use those images for real-world tasks without worry. But replace "image processing" with "generate a private key" and now you're deeply screwed. Well, now we know. Don't generate crypto keys on pre-release OSes that you're going to use for anything important. That's reasonable. But I don't think many people would have thought that way before. And of course pre-release OSes aren't the only place the danger lies. Debian had a similar problem that made it to releases and stayed undetected for a couple of years. The point is just that "silently break all your crypto" is a much worse vulnerability than mere crashes, or even corruption.

mikeash 12y ago

The only thing I'm arguing here is that dealing with crashes does not imply you can deal with severe crypto compromises. In short, that the above-quoted tweet is completely bogus. That's all.

coldtea 12y ago
How are "severe crypto compromises" any worse than crashes and potential data corruption and business interruption?
- detaro 12y ago
  A crashing test environment is no real danger, a compromised test environment could be the source of a lot of trouble (stealing code deployed to it, ...). Of course, it shouldn't be exposed enough to be successfully attacked in the first place...
- nitrogen 12y ago
  Any ssh key generated with a bad RNG could be easily crackable, as an example.
- mikeash 12y ago
  Because it poisons data produced on that machine in an invisible way. Normally you could use a system like this on a trial basis and keep the results. For example, you might run some image processing on it. You'd want to make sure the output was good, but having done so you could then use those images for real-world tasks without worry. But replace "image processing" with "generate a private key" and now you're deeply screwed. Well, now we know. Don't generate crypto keys on pre-release OSes that you're going to use for anything important. That's reasonable. But I don't think many people would have thought that way before. And of course pre-release OSes aren't the only place the danger lies. Debian had a similar problem that made it to releases and stayed undetected for a couple of years. The point is just that "silently break all your crypto" is a much worse vulnerability than mere crashes, or even corruption.