On Sat, Jul 19, 2014 at 02:27:56AM +0200, Kurt Roeckx wrote:
Of course, the syscall numbers and interface details are not set into
stone until this gets merged into mainline.
It doesn't say much about sizes you can request and what the
result of that would be. The getentropy() replacement
On Sat, Jul 19, 2014 at 05:41:41AM -0400, Theodore Ts'o wrote:
I take a somewhat different philosophical position, which is that it's
impossible to make something moron-proof, because morons are
incredibly ingenious :-), and there are legitimate times when you
might indeed want more than 256
Hi,
Quoting Russ Allbery (2014-07-16 22:17:23)
Ben Hutchings b...@decadent.org.uk writes:
On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
It would be nice to have a reliable kernel interface for getting
randomness rather than relying on proper chroot configuration.
There is such
On Fri, Jul 18, 2014 at 02:03:06PM +0200, Johannes Schauer wrote:
maybe this will help in the future:
http://lists.openwall.net/linux-kernel/2014/07/17/235
Latest version of the patch:
http://lists.openwall.net/linux-kernel/2014/07/18/329
Of course, the syscall numbers and
On Fri, Jul 18, 2014 at 08:54:14AM -0400, Theodore Ts'o wrote:
On Fri, Jul 18, 2014 at 02:03:06PM +0200, Johannes Schauer wrote:
maybe this will help in the future:
http://lists.openwall.net/linux-kernel/2014/07/17/235
Latest version of the patch:
Russ Allbery wrote:
Steven Chamberlain ste...@pyro.eu.org writes:
* first-forked process does not use the PRNG yet, but forks again
Actually, it does: it calls RAND_poll(), which libressl made
into a nop.
control. There has been some talk of implementing PID randomization
precisely to make
Ben Hutchings wrote:
Since Linux 2.6.29, you get 128 random bits at each execve(), which you
can access like this:
getauxval() is only in (e)glibc, not in dietlibc or klibc, though.
Also, glibc already uses all 128 bits in some other place.
bye,
//mirabilos
--
To UNSUBSCRIBE, email to
On Thu, 2014-07-17 at 13:11 +, Thorsten Glaser wrote:
Ben Hutchings wrote:
Since Linux 2.6.29, you get 128 random bits at each execve(), which you
can access like this:
getauxval() is only in (e)glibc, not in dietlibc or klibc, though.
True, and it was only added in glibc 2.16. So
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
Steven Chamberlain ste...@pyro.eu.org writes:
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 new LibreSSL code. Both projects ought to benefit from this.
Yes.
This was a real, but totally
On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
Steven Chamberlain ste...@pyro.eu.org writes:
[...]
It seems extreme, but the point is that something must be wrong on the
system if we get to the fallback code - /dev/urandom missing from a
chroot, or fd's exhausted, and the kernel not
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
Ben Hutchings b...@decadent.org.uk writes:
On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
It would be nice to have a reliable kernel interface for getting
randomness rather than relying on proper chroot configuration.
There is such an interface. It happens to be a char device.
(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
Hi,
Steven Chamberlain ste...@pyro.eu.org writes:
And since BSD and GNU software are unable
to link against each other, [...]
Oops, I should have said there that BSD software *if now linking
against LibreSSL* couldn't link with GNU software any more.
On Mon, 14 Jul 2014 13:32:40 -0700, Russ
On Wed, 2014-07-16 at 13:17 -0700, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk writes:
On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
It would be nice to have a reliable kernel interface for getting
randomness rather than relying on proper chroot configuration.
On Tue, Jul 15, 2014 at 07:43:27AM +0200, Andreas Metzler wrote:
That turns smaller adjustments in applications into
developing entirely different interfaces for each application, while
GnuTLS itself still lacks a lot of features.
Do you have any reference for this? I have not followed
Hi, all,
On Sun, Jul 13, 2014 at 2:15 AM, Russ Allbery r...@debian.org wrote:
Kurt Roeckx k...@roeckx.be writes:
On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote:
my intention is to package this stuff so one can have both openssl and
libressl installed in parallel. libressl
On Jul 15, Ryo IGARASHI rigar...@gmail.com wrote:
If libressl is supposed to be the binary compatible replacement for openssl,
the experience of these BLAS libraries might be helpful.
It is not.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Mon, Jul 14, 2014 at 01:32:40PM -0700, Russ Allbery wrote:
In the world in which BSD software is linked with LibreSSL and the license
exceptions have not been changed to allow OpenSSL-derived software, now
(due to the way that Debian applies this rule transitively) GPL software
can't link
On Mon, 2014-07-14 at 14:09:55 -0300, Henrique de Moraes Holschuh wrote:
On Mon, 14 Jul 2014, Kurt Roeckx wrote:
This will all probably take some time.
As long as you don't mean to wait to deploy symbol versioning. It becomes
*really* painful after a while. Changes to symbol versioning
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 :
Jeroen Dekkers wrote:
You forget one of the big problems with OpenSSL that LibreSSL doesn't
fix: the license. It actually makes the mess even bigger, given that
some of the GPL exceptions only talk about the OpenSSL library and
don't exempt OpenSSL-derived code. So even if LibreSSL is a
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
z...@debian.org wrote:
On 07/13/2014 09:48 PM, Mike Hommey wrote:
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
On 07/14/2014 10:01 PM, Steve McIntyre wrote:
z...@debian.org wrote:
On 07/13/2014 09:48 PM, Mike Hommey wrote:
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
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 Mon, Jul 14, 2014 at 10:08:01PM +0200, Toni Mueller wrote:
On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
how isn't OpenSSL part of the OpenBSD track record?
it is in the way that they include it, and
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
Steven Chamberlain ste...@pyro.eu.org writes:
So, merely as a result of the licensing, we could have a fascinating
situation whereby:
* BSD-licensed software contemplates switching from OpenSSL to LibreSSL
* GNU-licensed software keeps using OpenSSL with license exception, or
maybe someday
Toni Mueller t...@debian.org wrote:
[...]
That turns smaller adjustments in applications into
developing entirely different interfaces for each application, while
GnuTLS itself still lacks a lot of features.
[...]
Do you have any reference for this? I have not followed this closely
but
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
❦ 13 juillet 2014 11:52 +0800, Thomas Goirand z...@debian.org :
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
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
Matthias Urlichs matth...@urlichs.de wrote:
Thomas Goirand:
[...]
As Kurt wrote, GNUTLS becomes a better alternative then.
Does gnutls have an openssl shim which actually works as a generic
replacement? I dimly recall a couple of not-so-nice incompatibilities …
I am not aware of recent any
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 Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
I think GnuTLS is actually a better alternative and wish there
were more people developing and using it.
[...]
* GnuTLS, with an API incompatible with OpenSSL, thus requiring huge
amounts of work to make significant use
* 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
Guus Sliepen g...@debian.org wrote:
[...]
The problem is that OpenSSL is much more than just an implementation of
SSL/TLS. It is also provides a very extensive set of low-level
cryptographic functions. There are many programs that use OpenSSL for
the latter, not for the SSL/TLS layer. You just
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
Meanwhile, we could try to get ever distro with a clue together, map the
versioned symbol diffs that already exist, and see if we can come up with a
plan to at least do downstream versioning in a compatible way.
Please, please, please speak to upstream first. It's hard work, but some
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 Sun, 13 Jul 2014, Juliusz Chroboczek wrote:
Meanwhile, we could try to get ever distro with a clue together, map the
versioned symbol diffs that already exist, and see if we can come up with a
plan to at least do downstream versioning in a compatible way.
Please, please, please speak
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 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
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 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:
libssl.so.26
libcrypto.so.29
I don't really like it, since it could potentionally clash with
the ones provided by openssl. But it seems unlikely that openssl
will
Kurt Roeckx k...@roeckx.be writes:
On Sat, Jul 12, 2014 at 01:53:45PM +0200, 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
I
John D. Hendrickson and Sara Darnell johnandsa...@cox.net writes:
Russ Allbery wrote:
OpenSSL ABI implementation to another is something of an all-or-nothing
affair. You can do a small amount of building key packages with the
other
? rhetorically i'm unsure there's a problem.
I have some
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.
65 matches
Mail list logo
