4 ms·

It is possible the OpenSSH funding, since it is done through the OpenBSD Foundation, could, at the Foundation's discretion, go toward LibreSSL, since it's the s

by mjibson 12y ago

It is possible the OpenSSH funding, since it is done through the OpenBSD Foundation, could, at the Foundation's discretion, go toward LibreSSL, since it's the same group.

Alupis 12y ago
No it's not. Libressl is a different team; one that feels a fork was more appropriate than just fixing the problems in openssl. IMHO, libressl is a mistake. It's splitting resources over something that needs to be as air-tight as possible. I'd much rather have 1 really really good ssl library that everyone uses instead of 2 so-so ones.
- 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.
  - 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.
- forgottenpass 12y ago
  I'd much rather have 1 really really good ssl library that everyone uses instead of 2 so-so ones. That's reasonable, but those aren't the options at play here. Not only because GnuTLS is already a thing, but the chances of OpenSSL becoming really really good are questionable. An OpenBSD guy gave a talk a few weeks back where he said that Heartbleed wasn't the reason for the split, it was the reason for digging into the code and realizing that OpenSSL under current leadership isn't capable of being a really really good option. https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
- lomnakkus 12y ago
  "just fixing the problems in openssl." That's what libressl is about. If you're in any doubt, please see this talk: https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
  - Alupis 12y ago
    There is no doubt that is the intention. The doubt is whether or not it is a good call to fork openssl instead of attempting to get changes into upstream that fix it and make it better, safer, more reliable.
    - sigzero 12y ago
      Are we talking about OpenSSL that had bugs languishing for years? Yeah, good luck with that one. LibreSSL was the way to go and the OpenBSD folks are the ones I trust to do it.
      - Alupis 12y ago
        Yup, just like all these OpenSSH bugs: 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__... Fork it now! ~~~ Seriously, stop buying into all the hype generated by heartbleed. Things will simmer down, and it's doubtful libressl will replace openssl anytime in the next 5 years as the standard default ssl lib for many things. I do not buy into OpenSSL devs not wanting bugfixes. Where are the public rejections/closures of submitted fixes? There aren't any. There are just assumptions that they wont take certain patches, or submitted patches waiting for review (how about you jump in and help review?).
    - protomyth 12y ago
      Well, one of the bugs that got fixed in LibreSSL was reported to OpenSSL with a patch which was not applied. If they ignore that stuff, then you have to fork. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.htm...

by mjibson 12y ago

It is possible the OpenSSH funding, since it is done through the OpenBSD Foundation, could, at the Foundation's discretion, go toward LibreSSL, since it's the same group.

Alupis 12y ago

No it's not. Libressl is a different team; one that feels a fork was more appropriate than just fixing the problems in openssl. IMHO, libressl is a mistake. It's splitting resources over something that needs to be as air-tight as possible. I'd much rather have 1 really really good ssl library that everyone uses instead of 2 so-so ones.

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.
- 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.
forgottenpass 12y ago
I'd much rather have 1 really really good ssl library that everyone uses instead of 2 so-so ones. That's reasonable, but those aren't the options at play here. Not only because GnuTLS is already a thing, but the chances of OpenSSL becoming really really good are questionable. An OpenBSD guy gave a talk a few weeks back where he said that Heartbleed wasn't the reason for the split, it was the reason for digging into the code and realizing that OpenSSL under current leadership isn't capable of being a really really good option. https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
lomnakkus 12y ago
"just fixing the problems in openssl." That's what libressl is about. If you're in any doubt, please see this talk: https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
- Alupis 12y ago
  There is no doubt that is the intention. The doubt is whether or not it is a good call to fork openssl instead of attempting to get changes into upstream that fix it and make it better, safer, more reliable.
  - sigzero 12y ago
    Are we talking about OpenSSL that had bugs languishing for years? Yeah, good luck with that one. LibreSSL was the way to go and the OpenBSD folks are the ones I trust to do it.
    - Alupis 12y ago
      Yup, just like all these OpenSSH bugs: 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__... Fork it now! ~~~ Seriously, stop buying into all the hype generated by heartbleed. Things will simmer down, and it's doubtful libressl will replace openssl anytime in the next 5 years as the standard default ssl lib for many things. I do not buy into OpenSSL devs not wanting bugfixes. Where are the public rejections/closures of submitted fixes? There aren't any. There are just assumptions that they wont take certain patches, or submitted patches waiting for review (how about you jump in and help review?).
  - protomyth 12y ago
    Well, one of the bugs that got fixed in LibreSSL was reported to OpenSSL with a patch which was not applied. If they ignore that stuff, then you have to fork. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.htm...