4 ms·

> No it's not. Libressl is a different team OpenSSH and LibreSSL are both a part of OpenBSD. So when you donate to the OpenBSD Foundation, you are very much d

by clarry 12y ago

> No it's not. Libressl is a different team OpenSSH and LibreSSL are both a part of OpenBSD. So when you donate to the OpenBSD Foundation, you are very much donating to one project. > one that feels a fork was more appropriate than just fixing the problems in openssl You can't start fixing things in other peoples' source tree just like that. I'm pretty sure nothing useful would've come out of it if the OpenBSD folk had sent half a million lines in diffs to OpenSSL; http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.htm...

Alupis 12y ago
> You can't start fixing things in other peoples' source tree just like that. Yes, you can. It's called contributing to a project. If the "half million lines of diffs" were actually things needing fixing, then the upstream team would accept them. If they are not necessary changes (such as ripping out all windows compatibility), then no, they would reject such changes. It will take years, maybe a decade before a new ssl library becomes the "default". OpenSSL has a lot of ground covered and a lot of history. Yes, it's common knowledge that libressl started before heartbleed, but the reasons for the project being started are mostly along the lines of: 1) We don't think upstream would take these changes 2) We don't like some aspects of the design philosophy 3) We can do it better. All 3 reasons can be collapsed into a more focused effort to fix the already existing and very good ssl library; openssl.
- chrismonsanto 12y ago
  > Yes, you can. It's called contributing to a project. If the "half million lines of diffs" were actually things needing fixing, then the upstream team would accept them. If they are not necessary changes (such as ripping out all windows compatibility), then no, they would reject such changes. I take it you've never dealt with an inactive/apathetic upstream before? Just because someone is the steward of a project does not mean they should be. This is perhaps one of the most valid reasons to fork! The LibreSSL team says that there were big problems on the tracker that languished for years, such as OpenSSL not working correctly when you disable their custom memory allocator. If the OpenSSL team can't deal with bug reports in a timely fashion, what makes you think they will bother reviewing and merging hundreds of thousands of lines of code?
  - Alupis 12y ago
    Then you become the steward of the project and continue forward. Forking will introduce an untold number of new bugs, some of which may be worse than imagined. Right now, native libressl only works on bsd's, when openssl codebase works on many os's. There are ports being made, which will introduce more bugs. Bugs being in a tracker for years is not uncommon. Here's OpenSSH's tracker: https://bugzilla.mindrot.org/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=changeddate&product=Portable%20OpenSSH&query_based_on=&query_format=specific https://bugzilla.mindrot.org/buglist.cgi?bug_status=__open__... 331 bugs, a large majority of which are pre 2012. This is not a sign of inactive/apathetic developers. It's a sign of big and old projects. I have no doubt the OpenBSD folk are excited about this now... but 5 years from now? More? What's the long term viability of this project? Will they eventually put all OS's on an equal footing instead of *BSD's first and port to other OS's? Forking was not the answer. The answer was to fix the perceived problems in OpenSSL and make it as solid as it can be. It's splitting talent and resources unnecessarily. Especially when the two projects are under the same umbrella (OpenBSD Foundation).
    - chrismonsanto 12y ago
      > Then you become the steward of the project and continue forward. ... The answer was to fix the perceived problems in OpenSSL and make it as solid as it can be. It's splitting talent and resources unnecessarily. But that is what the fork is, OpenSSL with new stewards. What is your objection? That they are using a different name? That they decided to remove certain platforms which were a maintenance burden? That FIPS is broken by design and therefore isn't a priority? I imagine the OpenSSL team disagrees with the LibreSSL team on all of these issues. The only option was a fork. > Right now, native libressl only works on bsd's, when openssl codebase works on many os's. There are ports being made, which will introduce more bugs. One step backwards, two steps forward.
    - krunaldo 12y ago
      Most of these are related to portable openssh and not openssh. These are two very different teams.
- stephen_g 12y ago
  > It will take years, maybe a decade before a new ssl library becomes the "default". OpenSSL has a lot of ground covered and a lot of history. Why? The LibreSSL team are keeping the API backwards compatible, so it will literally be a drop-in replacement (once there are ports to other platforms). It should just require a recompile. Since the barrier to entry will be fairly low, it is foreseeable that it could become popular quite quickly.
