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
the
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 safe
(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. But
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
On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
Package: wnpp
Severity: wishlist
Owner: Toni Mueller t...@debian.org
* Package name: libressl
Version : 2.0.0
Upstream Author : The OpenBSD project, the OpenSSL project et al.
* URL :
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 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
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 currently in
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 just like
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. If
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 recently,
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 the
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 which
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
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
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
* Mike Hommey m...@glandium.org [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
Hi,
Bernhard R. Link:
* Mike Hommey m...@glandium.org [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
On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
Hi,
Bernhard R. Link:
* Mike Hommey m...@glandium.org [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
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 m...@glandium.org [140713 12:55]:
Contrary to what you seem to believe, this only really works if *both*
libraries have versioned symbols.
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
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
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
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 operand of
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 library
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 versioned
On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
Package: wnpp
Severity: wishlist
Owner: Toni Mueller t...@debian.org
* Package name: libressl
Version : 2.0.0
Upstream Author : The OpenBSD project, the OpenSSL project et al.
* URL :
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.
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 this
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. But
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 with
Hi,
On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
On Jul 12, Toni Mueller supp...@oeko.net 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
On Jul 12, Toni Mueller supp...@oeko.net wrote:
On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote:
On Jul 12, Toni Mueller supp...@oeko.net wrote:
* Package name: libressl
I am highly doubtful at best.
in which respect, and why?
I think some people are jumping ahead to
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
Package: wnpp
Severity: wishlist
Owner: Toni Mueller t...@debian.org
* 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.
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
On Jul 12, Toni Mueller supp...@oeko.net 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
37 matches
Mail list logo
