Oh, and note that OpenSSH Portable uses RAND_bytes from libssl to seed
its arc4random implementation.
So AFAICT if you were to link OpenSSH Portable against LibreSSL
Portable, it would get really crazy:
/dev/urandom or sysctl or scary fallback ->
LibreSSL Portable getentropy ->
LibreSSL Portable
(This may seem a little off-topic for the ITP but please bear with me...)
On 16/07/14 21:13, Guillem Jover wrote:
> kFreeBSD does have a supported sysctl for this: CTL_KERN KERN_ARND.
> (As does NetBSD which has two, KERN_URND and KERN_ARND.)
Actually yes, we would certainly want to use that. Bu
Hi!
On Wed, 2014-07-16 at 19:54:38 +0100, Steven Chamberlain wrote:
> The other major concern was about scary entropy-gathering code,
> implemented in LibreSSL Portable for Linux as a last resort for when
> /dev/urandom can't be read. I agree that it's too risky, or: too
> difficult to prove saf
On 16/07/14 03:06, Paul Tagliamonte wrote:
> I didn't see this yet in the thread, so:
> https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux
What's most interesting is that someone spent such effort to look for
this; that there are so many eyes now on both the original OpenSSL and
th
On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Toni Mueller
>
> * Package name: libressl
> Version : 2.0.0
> Upstream Author : The OpenBSD project, the OpenSSL project et al.
> * URL : http://www.libressl.org
On 14/07/14 21:08, Toni Mueller wrote:
>> > You forget one of the big problems with OpenSSL that LibreSSL doesn't
>> > fix: the license.
> Granted. Due to the amount of inherited code, it can't. We'll see how
> things evolve as the amount of inherited code will dwindle.
So, merely as a result of t
Hi Jeroen,
On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
> At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote:
> > Ok, but for whatever reason, they have an imho not as shiny track
> > record, as has OpenBSD. Which is no wonder, given all the revelations we
> > have had rece
Hi Thomas,
On Sun, Jul 13, 2014 at 11:52:24AM +0800, Thomas Goirand wrote:
> On 07/12/2014 08:46 PM, Toni Mueller wrote:
> > As libressl is currently under
> > heavy development, it is imho not to be expected to have that stable ABI
> > you are asking for.
>
> Well, I don't agree with this view.
On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > > I plan to try and get them to use symbol versioning, at least on
> > > those platforms that support it. This will probably be jus
On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > I plan to try and get them to use symbol versioning, at least on
> > those platforms that support it. This will probably be just like
>
> Thank you.
>
> > the patch currentl
On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> I plan to try and get them to use symbol versioning, at least on
> those platforms that support it. This will probably be just like
Thank you.
> the patch currently in Debian. I don't plan to add multiple
> versions of a symbol to try and keep the same
> I would like to make it co-installable with OpenSSL, but in general,
> this should be a drop-in replacement until APIs really diverge in a
> visible way. Yes, it would provide 'openssl', but I intend to place them
> into a different directory, so you might have to use LD_PATH to get
> them.
That
On Sun, Jul 13, 2014 at 08:36:30PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Mike Hommey:
> > Well, it kind of is. Because those versioned symbols in openssl come
> > from a debian patch, afaict. So while debian may be fine (as long as all
> > build-rdeps have been rebuilt since openssl got those v
On 12/07/14 12:53, Toni Mueller wrote:
> my intention is to package this stuff so one can have both openssl and
> libressl installed in parallel. libressl currently has libraries with
> these sonames:
>
> libssl.so.26
> libcrypto.so.29
If the ABI is already different, there's no need for the libr
On 12/07/14 02:09, Steven Chamberlain wrote:
> [...] these warnings would be treated as errors:
>
>> > In file included from md5/md5_locl.h:98:0,
>> > from md5/md5_dgst.c:60:
>> > md5/md5_dgst.c: In function 'md5_block_data_order':
>> > ./md32_common.h:237:66: warning: right-hand
On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> I am, frankly, not at all concerned with binaries not compiled on Debian
> at this point. Data point: Fedora uses a different symbol versioning
> scheme for openssl, so openssl-linked binaries from there won't run on
> Debian anyway.
>
> It's far more
Hi,
Mike Hommey:
> Well, it kind of is. Because those versioned symbols in openssl come
> from a debian patch, afaict. So while debian may be fine (as long as all
> build-rdeps have been rebuilt since openssl got those versioned
> symbols), other distros aren't covered, as well as binaries not
> c
On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> for that (i.e. make sure that _everything_ in libressl is only exported
> with properly versioned symbols), again IMHO the time and effort required
PLEASE PLEASE PLEASE PLEASE PLEASE take this to the portable libressl
upstream *and make it true* for
On 07/13/2014 09:48 PM, Mike Hommey wrote:
> On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
>> Hi,
>>
>> Bernhard R. Link:
>>> * Mike Hommey [140713 12:55]:
Contrary to what you seem to believe, this only really works if *both*
libraries have versioned symbols. Otherwi
On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Bernhard R. Link:
> > * Mike Hommey [140713 12:55]:
> > > Contrary to what you seem to believe, this only really works if *both*
> > > libraries have versioned symbols. Otherwise, you can end up with
> > > libraries linke
Hi,
Bernhard R. Link:
> * Mike Hommey [140713 12:55]:
> > Contrary to what you seem to believe, this only really works if *both*
> > libraries have versioned symbols. Otherwise, you can end up with
> > libraries linked against the unversioned one using symbols from the
> > versioned one at run ti
* Mike Hommey [140713 12:55]:
> > … while IMHO it's possible to safely mix openssl and libressl if we prepare
> > for that (i.e. make sure that _everything_ in libressl is only exported
> > with properly versioned symbols)
>
> Contrary to what you seem to believe, this only really works if *both
On Sun, Jul 13, 2014 at 08:17:51AM +0200, Matthias Urlichs wrote:
> Hi,
>
> Thomas Goirand:
> > Well, I don't agree with this view. If LibreSSL pretends to be a
> > replacement for OpenSSL, then they should care about being ABI
> > compatible, so we can easily switch from one implementation to the
On 07/13/2014 02:17 PM, Matthias Urlichs wrote:
> Does gnutls have an openssl shim which actually works as a generic
> replacement? I dimly recall a couple of not-so-nice incompatibilities
As much as I understand, it's a complete alternative with a different
API, I don't think there's a compatibil
At Sat, 12 Jul 2014 14:46:45 +0200,
Toni Mueller wrote:
> On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
>
> > I'm not really sure what you mean by this. I'm pretty sure the
> > openssl development team has a pretty good understanding of
> > security and I don't see anybody adding a
Hi,
Thomas Goirand:
> Well, I don't agree with this view. If LibreSSL pretends to be a
> replacement for OpenSSL, then they should care about being ABI
> compatible, so we can easily switch from one implementation to the
> other.
That depends. If the ABI in question includes calls or constants wh
On 07/12/2014 08:46 PM, Toni Mueller wrote:
> As libressl is currently under
> heavy development, it is imho not to be expected to have that stable ABI
> you are asking for.
Well, I don't agree with this view. If LibreSSL pretends to be a
replacement for OpenSSL, then they should care about being
On Jul 12, Toni Mueller wrote:
> On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
> > On Jul 12, Toni Mueller wrote:
> > > * Package name: libressl
> > I am highly doubtful at best.
>
> in which respect, and why?
I think some people are jumping ahead to "oh no! we're replacing
Hi,
On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
> On Jul 12, Toni Mueller wrote:
> > * Package name: libressl
> I am highly doubtful at best.
in which respect, and why?
> What are your plans exactly?
My plan is to first build the package(s) and upload to experimental, so
Hi Kurt,
[ I have trimmed the Cc list - we are all on devel@, anyway, right? ]
On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
> On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
> > On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote:
> > > What are you doing w
On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
> On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
> > There are a number of reasons for that, but one has been that I was
> > unhappy about the perceived 'closedness' of the project
>
> I was never very happy with it either
On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
>
> Hi Kurt,
>
> On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote:
> > What are you doing with the binaries, include files, man pages,
> > ...? Will they conflict with the ones from openssl?
>
> my intention is to package
Hi Kurt,
On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote:
> What are you doing with the binaries, include files, man pages,
> ...? Will they conflict with the ones from openssl?
my intention is to package this stuff so one can have both openssl and
libressl installed in parallel. li
On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Toni Mueller
>
> * Package name: libressl
> Version : 2.0.0
> Upstream Author : The OpenBSD project, the OpenSSL project et al.
> * URL : http://www.libressl.org
On Jul 12, Toni Mueller wrote:
> * Package name: libressl
I am highly doubtful at best.
What are your plans exactly?
Would it have the same SONAME of openssl and conflict+provide it?
Would it be a totally different library which packages would
build-depend on?
Which packages are supposed to
This is good to see already :)
I expect it builds fine on GNU/Linux, with GCC and Clang, unless
hardening options are used, then these warnings would be treated as errors:
> In file included from md5/md5_locl.h:98:0,
> from md5/md5_dgst.c:60:
> md5/md5_dgst.c: In function 'md5_bl
Package: wnpp
Severity: wishlist
Owner: Toni Mueller
* Package name: libressl
Version : 2.0.0
Upstream Author : The OpenBSD project, the OpenSSL project et al.
* URL : http://www.libressl.org/
* License : BSD, OpenSSL, SSLeay, Public Domain.
Programming Lang:
37 matches
Mail list logo
