9 ms·

> removed MacOS, Netware, OS/2, VMS and Windows build machinery What are the plans for native Windows support? I don't know what they mean by "The right Portab

by abcd_f 13y ago

> removed MacOS, Netware, OS/2, VMS and Windows build machinery What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."

bananas 13y ago
Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.
- abcd_f 13y ago
  There's a ton of Windows software that uses OpenSSL as their security library. Moreover, there is a lot of Windows projects that are written in inherently portable way and using OpenSSL API is the most natural choice for them. If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.
  - bananas 13y ago
    Well I disagree. Whilst it's a natural choice for portability, when you port to a proprietary platform such as windows you lose a lot of the support and portability guarantees that POSIX gives you and the calling conventions and standards of many libraries. At this point it's advisable to pick a holistic 3rd party abstraction over this such as something right from APR to Qt that will abstract the platform specific implementation away. Some people write a lot of stuff plugged into Win32 without considering the CSPs and pull in OpenSSL without thought. Their funeral. As my father said: "when in France, talk French or hire a translator".
    - huhtenberg 13y ago
      This is all great, but the fact remains that OpenSSL is very widely used on Windows and yanking it out without providing a drop-in replacement option is a bad idea. We can debate finer nuances of proper abstraction to the death, but it doesn't move a needle for people who already have OpenSSL dependencies in their code.
      - whatevsbro 13y ago
        > the fact remains that OpenSSL is very widely used on Windows and yanking it out without providing a drop-in replacement option is a bad idea The LibreSSL guys are not yanking anything out of Windows, they're just providing an alternative to OpenSSL, for all the world to use, for free. They're not under any obligation to support Windows, no matter how bad you want them to.
        huhtenberg 13y ago
        I don't expect them to support Windows, you misunderstand the whole concern. The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time. This is not a start of a beautiful friendship. Throw in a bit of crowd lynching (to the tune of "OpenBSD is showing OpenSSL how to do security right") and we can end up with OpenSSL devs showing a finger and throwing in a towel. At best, we'll have to related SSL implementations, devs of which don't really talk to each other. That's the issue.
        Sanddancer 13y ago
        People have been saying that OpenSSL has been of poor quality [1], that the documentation is bad [2], and the developers don't really listen [3] for years. Heartbleed was just the straw that broke the camel's back. OpenSSL really was one of those pieces of software that was Just Good Enough that people tolerated it, but at the same time, filled them with a desire to punch kittens whenever they had to code with it. [1] https://www.peereboom.us/assl/assl/html/openssl.html https://www.peereboom.us/assl/assl/html/openssl.html [2] http://www.ibm.com/developerworks/opensource/library/l-openssl/index.html http://www.ibm.com/developerworks/opensource/library/l-opens... [3] http://lists.randombit.net/pipermail/cryptography/2012-October/003409.html http://lists.randombit.net/pipermail/cryptography/2012-Octob...
  - DCKing 13y ago
    Windows is just a little too different for them to make a proper purge of the project right now. Having Windows support is just a much larger cross-cutting concern than a Unix-like OS, which appears to be the only category of operating system they're currently supporting. Windows will probably get a port some time later on. Remember that OpenSSH's libssh also has Windows support. It's just not something that fits in their current short term goals of fixing up OpenSSL (I like the term flensing they're using).
    - Flenser 12y ago
      > I like the term flensing they're using Indeed!
  - higherpurpose 13y ago
    If that Windows software doesn't need SSL, then it should just use NaCl anyway.
  - mariuolo 13y ago
    > If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers. Can you elaborate on that? I thought StartSSL was a certification authority.
  - a3n 13y ago
    > There's a ton of Windows software that uses OpenSSL And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch. OpenBSD can't do everything at once.
  - teacup50 13y ago
    > There's a ton of Windows software that uses OpenSSL as their security library. Yes, and most of it is awful because they shouldn't. I hate manually configuring SSL certificates for OpenSSL-using Windows software. Write a socket transport portability layer. It's not that hard, and you almost certainly need one anyway.
