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

Eric Wong normalperson at yhbt.net
Mon May 7 13:19:50 PDT 2012


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.


More information about the flac-dev mailing list