Re: openssl vs. libressl

On Friday November 13 2015 16:06:43 Jeremy Huddleston Sequoia wrote: >You mean it is up to the developer that is a client of that Qt API, not the >user. We should be protecting our users from developers that don't know >better. I think that's going beyond MacPorts goals. For once I agree with

Re: openssl vs. libressl

On 2015-11-13, at 1:33 AM, René J.V. Bertin wrote: > Telling it to "stop using them" is not unlike telling Apple they should stop > shipping anything but the latest version of a whole range of things shipped > with the OS (python comes to mind). There's a responsibility to ensure that > users w

Re: openssl vs. libressl

> On Nov 13, 2015, at 12:53, René J.V. Bertin wrote: > > On Friday November 13 2015 11:30:59 Jeremy Huddleston Sequoia wrote: > >> I don't understand what you mean here. These methods *force* the use of >> SSLv2 even if secure alternatives are available: >> >> qt.network.ssl: QSslSocket: can

Re: openssl vs. libressl

On Friday November 13 2015 11:30:59 Jeremy Huddleston Sequoia wrote: > I don't understand what you mean here. These methods *force* the use of > SSLv2 even if secure alternatives are available: > > qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method > qt.network.ssl: QSslSocket: cann

Re: openssl vs. libressl

> On Nov 13, 2015, at 10:09, René J.V. Bertin wrote: > > On Friday November 13 2015 09:20:11 Jeremy Huddleston Sequoia wrote: >> They *force* the use of the insecure SSLv2 transport (which was broken years >> ago and replace with SSLv3, which itself was broken). > > Where, how? I don't unders

Re: openssl vs. libressl

On Friday November 13 2015 09:20:11 Jeremy Huddleston Sequoia wrote: > They *force* the use of the insecure SSLv2 transport (which was broken years > ago and replace with SSLv3, which itself was broken). Where, how? > Qt probably doesn't use SSLv2 itself or else that warning would have had a >

Re: openssl vs. libressl

> On Nov 13, 2015, at 01:33, René J.V. Bertin wrote: > > On Thursday November 12 2015 15:56:58 Jeremy Huddleston Sequoia wrote: > > If LibreSSL should become the default, the best compromise in this particular > case might yet be to provide a variant that allows Qt to build with the > shipped

Re: openssl vs. libressl

On Friday November 13 2015 12:52:07 Dominik Reichardt wrote: > Yes! You must have missed Ryan's post in this thread when he remarked just > that (same license, same restrictions), one or two days ago. Guess so. This only strengthens my conviction that if anything and for the time being, it's t

Re: openssl vs. libressl

> Am 13.11.2015 um 12:21 schrieb René J.V. Bertin : > > You're right that it has the same license. I was under the impression that it > didn't, but should have checked. > > If it has the same license, there shouldn't be a difference in binary package > restrictions, right? Yes! You must have

Re: openssl vs. libressl

You're right that it has the same license. I was under the impression that it didn't, but should have checked. If it has the same license, there shouldn't be a difference in binary package restrictions, right? R. ___ macports-users mailing list macpor

Re: openssl vs. libressl

> On 13.11.2015, at 11:16, René J.V. Bertin wrote: > > On Friday November 13 2015 10:45:32 Dominik Reichardt wrote: > >> from www.libressl.org: >> >> "LibreSSL is a version of the TLS/crypto stack forked from OpenSSL in 2014, >> with goals of modernizing the codebase, improving security, and

Re: openssl vs. libressl

On Friday November 13 2015 10:45:32 Dominik Reichardt wrote: > from www.libressl.org: > > "LibreSSL is a version of the TLS/crypto stack forked from OpenSSL in 2014, > with goals of modernizing the codebase, improving security, and applying best > practice development processes.” > > so, no re

Re: openssl vs. libressl

> On 13.11.2015, at 10:33, René J.V. Bertin wrote: > > I don't really want into this kind of discussion, but > >> Libressl doesn't "emulate" OpenSSL. It is a derivative of OpenSSL with a >> focus on better architecture and security. > > AFAIK it's a rewrite (has to be, to avoid licensing/c