- orthecreedence 13y ago
  Ehh, I maintain a few libs that rely on the OpenSSL Windows ports. I'm not too keen on writing a compatibility layer that says "if windows, use the MS version, else use libreSSL!" I'm fine with them not supporting MSVC in the build, but is it really that much harder to support something like MinGW/MSYS? No need for Cygwin. The whole point of OpenSSL was that it runs everywhere. If we're going to write a shiny new version, let's at least try to hit the major platforms.
  - asddubs 13y ago
    you can write a layer that says "if windows, use openssl, else use libreSSL"
  - Sanddancer 13y ago
    I imagine that's what the supported option is going to be. Given that the OpenSSH documentation explicitly lists Cygwin as the way to run it for windows, similar will probably happen for LibreSSL. The OpenBSD team has always had another team handle porting of their libraries, and they do a pretty good job of it.
  - stuaxo 13y ago
    It's probably easier to cut the code right down to size now, then re-add compatibility once the base is solid. Given how knarly build systems can be, then only supporting modern versions of the same could help remove a lot of cruft.
  - AlexMeesters 13y ago
    Its not a replacement for OpenSSL, OpenSSL will continue to exists as it is, but in a while when libressl is stable enough you can choose on or the other. Its just a fork.
deleted 13y ago
[deleted]
frik 13y ago
maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services http://en.wikipedia.org/wiki/Network_Security_Services
- ProblemFactory 13y ago
  Curiously, the Heartbleed bug was found by the Google engineer who is working on replacing NSS with OpenSSL in Chrome: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53... From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.
  - rockdoe 13y ago
    The reasoning there is, certainly post-Heartbleed, very scary. Their conclusion boils down to that they want to use the system-provided OpenSSL on Android, rather than shipping NSS. This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone. Oh, I see the point already...
    - thefreeman 13y ago
      I mean couldn't you say the same thing if a vulnerability was found in NSS?
      - mercurial 13y ago
        No, because Android system updates are slow to come (or may never happen), while anything coming from the Google Play store (like Chrome) is timely.
ZoFreX 13y ago
I don't see why this product would have a different porting strategy to the usual way OpenBSD projects (such as OpenSSH) handle it - target OpenBSD exclusively in the core project, and support other platforms with ports. Presumably that's what they are going to do here.
- acqq 13y ago
  As far as I know OpenSSH doesn't work natively on Windows, only over Cygwin, that is, with the whole Linux environment by Red Hat.
masklinn 13y ago
FWIW the usual OpenBSD story is "get it working, reliable and simple, on (Open)BSD, then add porting shims" (they'll have to add shims for linux anyway if they start using strlcpy)
teacup50 13y ago
Most (all?) native Windows applications shouldn't use OpenSSL. They should use the operating system-shipped APIs, along with the OS-shipped certificate stores. That means SChannel and CryptoAPIs in native code.

by abcd_f 13y ago

bananas 13y ago

Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.

abcd_f 13y ago
There's a ton of Windows software that uses OpenSSL as their security library. Moreover, there is a lot of Windows projects that are written in inherently portable way and using OpenSSL API is the most natural choice for them. If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.
- bananas 13y ago
  Well I disagree. Whilst it's a natural choice for portability, when you port to a proprietary platform such as windows you lose a lot of the support and portability guarantees that POSIX gives you and the calling conventions and standards of many libraries. At this point it's advisable to pick a holistic 3rd party abstraction over this such as something right from APR to Qt that will abstract the platform specific implementation away. Some people write a lot of stuff plugged into Win32 without considering the CSPs and pull in OpenSSL without thought. Their funeral. As my father said: "when in France, talk French or hire a translator".
  - huhtenberg 13y ago
    This is all great, but the fact remains that OpenSSL is very widely used on Windows and yanking it out without providing a drop-in replacement option is a bad idea. We can debate finer nuances of proper abstraction to the death, but it doesn't move a needle for people who already have OpenSSL dependencies in their code.
    - whatevsbro 13y ago
      > the fact remains that OpenSSL is very widely used on Windows and yanking it out without providing a drop-in replacement option is a bad idea The LibreSSL guys are not yanking anything out of Windows, they're just providing an alternative to OpenSSL, for all the world to use, for free. They're not under any obligation to support Windows, no matter how bad you want them to.
      - huhtenberg 13y ago
        I don't expect them to support Windows, you misunderstand the whole concern. The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time. This is not a start of a beautiful friendship. Throw in a bit of crowd lynching (to the tune of "OpenBSD is showing OpenSSL how to do security right") and we can end up with OpenSSL devs showing a finger and throwing in a towel. At best, we'll have to related SSL implementations, devs of which don't really talk to each other. That's the issue.
        Sanddancer 13y ago
        People have been saying that OpenSSL has been of poor quality [1], that the documentation is bad [2], and the developers don't really listen [3] for years. Heartbleed was just the straw that broke the camel's back. OpenSSL really was one of those pieces of software that was Just Good Enough that people tolerated it, but at the same time, filled them with a desire to punch kittens whenever they had to code with it. [1] https://www.peereboom.us/assl/assl/html/openssl.html https://www.peereboom.us/assl/assl/html/openssl.html [2] http://www.ibm.com/developerworks/opensource/library/l-openssl/index.html http://www.ibm.com/developerworks/opensource/library/l-opens... [3] http://lists.randombit.net/pipermail/cryptography/2012-October/003409.html http://lists.randombit.net/pipermail/cryptography/2012-Octob...
- DCKing 13y ago
  Windows is just a little too different for them to make a proper purge of the project right now. Having Windows support is just a much larger cross-cutting concern than a Unix-like OS, which appears to be the only category of operating system they're currently supporting. Windows will probably get a port some time later on. Remember that OpenSSH's libssh also has Windows support. It's just not something that fits in their current short term goals of fixing up OpenSSL (I like the term flensing they're using).
  - Flenser 12y ago
    > I like the term flensing they're using Indeed!
