8 ms·

LibreSSL 2.1.5 released

96 points by fcambus 12y ago

fcambus 12y ago
From the release announcement : This or earlier LibreSSL releases may also address issues that are to be revealed by The OpenSSL Project Team on the 19th of March, 2015.
- 0x0 12y ago
  That sounds a bit passive-aggressive, no?
  - chris_wot 12y ago
    Passive-aggressive from whom? OpenSSL who don't tell LibreSSL about security flaws, or LibreSSL who need to wait for OpenSSL to do a release before they can find out about security vulnerabilities?
    - acqq 12y ago
      Why should OpenSSL tell anything to LibreSSL? LibreSSL had very negative words for OpenSSL in the past and tried to build the impression of being "more secure" just based on the "low hanging fruits." It's easy to make the fork and reformat or remove the parts of the code. It's much harder to find the real security problems in what remains. If I were in OpenSSL team I would also not tell LibreSSL anything and then in, for example, a year show statistics how often LibreSSL wasn't "more secure" at all. That's a fair comparison. (1) Hard problems are hard. 1) Edit: but see fafner's comment here, it seems the truth is even harder to believe: it seems it's the LibreSSL guys themselves who decided not to be informed and now write what they write(!)
      - pfortuny 12y ago
        Now that is not a very engineering-wise useful behavior. You may feel bad (I mean OpenSSL not "you") but do you want a better Internet or not? It is as easy as an encrypted email.
        acqq 12y ago
        Put yourself in OpenSSL shoes. Would you then really send your still confidential bugs to the people who claimed you're incompetent but they themselves didn't remove the said bugs after promoting their work and speaking bad about you for months? Even if you would, can you know if they would not leak them before your correspondents (which include really big companies which can really be in danger if the leak occurs) are ready? (See fafner's comment here for some details -- apparently LibreSSL people didn't want to guarantee not to leak(!)) You just know they are antagonistic to you.
        sigzero 12y ago
        No, they have different goals and different standards. I think people are attributing "antagonistic" when it really isn't there or is not nearly at the level the general geekdom thinks it is. Theo doesn't believe in embargoes. Theo doesn't want to be a part of yet another list when he is already swamped with the task load he has. I see zero problem with that. That the OpenSSL and LibreSSL teams talk is readily apparent though.
      - nononononono 12y ago
        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.
    - fafner 12y ago
      Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list? At least that was the case the last time the LibreSSL devs complained about not receiving any vuln info in advance...
      - masklinn 12y ago
        > Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list? Would you have a source for that? And for their reasoning behind it? Was "last time" poodle or something else? edit: in the sister thread[0] rlpb suggests the point of contention is that OpenSSL embargoes but Theo/OpenBSD (and thus libressl) does not take part in embargoes (and other issues including Theo being Theo), linking to http://lwn.net/Articles/601958/ http://lwn.net/Articles/601958/ as supporting evidence, which looks to cover just about all grounds. [0] https://news.ycombinator.com/item?id=9217022 https://news.ycombinator.com/item?id=9217022
        acqq 12y ago
        > Was "last time" poodle or something else? Excuse me please, I see you are emotional about the issue but I don't think it's the good way to discuss it. Asking for the source for the claim is OK, this however...
        masklinn 12y ago
        > Excuse me please, I see you are emotional about the issue […] Asking for the source for the claim is OK, this however... Uh what? I was just providing a relatively recent issue which IIRC libressl was also affected by as a possible candidate (turns out the issue in question is much older and not a "named vulnerability")
        rlpb 12y ago
        Story, with sources, at: http://lwn.net/Articles/601958/ http://lwn.net/Articles/601958/ They were asked to join the distros list, and they declined.
  - nodata 12y ago
    This comment is why we need a "DERAIL" button here. To split it into a different area. The comment is perhaps valid, but deflects from the discussion. Yet here it is sitting at the top of the comments page. Not ideal.
    - protomyth 12y ago
      "Take it to Tangency" was the old phrase on rpg.net
  - gonzo 12y ago
    It's quite PA when you know what the Friday disclosure is about and can see the LibreSSL hasn't (accidentally) fixed it.
    - akerl_ 12y ago
      Given that OpenSSL tried to get LibreSSL on the embargo list and the LibreSSL team declined due to their stance on embargoes, it seems uneventful to find out that they didn't did early access to this embargoed information.
