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 lib
[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 openntp
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 lib
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 :)
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
El lun, 06-04-2015 a las 23:31 +0100, Diego Elio Pettenò escribió:
> On 6 April 2015 at 23:07, Jason A. Donenfeld 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 Li
On 7 April 2015 at 06:07, Jason A. Donenfeld 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 similar mess a
On 6 April 2015 at 23:06, Paul B. Henson 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 linker options
On 6 April 2015 at 23:07, Jason A. Donenfeld 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 *all* the packa
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 h
> 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 de
On 04/05/2015 08:59 PM, Rich Freeman wrote:
> On Sun, Apr 5, 2015 at 2:35 PM, hasufell 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 doesn't make
On 5 April 2015 at 19:59, Rich Freeman 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 opinion expres
On Sun, Apr 5, 2015 at 2:35 PM, hasufell 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 ffmpeg vs libav
On 04/05/2015 03:25 PM, Rich Freeman wrote:
> On Sun, Apr 5, 2015 at 8:23 AM, Diego Elio Pettenò
> 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
On Sun, Apr 5, 2015 at 8:23 AM, Diego Elio Pettenò
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 secure, they should ju
On 5 April 2015 at 05:44, Paul B. Henson 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 it's heading
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 libs
On Sun, Apr 5, 2015 at 12:34 AM, Paul B. Henson 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; basically i
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 i
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 on
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 li
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 (w
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 "lib
On Thu, 2 Apr 2015 16:49:20 -0700
"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? I'm not sure if t
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 t
26 matches
Mail list logo