Re: openssl vs. libressl

On Thursday November 12 2015 15:56:58 Jeremy Huddleston Sequoia wrote: If LibreSSL should become the default, the best compromise in this particular case might yet be to provide a variant that allows Qt to build with the shipped OpenSSL version rather than against the "system" (MacPorts) version

Re: openssl vs. libressl

> On Nov 12, 2015, at 12:28, René J.V. Bertin wrote: > > On Thursday November 12 2015 08:45:19 Jeremy Huddleston Sequoia wrote: >> See this ticket for details about Qt5 + Libressl: >> >> https://github.com/libressl-portable/openbsd/issues/33 > > And an official statement from a highly visible

Re: openssl vs. libressl

On Thursday November 12 2015 08:45:19 Jeremy Huddleston Sequoia wrote: > See this ticket for details about Qt5 + Libressl: > > https://github.com/libressl-portable/openbsd/issues/33 And an official statement from a highly visible Qt dev: "Our current position is "our code is written for OpenSSL"

Re: openssl vs. libressl

On Thursday November 12 2015 08:45:19 Jeremy Huddleston Sequoia wrote: > https://github.com/libressl-portable/openbsd/issues/33 Easy fix, but that still leaves me with 3 runtime errors: qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback qt.network.ssl: QSslSocket: cannot reso

Re: openssl vs. libressl

> On Nov 12, 2015, at 07:26, René J.V. Bertin wrote: > > On Thursday November 12 2015 04:42:25 Ryan Schmidt wrote: > >> Just tested it. rev-upgrade works fine. > > And I just tested building Qt 5 with port:libressl active instead of > port:openssl, and got this error: > > /opt/local/var/macp

Re: openssl vs. libressl

On Thursday November 12 2015 04:42:25 Ryan Schmidt wrote: >Just tested it. rev-upgrade works fine. And I just tested building Qt 5 with port:libressl active instead of port:openssl, and got this error: /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-

Re: openssl vs. libressl

On Nov 10, 2015, at 11:59 AM, Jeremy Huddleston Sequoia wrote: > On Nov 10, 2015, at 00:17, Ryan Schmidt wrote: > >> That's not the same situation. If a user had been using glib2 and then later >> needed to switch to glib2-devel for some reason, everything should still >> work. All the ports t

Re: openssl vs. libressl

On Nov 11, 2015, at 11:00 AM, wood...@gmail.com wrote: > On Nov 11, 2015, at 10:54 AM, Brandon Allbery wrote: >> >> On Wed, Nov 11, 2015 at 11:52 AM, wrote: >> I don’t believe a “better license” should be the dictating factor, I believe >> what should dictate what is included is what has bette

Re: openssl vs. libressl

Yes in this case, its a convenance, what TECHNICAL benefits are there to changing ? > On Nov 11, 2015, at 11:05 AM, Brandon Allbery wrote: > > On Wed, Nov 11, 2015 at 12:05 PM, > wrote: > But in this case, I don’t see one, openssl has been fine being distributed > th

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 12:05 PM, wrote: > But in this case, I don’t see one, openssl has been fine being distributed > the way it is, its just that some people want a new-shiny here. So binary archives are a new-shiny with no practical significance. Got it. -- brandon s allbery kf8nh

Re: openssl vs. libressl

But in this case, I don’t see one, openssl has been fine being distributed the way it is, its just that some people want a new-shiny here. > On Nov 11, 2015, at 11:00 AM, Brandon Allbery wrote: > > On Wed, Nov 11, 2015 at 12:00 PM, > wrote: > I agree, but “better lic

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 12:00 PM, wrote: > I agree, but “better license” has nothing to do with that, does it ? It is the license that blocks binary distribution, with specific exemptions. Oddly enough, licenses are not merely political noise; they actually have practical ramifications that nee

Re: openssl vs. libressl