- busterb 12y ago
  The question of whether LibreSSL has fixes for OpenSSL issues comes up frequently enough that it made sense to note it directly. Fixes and improvements have certainly been shared between the Boring, Open and LibreSSL teams, and we look forward to further cooperation. It is obviously beneficial. LibreSSL has in the past mitigated issues that later became known in OpenSSL through security updates. Sometimes, it has been still vulnerable to OpenSSL issues as well. Hopefully we'll fall into the former camp this time around. To the security researchers and developers who have reached out, we are very grateful.
Ono-Sendai 12y ago
Nice to see some work being done on the Windows port!
busterb 12y ago
The LibreSSL version scheme corresponds to OpenBSD version numbers: 2.0.x -> OpenBSD 5.6, 2.1.x -> OpenBSD 5.7, 2.2.x -> OpenBSD 5.8, Development slowed approaching the end of 2.1.x as the OpenBSD tree went in release mode lockdown. It is interesting to see the development coordination that stops and restarts the tree activity. Things in the pipeline for 2.2.x include AIX, Cygwin, Visual Studio support, and wider support for optimizations (currently only ELF/OS X x64 is supported). In general, expect libtls to expand in features and improve usability, more code to be pruned and simplified. There were not many SSL patches for OpenBSD 5.6, and there were not any LibreSSL 2.0.x releases after 2.1.x began. However, we are looking at possibly releasing further 2.1.x updates if there is interest. They would correspond to OpenBSD 5.7 errata.
- kymywho 12y ago
  If the LibreSSL corresponds to OpenBSD version numbers then it should be numbered 2.5.6 => 2.5.7 => 2.5.8 etc.
  - busterb 12y ago
    We wanted to also push out releases faster than OpenBSD's 6 month cycle. Maybe we should have started at 5.6.0. I dunno, hindsight is 20/20.

96 points by fcambus 12y ago

From the release announcement : This or earlier LibreSSL releases may also address issues that are to be revealed by The OpenSSL Project Team on the 19th of March, 2015.

0x0 12y ago
That sounds a bit passive-aggressive, no?
- chris_wot 12y ago
  Passive-aggressive from whom? OpenSSL who don't tell LibreSSL about security flaws, or LibreSSL who need to wait for OpenSSL to do a release before they can find out about security vulnerabilities?
  - acqq 12y ago
    Why should OpenSSL tell anything to LibreSSL? LibreSSL had very negative words for OpenSSL in the past and tried to build the impression of being "more secure" just based on the "low hanging fruits." It's easy to make the fork and reformat or remove the parts of the code. It's much harder to find the real security problems in what remains. If I were in OpenSSL team I would also not tell LibreSSL anything and then in, for example, a year show statistics how often LibreSSL wasn't "more secure" at all. That's a fair comparison. (1) Hard problems are hard. 1) Edit: but see fafner's comment here, it seems the truth is even harder to believe: it seems it's the LibreSSL guys themselves who decided not to be informed and now write what they write(!)
    - pfortuny 12y ago
      Now that is not a very engineering-wise useful behavior. You may feel bad (I mean OpenSSL not "you") but do you want a better Internet or not? It is as easy as an encrypted email.
      - acqq 12y ago
        Put yourself in OpenSSL shoes. Would you then really send your still confidential bugs to the people who claimed you're incompetent but they themselves didn't remove the said bugs after promoting their work and speaking bad about you for months? Even if you would, can you know if they would not leak them before your correspondents (which include really big companies which can really be in danger if the leak occurs) are ready? (See fafner's comment here for some details -- apparently LibreSSL people didn't want to guarantee not to leak(!)) You just know they are antagonistic to you.
        sigzero 12y ago
        No, they have different goals and different standards. I think people are attributing "antagonistic" when it really isn't there or is not nearly at the level the general geekdom thinks it is. Theo doesn't believe in embargoes. Theo doesn't want to be a part of yet another list when he is already swamped with the task load he has. I see zero problem with that. That the OpenSSL and LibreSSL teams talk is readily apparent though.
    - nononononono 12y ago
      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.
  - fafner 12y ago
    Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list? At least that was the case the last time the LibreSSL devs complained about not receiving any vuln info in advance...
    - masklinn 12y ago
      > Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list? Would you have a source for that? And for their reasoning behind it? Was "last time" poodle or something else? edit: in the sister thread[0] rlpb suggests the point of contention is that OpenSSL embargoes but Theo/OpenBSD (and thus libressl) does not take part in embargoes (and other issues including Theo being Theo), linking to http://lwn.net/Articles/601958/ http://lwn.net/Articles/601958/ as supporting evidence, which looks to cover just about all grounds. [0] https://news.ycombinator.com/item?id=9217022 https://news.ycombinator.com/item?id=9217022
      - acqq 12y ago
        > Was "last time" poodle or something else? Excuse me please, I see you are emotional about the issue but I don't think it's the good way to discuss it. Asking for the source for the claim is OK, this however...
        masklinn 12y ago
        > Excuse me please, I see you are emotional about the issue […] Asking for the source for the claim is OK, this however... Uh what? I was just providing a relatively recent issue which IIRC libressl was also affected by as a possible candidate (turns out the issue in question is much older and not a "named vulnerability")
      - rlpb 12y ago
        Story, with sources, at: http://lwn.net/Articles/601958/ http://lwn.net/Articles/601958/ They were asked to join the distros list, and they declined.