- higherpurpose 13y ago
  If that Windows software doesn't need SSL, then it should just use NaCl anyway.
- mariuolo 13y ago
  > If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers. Can you elaborate on that? I thought StartSSL was a certification authority.
- a3n 13y ago
  > There's a ton of Windows software that uses OpenSSL And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch. OpenBSD can't do everything at once.
- teacup50 13y ago
  > There's a ton of Windows software that uses OpenSSL as their security library. Yes, and most of it is awful because they shouldn't. I hate manually configuring SSL certificates for OpenSSL-using Windows software. Write a socket transport portability layer. It's not that hard, and you almost certainly need one anyway.
orthecreedence 13y ago
Ehh, I maintain a few libs that rely on the OpenSSL Windows ports. I'm not too keen on writing a compatibility layer that says "if windows, use the MS version, else use libreSSL!" I'm fine with them not supporting MSVC in the build, but is it really that much harder to support something like MinGW/MSYS? No need for Cygwin. The whole point of OpenSSL was that it runs everywhere. If we're going to write a shiny new version, let's at least try to hit the major platforms.
- asddubs 13y ago
  you can write a layer that says "if windows, use openssl, else use libreSSL"
- Sanddancer 13y ago
  I imagine that's what the supported option is going to be. Given that the OpenSSH documentation explicitly lists Cygwin as the way to run it for windows, similar will probably happen for LibreSSL. The OpenBSD team has always had another team handle porting of their libraries, and they do a pretty good job of it.
- stuaxo 13y ago
  It's probably easier to cut the code right down to size now, then re-add compatibility once the base is solid. Given how knarly build systems can be, then only supporting modern versions of the same could help remove a lot of cruft.
- AlexMeesters 13y ago
  Its not a replacement for OpenSSL, OpenSSL will continue to exists as it is, but in a while when libressl is stable enough you can choose on or the other. Its just a fork.

deleted 13y ago

[deleted]

frik 13y ago

maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services http://en.wikipedia.org/wiki/Network_Security_Services

ProblemFactory 13y ago
Curiously, the Heartbleed bug was found by the Google engineer who is working on replacing NSS with OpenSSL in Chrome: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53... From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.
- rockdoe 13y ago
  The reasoning there is, certainly post-Heartbleed, very scary. Their conclusion boils down to that they want to use the system-provided OpenSSL on Android, rather than shipping NSS. This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone. Oh, I see the point already...
  - thefreeman 13y ago
    I mean couldn't you say the same thing if a vulnerability was found in NSS?
    - mercurial 13y ago
      No, because Android system updates are slow to come (or may never happen), while anything coming from the Google Play store (like Chrome) is timely.

ZoFreX 13y ago

I don't see why this product would have a different porting strategy to the usual way OpenBSD projects (such as OpenSSH) handle it - target OpenBSD exclusively in the core project, and support other platforms with ports. Presumably that's what they are going to do here.

acqq 13y ago
As far as I know OpenSSH doesn't work natively on Windows, only over Cygwin, that is, with the whole Linux environment by Red Hat.

masklinn 13y ago

FWIW the usual OpenBSD story is "get it working, reliable and simple, on (Open)BSD, then add porting shims" (they'll have to add shims for linux anyway if they start using strlcpy)

teacup50 13y ago

Most (all?) native Windows applications shouldn't use OpenSSL. They should use the operating system-shipped APIs, along with the OS-shipped certificate stores. That means SChannel and CryptoAPIs in native code.