I agree, but “better license” has nothing to do with that, does it ? My point is we should look at the best technical solution, and THAT should be the only factor. Anything else is ancillary. > On Nov 11, 2015, at 10:54 AM, Brandon Allbery wrote: > > On Wed, Nov 11, 2015 at 11:52 AM,

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 11:57 AM, René J.V. wrote: > On Wednesday November 11 2015 08:14:59 Bradley Giesbrecht wrote: > > > On Nov 11, 2015, at 4:15 AM, René J.V. Bertin > wrote: > > > I believe most openssl dependent ports are not binary distributable due > to the openssl license. > > There is

Re: openssl vs. libressl

On Wednesday November 11 2015 08:14:59 Bradley Giesbrecht wrote: > > On Nov 11, 2015, at 4:15 AM, René J.V. Bertin wrote: > I believe most openssl dependent ports are not binary distributable due to > the openssl license. There is indeed some kind of restriction, but apparently not as severe as

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 11:52 AM, wrote: > I don’t believe a “better license” should be the dictating factor, I > believe what should dictate what is included is what has better > functionality. This is politics, and TBH is not a technical reason for > inclusion or exclusion. TBH, I believe the o

Re: openssl vs. libressl

I don’t believe a “better license” should be the dictating factor, I believe what should dictate what is included is what has better functionality. This is politics, and TBH is not a technical reason for inclusion or exclusion. TBH, I believe the only dictating factor should be technical, what d

Re: openssl vs. libressl

> On Nov 11, 2015, at 4:15 AM, René J.V. Bertin wrote: > > - when a user made the opposite choice (say libressl instead of openssl), > doing `port install curl` (for example) will translate to `port install curl > +libressl` which means s/he won't benefit of binary packages for curl when > cur

Re: openssl vs. libressl

On Wednesday November 11 2015 06:27:29 Ryan Schmidt wrote: >Providing choice is not a primary goal of MacPorts. Providing software that >works is. >It seems libressl is the default ssl library in OpenBSD since one year. I think that's hardly long enough in an OS that's hardly a mainstream OS use

Re: openssl vs. libressl

On Nov 11, 2015, at 6:15 AM, René J.V. Bertin wrote: > On Wednesday November 11 2015 05:27:49 Ryan Schmidt wrote: > >> If we don't want to switch to libressl as a default, then I don't know why >> libressl is in MacPorts. > > To provide choice. Providing choice is not a primary goal of MacPor

Re: openssl vs. libressl

On Wednesday November 11 2015 05:27:49 Ryan Schmidt wrote: >If we don't want to switch to libressl as a default, then I don't know why >libressl is in MacPorts. To provide choice. Apart from the fact that the ssl ports can't be swapped without rebuilding all dependents, the only thing that does

Re: openssl vs. libressl

On Nov 10, 2015, at 6:11 AM, René J.V. Bertin wrote: > On Tuesday November 10 2015 04:46:50 Ryan Schmidt wrote: > >>> No, but if the ABIs are indeed not compatible there is no other solution, >>> is there? >> >> What has currently be done with libressl in MacPorts is a bug, not a >> solution.

Re: openssl vs. libressl

On Nov 10, 2015, at 11:59 AM, Jeremy Huddleston Sequoia wrote: > > On Nov 10, 2015, at 00:17, Ryan Schmidt wrote: >> >> On Nov 9, 2015, at 6:10 PM, Jeremy Huddleston Sequoia wrote: >> >>> On Nov 9, 2015, at 13:10, René J.V. Bertin wrote: >>> On Monday November 09 2015 15:05:26 Ryan Schmidt

Re: openssl vs. libressl

On Tuesday November 10 2015 18:55:51 Jeremy Huddleston Sequoia wrote: >Actually, this won't solve the problem. The entire problem here is that >OpenSSL and Libressl are note compatible. Projects need to be recompiled to >use one or the other. The only way to do this in a way that doesn't rely

Re: openssl vs. libressl