ivoras 12y ago
Anyone interested in details of LibreSSL development can watch the BSDCan talk at https://www.youtube.com/watch?v=oM6S7FEUfkU https://www.youtube.com/watch?v=oM6S7FEUfkU - there really are a LOT of instances of braindamaged code in OpenSSL and a radical repair is pretty much the only thing which will work.

by clarry 12y ago

Alupis 12y ago

> You can't start fixing things in other peoples' source tree just like that. Yes, you can. It's called contributing to a project. If the "half million lines of diffs" were actually things needing fixing, then the upstream team would accept them. If they are not necessary changes (such as ripping out all windows compatibility), then no, they would reject such changes. It will take years, maybe a decade before a new ssl library becomes the "default". OpenSSL has a lot of ground covered and a lot of history. Yes, it's common knowledge that libressl started before heartbleed, but the reasons for the project being started are mostly along the lines of: 1) We don't think upstream would take these changes 2) We don't like some aspects of the design philosophy 3) We can do it better. All 3 reasons can be collapsed into a more focused effort to fix the already existing and very good ssl library; openssl.

chrismonsanto 12y ago
> Yes, you can. It's called contributing to a project. If the "half million lines of diffs" were actually things needing fixing, then the upstream team would accept them. If they are not necessary changes (such as ripping out all windows compatibility), then no, they would reject such changes. I take it you've never dealt with an inactive/apathetic upstream before? Just because someone is the steward of a project does not mean they should be. This is perhaps one of the most valid reasons to fork! The LibreSSL team says that there were big problems on the tracker that languished for years, such as OpenSSL not working correctly when you disable their custom memory allocator. If the OpenSSL team can't deal with bug reports in a timely fashion, what makes you think they will bother reviewing and merging hundreds of thousands of lines of code?
- Alupis 12y ago
  Then you become the steward of the project and continue forward. Forking will introduce an untold number of new bugs, some of which may be worse than imagined. Right now, native libressl only works on bsd's, when openssl codebase works on many os's. There are ports being made, which will introduce more bugs. Bugs being in a tracker for years is not uncommon. Here's OpenSSH's tracker: https://bugzilla.mindrot.org/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=changeddate&product=Portable%20OpenSSH&query_based_on=&query_format=specific https://bugzilla.mindrot.org/buglist.cgi?bug_status=__open__... 331 bugs, a large majority of which are pre 2012. This is not a sign of inactive/apathetic developers. It's a sign of big and old projects. I have no doubt the OpenBSD folk are excited about this now... but 5 years from now? More? What's the long term viability of this project? Will they eventually put all OS's on an equal footing instead of *BSD's first and port to other OS's? Forking was not the answer. The answer was to fix the perceived problems in OpenSSL and make it as solid as it can be. It's splitting talent and resources unnecessarily. Especially when the two projects are under the same umbrella (OpenBSD Foundation).
  - chrismonsanto 12y ago
    > Then you become the steward of the project and continue forward. ... The answer was to fix the perceived problems in OpenSSL and make it as solid as it can be. It's splitting talent and resources unnecessarily. But that is what the fork is, OpenSSL with new stewards. What is your objection? That they are using a different name? That they decided to remove certain platforms which were a maintenance burden? That FIPS is broken by design and therefore isn't a priority? I imagine the OpenSSL team disagrees with the LibreSSL team on all of these issues. The only option was a fork. > Right now, native libressl only works on bsd's, when openssl codebase works on many os's. There are ports being made, which will introduce more bugs. One step backwards, two steps forward.
  - krunaldo 12y ago
    Most of these are related to portable openssh and not openssh. These are two very different teams.
stephen_g 12y ago
> It will take years, maybe a decade before a new ssl library becomes the "default". OpenSSL has a lot of ground covered and a lot of history. Why? The LibreSSL team are keeping the API backwards compatible, so it will literally be a drop-in replacement (once there are ports to other platforms). It should just require a recompile. Since the barrier to entry will be fairly low, it is foreseeable that it could become popular quite quickly.

ivoras 12y ago

Anyone interested in details of LibreSSL development can watch the BSDCan talk at https://www.youtube.com/watch?v=oM6S7FEUfkU https://www.youtube.com/watch?v=oM6S7FEUfkU - there really are a LOT of instances of braindamaged code in OpenSSL and a radical repair is pretty much the only thing which will work.