On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote:
Is there a way to split libtls off libressl?
To revive this rather old thread, I just wanted to provide an update.
After some discussion with upstream portable openntpd, the libressl team
decided to go ahead and create a standalone
[Sorry if this is a dupe, my first send didn't seem to go through]
On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote:
Is there a way to split libtls off libressl?
To revive this rather old thread, I just wanted to provide an update.
After some discussion with upstream portable
On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote:
Is there a way to split libtls off libressl?
To revive this rather old thread, I just wanted to provide an update.
After some discussion with upstream portable openntpd, the libressl team
decided to go ahead and create a standalone
On 04/07/2015 12:06 AM, Paul B. Henson wrote:
From: hasufell
Sent: Sunday, April 05, 2015 4:34 AM
However, openntpd still compiles with openssl.
Well, the current stable openntpd in portage compiles with openssl but that's
not surprising as it is ancient and predates libressl :). The
El lun, 06-04-2015 a las 23:31 +0100, Diego Elio Pettenò escribió:
On 6 April 2015 at 23:07, Jason A. Donenfeld zx...@gentoo.org wrote:
Packages that will compile against either one get || (openssl libressl).
Packages that require a specific one will just have that one listed. Openssl
will
hasufell wrote:
This is something that has to be resolved upstream. If they don't
cooperate long-term, then their fork will just die out for sure
(and for good).
I agree that this is what one would intuitively expect, but what
actually happens is that whatever is perceived as most mainstream
On 6 April 2015 at 23:06, Paul B. Henson hen...@acm.org wrote:
What are the downsides of the approach pkgsrc is tentatively taking,
where there are no modifications to libressl but the libraries are
installed in an alternative location? Packages that require libressl can
just use the appropriate
From: hasufell
Sent: Sunday, April 05, 2015 4:34 AM
However, openntpd still compiles with openssl.
Well, the current stable openntpd in portage compiles with openssl but that's
not surprising as it is ancient and predates libressl :). The current unstable
openntpd actually has no ssl
Solution:
Packages that will compile against either one get || (openssl libressl).
Packages that require a specific one will just have that one listed.
Openssl will block Libressl and vice versa.
The result of this arrangement is that systems that require few packages
will probably be able to
On 7 April 2015 at 06:07, Jason A. Donenfeld zx...@gentoo.org wrote:
Solution:
Packages that will compile against either one get || (openssl libressl).
Packages that require a specific one will just have that one listed. Openssl
will block Libressl and vice versa.
This would result in a
On 6 April 2015 at 23:07, Jason A. Donenfeld zx...@gentoo.org wrote:
Packages that will compile against either one get || (openssl libressl).
Packages that require a specific one will just have that one listed. Openssl
will block Libressl and vice versa.
Doesn't work, you'd have to rebuild
On 04/05/2015 01:17 PM, Rich Freeman wrote:
If you're going to fork a library, and don't intend to keep the
packages API-compatible, then change the filenames. What is so hard
about this? LIbressl was even an outside fork, so it didn't come with
any of the baggage of we're the real libssl
On 5 April 2015 at 05:44, Paul B. Henson hen...@acm.org wrote:
I guess I'll just let this simmer for now and see how things develop. My
preference (I think, at least at the moment) would be for both
implementations to be able to coexist, like openssl and gnutls. It looks
like that's the way
On Sun, Apr 5, 2015 at 8:23 AM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
Since as you point out the two packages are vastly API compatible, it makes
them ABI incompatible and conflicting.
++
If they really want to improve the security of function calls that
they consider inherently
On 04/05/2015 06:44 AM, Paul B. Henson wrote:
On Fri, Apr 03, 2015 at 01:31:53PM +0200, hasufell wrote:
Not anymore. We will go for libressl USE flag for the same reason
there is a libav USE flag now (working subslots etc).
Um, ok. That still only allows one or the other to be installed
On Sun, Apr 5, 2015 at 12:34 AM, Paul B. Henson hen...@acm.org wrote:
They're pretty much decided on allowing both openssl and libressl to be
installed concurrently and for a given application to use one or the
other. The specific method for that packaging system is what they call a
prefix;
On Sun, Apr 5, 2015 at 2:35 PM, hasufell hasuf...@gentoo.org wrote:
You are ranting at the wrong place. If you want to make a difference,
take this to the openbsd mailing lists.
It seems unlikely that this would make much of a difference. I think
that allowing this package to create another
On 04/05/2015 03:25 PM, Rich Freeman wrote:
On Sun, Apr 5, 2015 at 8:23 AM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
Since as you point out the two packages are vastly API compatible, it makes
them ABI incompatible and conflicting.
++
If they really want to improve the security
On 5 April 2015 at 19:59, Rich Freeman ri...@gentoo.org wrote:
It seems unlikely that this would make much of a difference. I think
that allowing this package to create another ffmpeg vs libav mess is a
mistake.
To be honest, the upstream developers should be fairly in the known
regarding my
On 04/05/2015 08:59 PM, Rich Freeman wrote:
On Sun, Apr 5, 2015 at 2:35 PM, hasufell hasuf...@gentoo.org wrote:
You are ranting at the wrong place. If you want to make a difference,
take this to the openbsd mailing lists.
It seems unlikely that this would make much of a difference.
It
On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote:
Tricky thing here, because then you'd need to rename the libs. E.g.
libssl to liblibressl or something.
But then every program with a build environment to link to libssl would
first have to be patched to link to our specialized
On Fri, Apr 03, 2015 at 01:31:53PM +0200, hasufell wrote:
Not anymore. We will go for libressl USE flag for the same reason
there is a libav USE flag now (working subslots etc).
Um, ok. That still only allows one or the other to be installed though,
right? So if you want a package that only
On 04/03/2015 01:49 AM, Paul B. Henson wrote:
What is the current status/thoughts regarding libressl? Reviewing the
bug and some past threads, it sounds like the initial plan was to make
openssl a virtual and let either classic openssl or libressl fulfull it?
Not anymore. We will go for
On 04/03/2015 01:49 AM, Paul B. Henson wrote:
The specific reason for my current inquiry is that the latest openntpd
release includes the new support from openbsd for constraints, where
basically you can verify ntp time sources by checking their time
relative to a trusted TLS server (which
On Thu, 2 Apr 2015 16:49:20 -0700
Paul B. Henson hen...@acm.org wrote:
What is the current status/thoughts regarding libressl? Reviewing the
bug and some past threads, it sounds like the initial plan was to make
openssl a virtual and let either classic openssl or libressl fulfull
it? I'm not
What is the current status/thoughts regarding libressl? Reviewing the
bug and some past threads, it sounds like the initial plan was to make
openssl a virtual and let either classic openssl or libressl fulfull it?
I'm not sure if things have changed from that viewpoint, but it really
doesn't seem
26 matches
Mail list logo
