flac dev - May 2012 - [PATCH] Optionally, allow distros to use openssl for MD5 verification

El 07/05/12 06:23, Miroslav Lichvar escribi?:
> On Sat, May 05, 2012 at 05:34:31PM -0400, Cristian Rodr?guez wrote:
>> This has the advantage of being more efficient than the included
>> routines and allows distros to centralize crypto mainteniance on
>> a few libraries.
>
> Isn't the OpenSSL license incompatible with GPL? IANAL, but I think
> the flac and metaflac utilities can't be linked with OpenSSL unless
> there is an exception in the flac license which would require getting
> the permission from all contributors.
flac and metaflac do not use openSSL, only libFLAC does.
> I'd suggest to use the NSS library instead. It has an API just for
> hashing (NSSLOWHASH) which can be used with just one small library
> (freebl3) instead of the whole NSS stack.
And hence loosing all benefits from my patch, NSS does not have :

- Hardware assisted hashing
- NSSLOWHASH does not have documentation
- freedbl is not linked to any application in my full blow desktop, but 
openssl libcrypto is used widely, hence at least its codepaths are 
better excersized.

Personally I don't see any technical reason to use a different library 
other than politics and obscure potential license incompatibilities.

PS: I know NSS is the choice for this "design by comittee" thing
"Crypto
consolidation" in distributions that some suits are trying to push on, 
but Im glad to see it has failed miserably ;-)

Cristian Rodr?guez <crrodriguez at opensuse.org>
wrote:
> El 07/05/12 06:23, Miroslav Lichvar escribi?:
> > On Sat, May 05, 2012 at 05:34:31PM -0400, Cristian Rodr?guez wrote:
> >> This has the advantage of being more efficient than the included
Btw, how much more efficient and on what hardware?

Based on previous experience (in a project not related to FLAC) on
x86_64 (Core2 Duo), I don't recall the MD5 performance of OpenSSL ASM
being significantly faster than the equivalent C code (from gnulib).
SHA1 was a different story, but I still decided it wasn't worth my
time/effort to maintain (especially extra testing time to ensure code
works with and without OpenSSL).
> > Isn't the OpenSSL license incompatible with GPL? IANAL, but I
think
> > the flac and metaflac utilities can't be linked with OpenSSL
unless
> > there is an exception in the flac license which would require getting
> > the permission from all contributors.
> 
> flac and metaflac do not use openSSL, only libFLAC does.
But since flac/metaflac use libFLAC, I suspect (IANAL) the relationship
can be transitive.  (But being an optional dependency helps as distros
can avoid potential issues).
> Personally I don't see any technical reason to use a different library 
> other than politics and obscure potential license incompatibilities.
OpenSSL doesn't have a good track record as far as ABI/API stability is
concerned (though I think the hash APIs are more stable).

Perhaps disabling OpenSSL auto-detection (and only enabling it when
explicitly configured) is better?

One issue I've noticed in the (fast-moving) Ruby world:

  The ruby-core mailing list frequently sees segfault reports due to the
  "openssl" Ruby extension using one version/installation of OpenSSL
and
  another Ruby extension (e.g. EventMachine, curl) using a different
  OpenSSL version.  This is common occurrence, as distros will often
  ship with multiple OpenSSL versions to accomodate different apps and
  often Ruby installations/extensions are installed in home directories
  that aren't upgraded as the same time as the distro itself.

  I think these issue is a product of both the Ruby world moving too fast
  and OS distros moving too slowly, but it's the unfortunate reality
  Rubyists have to deal with :/

  I'd rather libFLAC sidestep these potential issues entirely.

El 07/05/12 16:19, Eric Wong escribi?:
>> flac and metaflac do not use openSSL, only libFLAC does.
>
> But since flac/metaflac use libFLAC, I suspect (IANAL) the relationship
> can be transitive.  (But being an optional dependency helps as distros
> can avoid potential issues).
That's why it is optional, however there is no such issue, all this 
incompatibility thing arised of interpretations by debian and the FSF, 
as far as the rest of the world. openSSL falls into the category of a 
"system library", twhich falls into the "special exception"
clause which
allows your GPL-ed program to link against GPL incompatible libraries 
which are shipped as part of the operating system.
> OpenSSL doesn't have a good track record as far as ABI/API stability is
> concerned (though I think the hash APIs are more stable).
Those  compiling and linking against incompatible library versions are 
doing it wrong, usually happends when users dont get proper packages 
from distributions or distributor-provided backports.

Cristian Rodr?guez wrote:
> flac and metaflac do not use openSSL, only libFLAC does.
But flac and metaflac are GPL and link (possibly statically) to 
libFLAC.
> Personally I don't see any technical reason to use a different library 
> other than politics and obscure potential license incompatibilities.
A license incompatibility is a license incompatiility and you
can't just cover your eyes and pretend it isn't there.

For instance in Debian, there are numerous packages that have
libreadline (GPL) support disabled because the package uses
OpenSSL.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/