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
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() repla
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:
>
> http://lists.op
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 inte
Hi,
Quoting Russ Allbery (2014-07-16 22:17:23)
> Ben Hutchings 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 interfac
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.
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 debia
Russ Allbery wrote:
>Steven Chamberlain 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 this attack har
On Wed, 2014-07-16 at 13:17 -0700, Russ Allbery wrote:
> Ben Hutchings 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 suc
Hi,
> Steven Chamberlain 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 Allbery wrot
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
Ben Hutchings 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. Expecting
> adminis
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 Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
> Steven Chamberlain 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 having a re
Steven Chamberlain 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 contrived issue wit
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
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 d
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 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 versioni
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 li
On Jul 15, Ryo IGARASHI 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
Hi, all,
On Sun, Jul 13, 2014 at 2:15 AM, Russ Allbery wrote:
> Kurt Roeckx 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 w
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 foll
Toni Mueller 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 historically GnuTLS
Steven Chamberlain 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 switches to Gnu
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
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 i
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
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 re
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),
> 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 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
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
> 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
upstre
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
Guus Sliepen 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 cannot drop
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 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 signif
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
Matthias Urlichs 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 changes to the O
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
❦ 13 juillet 2014 11:52 +0800, Thomas Goirand :
>> 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
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
"John D. Hendrickson and Sara Darnell" 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 experience
Kurt Roeckx 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 don't r
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
> w
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
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
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:
65 matches
Mail list logo
