Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Nicolas Chauvet wrote:
I would like to list what would be possible workarounds for this
issue. We likely need to build a openssl-freeworld package:
- Build a similar package and drop a file in ld.conf.d to make it
system wide ? (the freetype-freeworld way)
This seems unpractical as we may produce unknown behavior and
un-certified code path with others applications.
I think this is the only practical solution. It means other applications
will also benefit from ECC support, in particular, all those which simply
support all crypto algorithms supported by OpenSSL (e.g. browsers). ECC was
also the blocker for bitcoin and probably some more packages.
- Build a shared object with another SONAME so packages liked with
the
freeworld version will not conflict with package linked with the
fedora version.
(It will eventually be possible to relink the so to the the fedora
SONAME manually in a second step).
- Build the freeworld version statically.
Both these versions are likely to lead to symbol conflicts, because
multimedia apps tend to link a lot of libraries, so they'd end up with both
libaacs (or the custom OpenSSL it links) and the system OpenSSL providing
the same symbols with different implementations. This is a recipe for a
disaster.
The question to sync the patch between fedora and RPM Fusion VCS is
a
big question until we move to git, so I hope that progress will be
made in this area soon.
If not we may experiment an openssl-freeworld to be possibily behind
the fedora version.
How I deal with it for freetype-freeworld is that I am on watchcommits and
watchbugzilla for the Fedora freetype and just sync the patches by hand as
soon as humanely possible. This needs to go fast because the fixes tend to
be security fixes (which is also the case for OpenSSL).
Kevin Kofler