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).