4 ms·

Is there any coordination between OpenBSD and the Linux Foundation? For example, did the Linux Foundation consider adopting OpenBSD's fork rather than auditing

Is there any coordination between OpenBSD and the Linux Foundation? For example, did the Linux Foundation consider adopting OpenBSD's fork rather than auditing and fixing the original? EDIT: What is the status of LibreSSL?

tedunangst 12y ago
Auditing and fixing the original still improves LibreSSL, although one of the main goals of LibreSSL was to clean things up to make that easier. Last LibreSSL release was 2.1.4 last week, although a minor update should be coming soon. http://marc.info/?l=openbsd-announce&m=142543818707898&w=2 http://marc.info/?l=openbsd-announce&m=142543818707898&w=2 LibreSSL is going to track OpenBSD versions, so now that OpenBSD 5.7 is done, the LibreSSL 2.1.x series is done (except to receive patches). At some point a 2.2 release will be made, corresponding to new developments.
- hackuser 12y ago
  Thanks. Did OpenBSD get the funding they sought for LibreSSL? How mature is it at this point? I see it's included (?) with OpenBSD, which is a good sign.
- nailer 12y ago
  libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.
  - Alupis 12y ago
    > libressl's binary is already half the size of openssl What does binary size have to do with quality? OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community. For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time. Remember, OpenSSL really only had 1 developer and only received around $2,000 a year in donations prior to Heartbleed[1] (which is grossly pathetic for such a critical piece of software). If those numbers had been tenfold or more, perhaps the bugs that led to Heartbleed may have been found and fixed long before they were an issue. Thankfully the Linux Foundation and the Core Infrastructure Initiative are aiming to remedy this. [1] http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/ http://arstechnica.com/information-technology/2014/04/tech-g...
    - green7ea 12y ago
      > What does binary size have to do with quality? I think grandparent meant that binary size is related to code size. The number of bugs being related to the number of lines of code, you could infer that a bigger binary means more lines of code which means more bugs. In my experience, this tends to be true. Of course this makes the big assumption that the binaries have been compiled with similar compilers using similar optimizations and are both stripped.
    - nailer 12y ago
      > What does binary size have to do with quality? Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you? http://opensslrampage.org/ http://opensslrampage.org/
      - Alupis 12y ago
        It doesn't indicate either way. If the code is in there, if it works for those platforms, and has no adverse effects on other portions of the codebase, then it doesn't matter (those code paths are never executed unless you run on those platforms).
        nailer 12y ago
        You can't guarantee that code path never gets executed. For a good historical example, Windows NT4 also came with inbuilt OS/2 and POSIX subsystems that were never used by users, but typically used by people on the internet to crack boxes.
        xorcist 12y ago
        While I haven't look at the OS/2 support of OpensSSL specifically, surely it is not a question about code that it never executed, but code that is never built on a modern system. That makes it more a question about code maintainability and code readability, rather than security problems with seldom executed code.
coldpie 12y ago
I have to say, LibreSSL's snarky PR stance when it was first launched really turned me off. This stuff is hard and the code is old; being an asshole about the code quality is really inappropriate. Has their behavior matured since then?
- pakled_engineer 12y ago
  No reason you can't look at the recent commits yourself and determine if they are 'mature' enough for you.
  - Alupis 12y ago
    They did really try to seize the moment and imho did act a bit disingenuous towards OpenSSL. They even played on the point that OpenSSL's coding style wasn't "modern" and adequate and therefore made it near impossible for people to work on[1]. Since when does having curly brackets on different lines make something impossible to read? They also gutted more than 90,000 lines in the first month (something that would be naive to claim had absolutely no unintended side effects), and claimed the OpenSSL project would not accept a single change (sort of alluding to the OpenSSL project having some delusional desire to stay "broken"), mandating the fork[1][2]. OpenSSL was largely written by cryptographers. LibreSSL is being hacked on by OpenBSD developers. OpenSSL's code may not be pretty, but I sure think it would have been a better use of time and efforts to have the OpenBSD developers work alongside the OpenSSL cryptographers. [1] http://www.infoq.com/news/2014/05/libre-ssl-first-30-days http://www.infoq.com/news/2014/05/libre-ssl-first-30-days [2] http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/ http://arstechnica.com/information-technology/2014/04/openss...
    - pakled_engineer 12y ago
      They did, but they also were frustrated beyond sanity at what OpenSSL was doing like adding a wrapper around malloc & free and that was new code not old legacy cruft that can be excused. It also taught us all an important lesson in rage commits when Theo screwed up one of them :-P

