[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