7 ms·

Please read the commit log of LibreSSL and try not to face-palm. I think you will fail. The code quality they're up against is very often stuff you expect to fi

Please read the commit log of LibreSSL and try not to face-palm. I think you will fail. The code quality they're up against is very often stuff you expect to find at thedailywtf.com. It must always be ok to criticize (even in the form of mocking) bad code as long as the criticism comes with well written patches. OpenSSL should embrace the help they get for the greater good.

acqq 12y ago
If the mocking is the fair game, everybody can mock LibreSSL too for not actually finding the real security bugs that exist in their code after more months of publicly claiming they are "more secure." I admit they had a few ideas OK, but for my taste they made too much self-promotion and "mocking" of the original developers. I allow you the right to like that, I just state that I don't and stand behind it. See also fafner's comment here and think about it.
- chris_wot 12y ago
  OpenSSL is free to do that, but given the issues in their code it would probably backfire.
mp3geek 12y ago
Or instead of just forking OpenSSL then should help develop/submit patches to OpenSSL and improve the existing code base.
- acqq 12y ago
  And they could have found the security bugs and report them to OpenSSL even after they forked. If they actually did some serious security investigations of the code they took and kept in their fork, it should be natural to discover such issues and not just wait for others to find them in OpenSSL. Does anybody know of any such report?
  - vog 12y ago
    While I generally agree that this should be done, I'd also like to point out that many (most?) security fixes in LibreSSL are really "side effects" from trowing away lots of code, or cleaning it up.
    - acqq 12y ago
      That's my impression too, that they threw away a lot and replaced a few functions with the "good-practice in OpenSSL" ones, but otherwise haven't changed too much, so the code base can be easier to maintain but is not necessary "the" solution some believe it is.
- masklinn 12y ago
  > Or instead of just forking OpenSSL then should help develop/submit patches to OpenSSL and improve the existing code base. Part of the early LibreSSL work was auditing and merging security patches which had been in the OpenSSL tracker for months or years.
- rmc 12y ago
  Do LibreSSL and OpenSSL have the same goals? Do they both want to support the same features/hardware/etc.? If LibreSSL remove something because it's not needed for what LibreSSL wants to support, but OpenSSL does want to support it, then what should happen? Should it be removed? Or not? Different projects can have different goals.
- weland 12y ago
  A good portion of LibreSSL's patches are in the form of removing code for dead platforms like VAX/VMS and OS/2, problematic wrappers like openssl_malloc() or patching the everything-on-by-default approach that OpenSSL takes. The OpenSSL team actively refuses any such patches, which is why LibreSSL was forked in the first place.

acqq 12y ago

If the mocking is the fair game, everybody can mock LibreSSL too for not actually finding the real security bugs that exist in their code after more months of publicly claiming they are "more secure." I admit they had a few ideas OK, but for my taste they made too much self-promotion and "mocking" of the original developers. I allow you the right to like that, I just state that I don't and stand behind it. See also fafner's comment here and think about it.

chris_wot 12y ago
OpenSSL is free to do that, but given the issues in their code it would probably backfire.

mp3geek 12y ago

Or instead of just forking OpenSSL then should help develop/submit patches to OpenSSL and improve the existing code base.

acqq 12y ago
And they could have found the security bugs and report them to OpenSSL even after they forked. If they actually did some serious security investigations of the code they took and kept in their fork, it should be natural to discover such issues and not just wait for others to find them in OpenSSL. Does anybody know of any such report?
- vog 12y ago
  While I generally agree that this should be done, I'd also like to point out that many (most?) security fixes in LibreSSL are really "side effects" from trowing away lots of code, or cleaning it up.
  - acqq 12y ago
    That's my impression too, that they threw away a lot and replaced a few functions with the "good-practice in OpenSSL" ones, but otherwise haven't changed too much, so the code base can be easier to maintain but is not necessary "the" solution some believe it is.
masklinn 12y ago
> Or instead of just forking OpenSSL then should help develop/submit patches to OpenSSL and improve the existing code base. Part of the early LibreSSL work was auditing and merging security patches which had been in the OpenSSL tracker for months or years.
rmc 12y ago
Do LibreSSL and OpenSSL have the same goals? Do they both want to support the same features/hardware/etc.? If LibreSSL remove something because it's not needed for what LibreSSL wants to support, but OpenSSL does want to support it, then what should happen? Should it be removed? Or not? Different projects can have different goals.
weland 12y ago
A good portion of LibreSSL's patches are in the form of removing code for dead platforms like VAX/VMS and OS/2, problematic wrappers like openssl_malloc() or patching the everything-on-by-default approach that OpenSSL takes. The OpenSSL team actively refuses any such patches, which is why LibreSSL was forked in the first place.