tedunangst 12y ago

Auditing and fixing the original still improves LibreSSL, although one of the main goals of LibreSSL was to clean things up to make that easier. Last LibreSSL release was 2.1.4 last week, although a minor update should be coming soon. http://marc.info/?l=openbsd-announce&m=142543818707898&w=2 http://marc.info/?l=openbsd-announce&m=142543818707898&w=2 LibreSSL is going to track OpenBSD versions, so now that OpenBSD 5.7 is done, the LibreSSL 2.1.x series is done (except to receive patches). At some point a 2.2 release will be made, corresponding to new developments.

hackuser 12y ago
Thanks. Did OpenBSD get the funding they sought for LibreSSL? How mature is it at this point? I see it's included (?) with OpenBSD, which is a good sign.
nailer 12y ago
libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.
- Alupis 12y ago
  > libressl's binary is already half the size of openssl What does binary size have to do with quality? OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community. For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time. Remember, OpenSSL really only had 1 developer and only received around $2,000 a year in donations prior to Heartbleed[1] (which is grossly pathetic for such a critical piece of software). If those numbers had been tenfold or more, perhaps the bugs that led to Heartbleed may have been found and fixed long before they were an issue. Thankfully the Linux Foundation and the Core Infrastructure Initiative are aiming to remedy this. [1] http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/ http://arstechnica.com/information-technology/2014/04/tech-g...
  - green7ea 12y ago
    > What does binary size have to do with quality? I think grandparent meant that binary size is related to code size. The number of bugs being related to the number of lines of code, you could infer that a bigger binary means more lines of code which means more bugs. In my experience, this tends to be true. Of course this makes the big assumption that the binaries have been compiled with similar compilers using similar optimizations and are both stripped.
  - nailer 12y ago
    > What does binary size have to do with quality? Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you? http://opensslrampage.org/ http://opensslrampage.org/
    - Alupis 12y ago
      It doesn't indicate either way. If the code is in there, if it works for those platforms, and has no adverse effects on other portions of the codebase, then it doesn't matter (those code paths are never executed unless you run on those platforms).
      - nailer 12y ago
        You can't guarantee that code path never gets executed. For a good historical example, Windows NT4 also came with inbuilt OS/2 and POSIX subsystems that were never used by users, but typically used by people on the internet to crack boxes.
        xorcist 12y ago
        While I haven't look at the OS/2 support of OpensSSL specifically, surely it is not a question about code that it never executed, but code that is never built on a modern system. That makes it more a question about code maintainability and code readability, rather than security problems with seldom executed code.

coldpie 12y ago

I have to say, LibreSSL's snarky PR stance when it was first launched really turned me off. This stuff is hard and the code is old; being an asshole about the code quality is really inappropriate. Has their behavior matured since then?

pakled_engineer 12y ago
No reason you can't look at the recent commits yourself and determine if they are 'mature' enough for you.
- Alupis 12y ago
  They did really try to seize the moment and imho did act a bit disingenuous towards OpenSSL. They even played on the point that OpenSSL's coding style wasn't "modern" and adequate and therefore made it near impossible for people to work on[1]. Since when does having curly brackets on different lines make something impossible to read? They also gutted more than 90,000 lines in the first month (something that would be naive to claim had absolutely no unintended side effects), and claimed the OpenSSL project would not accept a single change (sort of alluding to the OpenSSL project having some delusional desire to stay "broken"), mandating the fork[1][2]. OpenSSL was largely written by cryptographers. LibreSSL is being hacked on by OpenBSD developers. OpenSSL's code may not be pretty, but I sure think it would have been a better use of time and efforts to have the OpenBSD developers work alongside the OpenSSL cryptographers. [1] http://www.infoq.com/news/2014/05/libre-ssl-first-30-days http://www.infoq.com/news/2014/05/libre-ssl-first-30-days [2] http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/ http://arstechnica.com/information-technology/2014/04/openss...
  - pakled_engineer 12y ago
    They did, but they also were frustrated beyond sanity at what OpenSSL was doing like adding a wrapper around malloc & free and that was new code not old legacy cruft that can be excused. It also taught us all an important lesson in rage commits when Theo screwed up one of them :-P