3 ms·
I've had a quick browse through the LibreSSL commits. There is some comedy gold in there. Check out: http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8
by loftsy 12y ago
I've had a quick browse through the LibreSSL commits. There is some comedy gold in there.
Check out:
http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bf http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a...
http://freshbsd.org/commit/openbsd/c862290df5533966091ded3906da184f1cac8675 http://freshbsd.org/commit/openbsd/c862290df5533966091ded390...
http://freshbsd.org/commit/openbsd/a35e815be16befe27ee3f7623adfd5fc5e6693f4 http://freshbsd.org/commit/openbsd/a35e815be16befe27ee3f7623...
- micv 12y agoStuff like this is why you need fresh, objective eyes to review critical code. It's too easy to miss things when you're deep in the weeds.
- raverbashing 12y agoThe big-endian x86 is probably the worse one, but they're all gold
- Intermernet 12y agoThat big-endian bug is a perfect example of OCD in coding. "I can't ever reach that code path so I'll remove it". I have caught myself doing this in some cases. I once removed a test to see if the CSPRNG was actually working because the test coverage showed that I could never reach that code-path. I then realised that this needed to be there, because otherwise, if the CSPRNG ever stopped working, the code wouldn't know about it, and (maybe) start using streams of zeroes as it's entropy. Sometimes you need to remember that hardware can fail, or be compromised, even though in most cases it will just cause the program to crash.