- nodata 12y ago
  This comment is why we need a "DERAIL" button here. To split it into a different area. The comment is perhaps valid, but deflects from the discussion. Yet here it is sitting at the top of the comments page. Not ideal.
  - protomyth 12y ago
    "Take it to Tangency" was the old phrase on rpg.net
- gonzo 12y ago
  It's quite PA when you know what the Friday disclosure is about and can see the LibreSSL hasn't (accidentally) fixed it.
  - akerl_ 12y ago
    Given that OpenSSL tried to get LibreSSL on the embargo list and the LibreSSL team declined due to their stance on embargoes, it seems uneventful to find out that they didn't did early access to this embargoed information.
busterb 12y ago
The question of whether LibreSSL has fixes for OpenSSL issues comes up frequently enough that it made sense to note it directly. Fixes and improvements have certainly been shared between the Boring, Open and LibreSSL teams, and we look forward to further cooperation. It is obviously beneficial. LibreSSL has in the past mitigated issues that later became known in OpenSSL through security updates. Sometimes, it has been still vulnerable to OpenSSL issues as well. Hopefully we'll fall into the former camp this time around. To the security researchers and developers who have reached out, we are very grateful.

Ono-Sendai 12y ago

Nice to see some work being done on the Windows port!

busterb 12y ago

The LibreSSL version scheme corresponds to OpenBSD version numbers: 2.0.x -> OpenBSD 5.6, 2.1.x -> OpenBSD 5.7, 2.2.x -> OpenBSD 5.8, Development slowed approaching the end of 2.1.x as the OpenBSD tree went in release mode lockdown. It is interesting to see the development coordination that stops and restarts the tree activity. Things in the pipeline for 2.2.x include AIX, Cygwin, Visual Studio support, and wider support for optimizations (currently only ELF/OS X x64 is supported). In general, expect libtls to expand in features and improve usability, more code to be pruned and simplified. There were not many SSL patches for OpenBSD 5.6, and there were not any LibreSSL 2.0.x releases after 2.1.x began. However, we are looking at possibly releasing further 2.1.x updates if there is interest. They would correspond to OpenBSD 5.7 errata.

kymywho 12y ago
If the LibreSSL corresponds to OpenBSD version numbers then it should be numbered 2.5.6 => 2.5.7 => 2.5.8 etc.
- busterb 12y ago
  We wanted to also push out releases faster than OpenBSD's 6 month cycle. Maybe we should have started at 5.6.0. I dunno, hindsight is 20/20.