> On Nov 10, 2015, at 06:21, Daniel J. Luke wrote: > > On Nov 10, 2015, at 5:12 AM, René J.V. Bertin wrote: >> Indeed. Still, the mod Jeremy introduced is the best/only way I know to >> allow choice that doesn't involve introducing an SSL PortGroup that provides >> +openssl and +libressl vari

Re: openssl vs. libressl

On Nov 10, 2015, at 10:44 AM, Rainer Müller wrote: > This would basically cause the same problems as with the current path: > dependency. you’re right, of course. > It is still required to rev-upgrade all ports after switching the > variant. All binary archives built with the default option woul

Re: openssl vs. libressl

> On Nov 10, 2015, at 00:17, Ryan Schmidt wrote: > > > On Nov 9, 2015, at 6:10 PM, Jeremy Huddleston Sequoia wrote: > >> On Nov 9, 2015, at 13:10, René J.V. Bertin wrote: >> >>> On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: >>> In r139229 Jeremy made libressl a drop-in replace

Re: openssl vs. libressl

On 2015-11-10 15:21, Daniel J. Luke wrote: > We could have a port “mp-ssl-lib” that defaults to depending on one > of the ssl libs (say openssl). It could also be installed as > mp-ssl-lib +libressl which would modify it’s dependencies and install > libressl and not openssl. > > Other ports would

Re: openssl vs. libressl

On Tuesday November 10 2015 09:27:27 Brandon Allbery wrote: > As quoted from Rainer Müller: > > See both the official statement and a blog post from a Gentoo developer > > explaining the problem: Right ... exactly the same posts I found myself. I was looking for a link to gentoo.org or with

Re: openssl vs. libressl

On Tuesday November 10 2015 09:21:19 Daniel J. Luke wrote: >Other ports would all depend on ‘mp-ssl-lib’ and not directly only openssl or >libressl. > >It’s not a perfect solution, but may be nicer than adding +openssl/+libressl >to every possible port. Hmmm, I should have thought of that. Wait

Re: openssl vs. libressl

On Tue, Nov 10, 2015 at 7:11 AM, René J.V. wrote: > > See the Gentoo dev link given previously > Care to repeat it, I cannot seem to find it in this thread? As quoted from Rainer Müller: See both the official statement and a blog post from a Gentoo developer > explaining the problem: > > https

Re: openssl vs. libressl

On Nov 10, 2015, at 5:12 AM, René J.V. Bertin wrote: > Indeed. Still, the mod Jeremy introduced is the best/only way I know to allow > choice that doesn't involve introducing an SSL PortGroup that provides > +openssl and +libressl variants. One other way to handle it would be how we tried to ha

Re: openssl vs. libressl

On Tuesday November 10 2015 04:46:50 Ryan Schmidt wrote: > > No, but if the ABIs are indeed not compatible there is no other solution, > > is there? > > What has currently be done with libressl in MacPorts is a bug, not a solution. ?? Why? It leaves the educated user with a choice regardless of

Re: openssl vs. libressl

On Nov 10, 2015, at 4:12 AM, René J.V. Bertin wrote: > On Tuesday November 10 2015 02:17:06 Ryan Schmidt wrote: > >>> This is the same solution we've used elsewhere in MacPorts (eg: >>> ffmpeg-devel). >> >> That's not the same situation. If a user had been using glib2 and then later >> needed

Re: openssl vs. libressl

On Tuesday November 10 2015 02:17:06 Ryan Schmidt wrote: >> This is the same solution we've used elsewhere in MacPorts (eg: >> ffmpeg-devel). > >That's not the same situation. If a user had been using glib2 and then later >needed to switch to glib2-devel for some reason, everything should still

Re: openssl vs. libressl

On Nov 9, 2015, at 6:10 PM, Jeremy Huddleston Sequoia wrote: > On Nov 9, 2015, at 13:10, René J.V. Bertin wrote: > >> On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: >> >>> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a >>> rebuild is needed to make things work

Re: openssl vs. libressl

