date:20140713

Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

2014-07-13 Thread Matthias Urlichs

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 are
the security equivalent of gets() or scanf(%s) or …, then no.

 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 …

 Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but not
 have the choice between the 2, otherwise, that's a recipe for disaster.
 
Well …

 Please don't upload LibreSSL to Sid *ever*, unless we collectively
 decide that we are switching away from OpenSSL (and for which a
 discussion would have to start).
 
… 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), again IMHO the time and effort required
for _that_ would be better spent evaluating the changes both projects made
and then deciding which of the two shall be in Debian.

Both efforts have started fairly recently, so it's kind of premature to do
that now; and while IANARTM (Release Team Member) transitioning the whole
of Debian to libressl closer to the release would not be a good idea even
if we decide it's (going to be) the better alternative.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140713061751.ga15...@smurf.noris.de

Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

2014-07-13 Thread Vincent Bernat

 ❦ 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 should care about being ABI
 compatible, so we can easily switch from one implementation to the
 other. Just like for MariaDB / MySQL in fact (not sure if these are
 still ABI compatible though). If that's not the case, then it looses a
 lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative
 then.

It will never be ABI compatible since they have removed stuff. Anything
should be recompiled to ensure that obsolete functions are not used.

 OTOH, one guy already switched his entire Linux
 system over, so far with no visible adverse effects.

 And then? This gives no clue if he had to rebuild everything that
 build-depended on OpenSSL...

He did rebuild everything:
 http://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/
-- 
die_if_kernel(Kernel gets FloatingPenguinUnit disabled trap, regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c


signature.asc
Description: PGP signature

Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility

2014-07-13 Thread Vincent Bernat

 ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre st...@einval.com :

 And I've got to ask: for the couple of trivial examples that Frederick
 pointed out - why on earth do these even exist as libraries instead of
 being inlined wherever they're needed?

Because, in node, a library is cheap and the functionality get unit
tested. That's why there are so many dependencies in this ecosystem.

Inlining is solving the wrong problem.
-- 
printk(MASQUERADE: No route: Rusty's brain broke!\n);
2.4.3. linux/net/ipv4/netfilter/ipt_MASQUERADE.c


signature.asc
Description: PGP signature

Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility

2014-07-13 Thread Neil Williams

On Sun, 13 Jul 2014 09:26:38 +0200
Vincent Bernat ber...@debian.org wrote:

  ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre st...@einval.com :
 
  And I've got to ask: for the couple of trivial examples that
  Frederick pointed out - why on earth do these even exist as
  libraries instead of being inlined wherever they're needed?
 
 Because, in node, a library is cheap and the functionality get unit
 tested. That's why there are so many dependencies in this ecosystem.

Unit tests do not preclude inlining.
Unit tests do not preclude aggregation.

It's all just about multiple blocks of code in dedicated directories
inside a single source package building a single binary package from
which any other package can pick and choose the bits that package needs.

Just what is wrong with one binary package putting lots of js
in /usr/share/javascript/$library/$version/ and using symlinks in the
bigger package to pull in the files that package wants?

It's more work for the maintainers but it's less work for users - which
is the right way around.

 Inlining is solving the wrong problem.

Tiny packages are the wrong solution.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility

2014-07-13 Thread Jeroen Dekkers

At Sun, 13 Jul 2014 09:26:38 +0200,
Vincent Bernat wrote:
 
  ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre st...@einval.com :
 
  And I've got to ask: for the couple of trivial examples that Frederick
  pointed out - why on earth do these even exist as libraries instead of
  being inlined wherever they're needed?
 
 Because, in node, a library is cheap and the functionality get unit
 tested. That's why there are so many dependencies in this ecosystem.

You have all the extra metadata, extra git repository, extra
dependency tracking, etc. no matter how 'cheap' a library is.

And as far as I understand npm (correct me if I'm wrong, I don't use
npm very often), it will install dependencies in a nested way, so if
app1 use library1 and library2, and both those libraries use
tinylibrary1, tinylibrary2 and tinylibrary3, then those 3 tiny
libraries will be installed both under library1 and library2. I
wouldn't really call that cheap.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wqbhy54i.wl%jer...@dekkers.ch

Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

2014-07-13 Thread Jeroen Dekkers

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 backdoor in it.

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, but hey, sometimes one has to make a decision.

OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
how isn't OpenSSL part of the OpenBSD track record?

I think GnuTLS is actually a better alternative and wish there
were more people developing and using it.

But developing GnuTLS is a full-time job, and then there's the control
problem with the FSF - you are certainly aware about the problems the
original upstream ran into when he wanted to break loose from the FSF
(for a reason I have forgotten). LibreSSL is a much lower-hanging fruit,
as it is supposed to be mostly, or entirely, plug-compatible with
OpenSSL. To me, the playing field largely looks like this atm:

* GnuTLS, with an API incompatible with OpenSSL, thus requiring huge
amounts of work to make significant use of it.

It depends on how you look at it. If you see the OpenSSL API as
something that isn't really well designed then other libraries not
copying the API is actually a good thing.

* MatrixSSL, which once had a dubious license, and which still did not
come out too well in the SSL lib comparison I recently saw (see the
list archive),
* the now newly staffed OpenSSL project, with their mixed track
record (eg. FIPS), and now
* LibreSSL, which sounds much like an OpenSSL on a diet, and with some
exercise, and promising thrust behind it, but mostly simply a
drop-in.

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 drop-in
for OpenSSL we can't replace OpenSSL with LibreSSL for those projects.

You also forget to list two other TLS libraries:

* NSS, in my opinion the biggest downside of NSS is that it includes
NSPR. This both increases the code size a lot and makes the API less
nice if I remember correctly.

* PolarSSL, which I really like from a technical point of
view. Featurewise it is pretty complete (the only major feature it
doesn't implement is DTLS AFAICS), while being one tenth the size of
OpenSSL / GnuTLS:

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies
PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version
that is used by the Dutch government.
The downsides are that it looks like it doesn't have a stable API
and contributing needs copyright assignment because it is
dual-licensed.

Kind regards,

Jeroen Dekkers

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbr1y2va.wl%jer...@dekkers.ch

1 2 >

1 - 100 of 133 matches

Mail list logo