[RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Kevin Kofler]

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