> On Nov 9, 2015, at 17:31, René J.V. Bertin wrote: > > On Monday November 09 2015 16:11:54 Jeremy Huddleston Sequoia wrote: > > hi, > >>> Now what if you do >>> >>> %> ln -s libssl.35.dylib libssl.1.0.0.dylib ? >>> >>> (assuming that libressl indeed installs libssl.35.dylib) >>> >>> If tha

Re: openssl vs. libressl

On Mon, Nov 9, 2015 at 8:31 PM, René J.V. wrote: > First quick tests (downloading a couple of release tarballs from github, > with /opt/local/bin/curl) suggests that it works. Which doesn't really > surprise me too much: both libraries are written in C. As long as dependent > software sticks to p

Re: openssl vs. libressl

On Monday November 09 2015 16:11:54 Jeremy Huddleston Sequoia wrote: hi, > > Now what if you do > > > > %> ln -s libssl.35.dylib libssl.1.0.0.dylib ? > > > > (assuming that libressl indeed installs libssl.35.dylib) > > > > If that works, it can be handled with a very simple post-destroot addit

Re: openssl vs. libressl

> On Nov 9, 2015, at 13:40, René J.V. Bertin wrote: > > On Monday November 09 2015 15:27:54 Ryan Schmidt wrote: > >>> Interesting. I think it was FreeBSD that tried to do that (both API and >>> ABI) and failed at both, and said rebuild stuff for one or the other. >>> Apparently they were the

Re: openssl vs. libressl

> On Nov 9, 2015, at 13:10, René J.V. Bertin wrote: > > On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: > >> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a >> rebuild is needed to make things work, then this > > Yes, but at least on Linux libressl installs lib

Re: openssl vs. libressl

On 2015-11-09 22:40, René J.V. Bertin wrote: > Now what if you do > > %> ln -s libssl.35.dylib libssl.1.0.0.dylib ? > > (assuming that libressl indeed installs libssl.35.dylib) > > If that works, it can be handled with a very simple post-destroot addition in > both ports . You should not do th

Re: openssl vs. libressl

On Monday November 09 2015 15:27:54 Ryan Schmidt wrote: > > Interesting. I think it was FreeBSD that tried to do that (both API and > > ABI) and failed at both, and said rebuild stuff for one or the other. > > Apparently they were the ones who made the mistake, and it actually works > > if done

Re: openssl vs. libressl

On Nov 9, 2015, at 3:12 PM, Brandon Allbery wrote: > On Mon, Nov 9, 2015 at 4:05 PM, Ryan Schmidt wrote: >> In r139229 Jeremy made libressl a drop-in replacement for openssl. > > Interesting. I think it was FreeBSD that tried to do that (both API and ABI) > and failed at both, and said rebuild s

Re: openssl vs. libressl

On Mon, Nov 9, 2015 at 4:05 PM, Ryan Schmidt wrote: > In r139229 Jeremy made libressl a drop-in replacement for openssl. Interesting. I think it was FreeBSD that tried to do that (both API and ABI) and failed at both, and said rebuild stuff for one or the other. Apparently they were the ones wh

Re: openssl vs. libressl

On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: > In r139229 Jeremy made libressl a drop-in replacement for openssl. If a > rebuild is needed to make things work, then this Yes, but at least on Linux libressl installs libraries with different numbers (libssl.so.35 vs libssl.so.1.0.0). I

Re: openssl vs. libressl

On Nov 9, 2015, at 2:43 PM, Brandon Allbery wrote: > On Mon, Nov 9, 2015 at 3:39 PM, René J.V. wrote: >> I understand that libressl aims to be API-compatible with openssl so that it >> can act as a drop-in replacement. How far does that go, far enough that one >> can symlink the libssl and libcr

Re: openssl vs. libressl

On Mon, Nov 9, 2015 at 3:39 PM, René J.V. wrote: > I understand that libressl aims to be API-compatible with openssl so that > it can act as a drop-in replacement. How far does that go, far enough that > one can symlink the libssl and libcrypto runtimes from the one port to the > shared libraries