Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On Wed, Oct 23, 2013 at 4:16 AM, Xavier Bachelot wrote: > Tested OK and karma given. > A major roadblock has been removed, enjoy :-) Awesome! Thanks, Richard
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 10/22/2013 11:27 AM, Xavier Bachelot wrote: On 10/15/2013 10:13 AM, Xavier Bachelot wrote: ECC seems to be allowed in Fedora now. I've filled a bug against libgcrypt requesting to enable it : https://bugzilla.redhat.com/show_bug.cgi?id=1019126 Once this is done, the libgcrypt-freeworld will become useless. ECC-enabled libgcrypt is now available in Koji : https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc19 https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc20 Not tested yet, I will test and give karma this evening. Tested OK and karma given. A major roadblock has been removed, enjoy :-) Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 10/15/2013 10:13 AM, Xavier Bachelot wrote: ECC seems to be allowed in Fedora now. I've filled a bug against libgcrypt requesting to enable it : https://bugzilla.redhat.com/show_bug.cgi?id=1019126 Once this is done, the libgcrypt-freeworld will become useless. ECC-enabled libgcrypt is now available in Koji : https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc19 https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc20 Not tested yet, I will test and give karma this evening. Make sure to remove libgcrypt-freeworld if you have it installed or at least comment out /etc/ld.so.conf.d/libgcrypt-freeworld-*.conf and run ldconfig before testing. Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 07/31/2013 11:21 PM, Xavier Bachelot wrote: Hi, New version, merging changes from the new Fedora release : spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec srpm : http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.3-1.fc19.1.src.rpm Shall I open a formal review ticket or does anyone think that another approach than the "override Fedora provided lib" would be better ? Regards, Xavier ECC seems to be allowed in Fedora now. I've filled a bug against libgcrypt requesting to enable it : https://bugzilla.redhat.com/show_bug.cgi?id=1019126 Once this is done, the libgcrypt-freeworld will become useless. Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 08/09/2013 12:37 AM, Xavier Bachelot wrote: > On 08/08/2013 11:01 PM, Richard Shaw wrote: >> For me the problem wasn't libaacs, but the aacs_info binary which seems to >> independently link to libgcrypt. Before setting the LD_PRELOAD environment >> variable it pretty much gave up getting any information about the blu-ray >> video, >> afterwards it still failed, but it did try. >> >> # ldd /usr/bin/aacs_info >> linux-vdso.so.1 => (0x7fff29f5f000) >> libaacs.so.0 => /usr/lib64/libaacs.so.0 (0x003ecf80) >> libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 >> (0x00308660) >> libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00307020) >> libc.so.6 => /usr/lib64/libc.so.6 (0x00306fe0) >> libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x003ecf40) >> libdl.so.2 => /usr/lib64/libdl.so.2 (0x00307060) >> /lib64/ld-linux-x86-64.so.2 (0x00306fa0) >> >> Richard > > Probably an rpath issue with aacs_info, not an issue with libgcrypt-freeworld > itself. I'll take a look asap. > > Xavier > Fixed in cvs, building now. Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 08/08/2013 11:01 PM, Richard Shaw wrote: > For me the problem wasn't libaacs, but the aacs_info binary which seems to > independently link to libgcrypt. Before setting the LD_PRELOAD environment > variable it pretty much gave up getting any information about the blu-ray > video, > afterwards it still failed, but it did try. > > # ldd /usr/bin/aacs_info > linux-vdso.so.1 => (0x7fff29f5f000) > libaacs.so.0 => /usr/lib64/libaacs.so.0 (0x003ecf80) > libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00308660) > libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00307020) > libc.so.6 => /usr/lib64/libc.so.6 (0x00306fe0) > libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x003ecf40) > libdl.so.2 => /usr/lib64/libdl.so.2 (0x00307060) > /lib64/ld-linux-x86-64.so.2 (0x00306fa0) > > Richard Probably an rpath issue with aacs_info, not an issue with libgcrypt-freeworld itself. I'll take a look asap. Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
For me the problem wasn't libaacs, but the aacs_info binary which seems to independently link to libgcrypt. Before setting the LD_PRELOAD environment variable it pretty much gave up getting any information about the blu-ray video, afterwards it still failed, but it did try. # ldd /usr/bin/aacs_info linux-vdso.so.1 => (0x7fff29f5f000) libaacs.so.0 => /usr/lib64/libaacs.so.0 (0x003ecf80) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00308660) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00307020) libc.so.6 => /usr/lib64/libc.so.6 (0x00306fe0) libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x003ecf40) libdl.so.2 => /usr/lib64/libdl.so.2 (0x00307060) /lib64/ld-linux-x86-64.so.2 (0x00306fa0) Richard
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 08/03/2013 06:00 PM, Richard Shaw wrote: > Have you been able to set this? > > I installed the resultant RPM but even with the ldconf file, all programs seem > to prefer the official libgcrypt library. In order to force it I had to > specify > the freeworld library with LD_PRELOAD= > It works for me, without any trick involved. Before installing libgcrypt-freeworld : $ldd /usr/lib64/libaacs.so.0 linux-vdso.so.1 => (0x7fffe66f) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x003a8340) libdl.so.2 => /lib64/libdl.so.2 (0x00348f00) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x0034a760) libpthread.so.0 => /lib64/libpthread.so.0 (0x00348f40) libc.so.6 => /lib64/libc.so.6 (0x00348e80) /lib64/ld-linux-x86-64.so.2 (0x00348e00) After installing libgcrypt-freeworld : $ ldd /usr/lib64/libaacs.so.0 linux-vdso.so.1 => (0x7fff34f78000) libgcrypt.so.11 => /usr/lib64/libgcrypt-freeworld/libgcrypt.so.11 (0x7fdb80dce000) libdl.so.2 => /lib64/libdl.so.2 (0x00348f00) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x0034a760) libpthread.so.0 => /lib64/libpthread.so.0 (0x00348f40) libc.so.6 => /lib64/libc.so.6 (0x00348e80) /lib64/ld-linux-x86-64.so.2 (0x00348e00) Sorry for the late answer, I'm on vacation until end of next week, mostly away from any computer. Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Have you been able to set this? I installed the resultant RPM but even with the ldconf file, all programs seem to prefer the official libgcrypt library. In order to force it I had to specify the freeworld library with LD_PRELOAD= Thanks, Richard
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On Wed, Jul 31, 2013 at 4:21 PM, Xavier Bachelot wrote: > Hi, > > New version, merging changes from the new Fedora release : > spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec > srpm : > > http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.3-1.fc19.1.src.rpm > > Shall I open a formal review ticket or does anyone think that another > approach > than the "override Fedora provided lib" would be better ? As as the package doesn't conflict with the Fedora package I'm fine, but I don't know that my vote counts :) Richard
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Hi, New version, merging changes from the new Fedora release : spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec srpm : http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.3-1.fc19.1.src.rpm Shall I open a formal review ticket or does anyone think that another approach than the "override Fedora provided lib" would be better ? Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Hi Richard,
On 07/19/2013 05:17 PM, Richard Shaw wrote:
> Xavier,
>
> Thanks for taking this up. I recently got a bluray drive for my desktop
> machine
> but haven't gotten around to trying it yet...
>
It should hopefully be quite straightforward now.
yum install $PREFERRED_VIDEO_PLAYER libaacs libgcrypt-freeworld
then drop a properly filled KEYDB.cfg file in /etc/xdg/aacs.
repoquery says mplayer, vlc, xbmc and xine-lib have support for libbluray.
> Some pre-review comments:
>
> 1. Are you planning to keep a minimal diff from the upstream spec?
>
> If not you can remove BuildRoot: and Group: tags.
>
Yes, I'd rather keep the spec as close as possible to Fedora's one. Less
thinking when merging changes from Fedora, lower turnaround for (security)
updates.
> 2. Shouldn't this package Require: the parent package in Fedora? (Requires:
> libgcrypt%{?_isa} = %{version}-%{release})
>
> Perhaps the release part isn't necessary...
>
Why ? Keep both in sync ? Once libgcrypt-freeworld is installed, the regular
libgcrypt is not really used anymore, so I'm not sure it really matters.
Regards,
Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On Fri, Jul 19, 2013 at 10:40 AM, Xavier Bachelot wrote:
> > 2. Shouldn't this package Require: the parent package in Fedora?
> (Requires:
> > libgcrypt%{?_isa} = %{version}-%{release})
> >
> > Perhaps the release part isn't necessary...
> >
> Why ? Keep both in sync ? Once libgcrypt-freeworld is installed, the
> regular
> libgcrypt is not really used anymore, so I'm not sure it really matters.
>
> Sorry, I thought this was more like my sox-freeworld package. I build
everything and them rm -f the files that the Fedora sox package supplies so
it works along side the Fedora package, I guess in this case we're more or
less replacing the Fedora package.
Richard
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Xavier,
Thanks for taking this up. I recently got a bluray drive for my desktop
machine but haven't gotten around to trying it yet...
Some pre-review comments:
1. Are you planning to keep a minimal diff from the upstream spec?
If not you can remove BuildRoot: and Group: tags.
2. Shouldn't this package Require: the parent package in Fedora? (Requires:
libgcrypt%{?_isa} = %{version}-%{release})
Perhaps the release part isn't necessary...
Thanks,
Richard
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Hi, On 06/11/2012 08:27 PM, Xavier Bachelot wrote: > On 06/11/2012 06:08 PM, Nicolas Chauvet wrote: >> > Hi, >> > >> > As you may know, the libaacs package from RPM Fusion rely on openssl >> > functions that have been disabled in the fedora package for some >> > reason. > This is actually libgcrypt, not openssl, but this is the same issue. ECC > is possibly patent-encumbered and thus disabled in both packages. > The issue is still blocked by Fedora Legal. > >> > This lead the libaacs package to be partially unuseable for it's target >> > usage. >> > >> > 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. > That was the solution I was looking at, but I've not finished up the > work yet. If this is not an acceptable solution, please let me know so I > don't resume work on it if this is doomed to be rejected. > I've finally had some time to look into this more and I now have a libgcrypt-freeworld package build along the same tricks as freetype-freeworld. This removes the need for pre-calculated VUKs for libaacs and thus allows much simpler bluray reading. spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec srpm : http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.2-1.fc19.1.src.rpm I'd be glad if someone can take a look and evaluate if that's worth submitting for review. >> > - 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. I've not cut the solutions above, in order to keep some context, even if this is not what I've done. Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
2012/8/19 Julian Sikorski : > W dniu 11.06.2012 18:08, Nicolas Chauvet pisze: >> Hi, >> >> As you may know, the libaacs package from RPM Fusion rely on openssl >> functions that have been disabled in the fedora package for some >> reason. >> This lead the libaacs package to be partially unuseable for it's target >> usage. >> >> 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. >> - 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. >> >> 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. >> >> Any thoughts on that ? >> >> Nicolas (kwizart). >> > Has there been any progress on this? I have recently put a new enough > dvd in my drive that the only non-revoked publicly known key is the PS3 > one, and that one does not work with aacskeys. It probably worth to do some testing before to agree with one or another solution. The easiest one (none intrusive) is probably to build it statically. One way to solve the symbol mismatch would be to rely on symbol versioning but this would requires involvement from the related upstream projects. What the respective upstream think about this issue ? Nicolas (kwizart)
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
W dniu 11.06.2012 18:08, Nicolas Chauvet pisze: > Hi, > > As you may know, the libaacs package from RPM Fusion rely on openssl > functions that have been disabled in the fedora package for some > reason. > This lead the libaacs package to be partially unuseable for it's target usage. > > 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. > - 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. > > 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. > > Any thoughts on that ? > > Nicolas (kwizart). > Has there been any progress on this? I have recently put a new enough dvd in my drive that the only non-revoked publicly known key is the PS3 one, and that one does not work with aacskeys. Regards, Julian
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
I wrote: > They all have the same limitation (except in a few cases where upstream > renamed ALL the symbols of the library exactly to prevent that): They > CANNOT be directly or indirectly linked into one and the same executable. > E.g. it is NOT possible to use anything GTK+ 2 in a GTK+ 3 application. > Where this restriction was disobeyed, compatibility libraries HAVE lead to > symbol conflicts, e.g. this has been a problem very recently with Berkeley > db. (Unfortunately, I don't have the bug ID handy.) This is also one of > the reasons why compatibility libraries are discouraged in Fedora and only > to be used as a last resort, if porting the applications is impossible in > a reasonable timeframe. PS: Another example of a symbol conflict: http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm The issue there turned out to be that Gallium and OpenGTL both statically linked LLVM, and were both linked into Krita. The fix was to make both Gallium and OpenGTL link the shared system LLVM library. Only after BOTH were changed to use the shared library, the problem went away. Kevin Kofler
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Nicolas Chauvet wrote: > This could be true before the "gold" linker, I expect it tend to > disappear since we explicitly link a given library. I don't think > preload would mix symbols in this case. The checks that got added are only link-time checks. The runtime ld.so still works the same way as always, a symbol is global and the linker will just randomly pick the first symbol it finds with the given name in ANY loaded library. > Do you have any reference of such issue in the recent history ? There are many such issues all the time. The usual result is a crash, and a particularly hard to debug one at that. > There are already several libraries (compat or for another ABI) that > are provided multiple times from the repository. They all have the same limitation (except in a few cases where upstream renamed ALL the symbols of the library exactly to prevent that): They CANNOT be directly or indirectly linked into one and the same executable. E.g. it is NOT possible to use anything GTK+ 2 in a GTK+ 3 application. Where this restriction was disobeyed, compatibility libraries HAVE lead to symbol conflicts, e.g. this has been a problem very recently with Berkeley db. (Unfortunately, I don't have the bug ID handy.) This is also one of the reasons why compatibility libraries are discouraged in Fedora and only to be used as a last resort, if porting the applications is impossible in a reasonable timeframe. We also had symbol conflicts without any compatibility library involved, where 2 unrelated libraries (or a library and an executable) happened to use the same public symbol name (often due to not using ELF hidden visibility: hidden symbols are local to the library or executable, visible symbols are global, so if you don't hide your internal symbols, that often exposes symbols with very generic names). But most often it happens with compatibility libraries. So I stand by it: The only practical way to ship an openssl-freeworld is such that it overrides the Fedora openssl. Kevin Kofler
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
2012/6/13 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. This could be true before the "gold" linker, I expect it tend to disappear since we explicitly link a given library. I don't think preload would mix symbols in this case. Do you have any reference of such issue in the recent history ? There are already several libraries (compat or for another ABI) that are provided multiple times from the repository. >> 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). I would use another workflow since fedora git. - Using a local branch tracking fedora origin/master (or another branch). - Doing commit there - On fedora package update (for the given branch), rebasing the commit for my local branch. - fedora srpm still works, so using cvs-import.sh into RPM Fusion. I'm not sure if git would allow me to track foo.spec from fedora if it's renamed as foo-freeworld.spec in my local branch. I will test that. Nicolas (kwizart)
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
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 06/11/2012 10:56 PM, Ken Dreyer wrote: > On Mon, Jun 11, 2012 at 12:23 PM, Richard Shaw wrote: >> Unless something other than libaacs will use the freeworld package, I >> think this is a prime example of why there needs to be exceptions to >> the rules :) >> >> I don't know of any formal approval mechanism here, but my vote would >> be to allow the bundled/static linking for this and just following the >> Fedora guidelines for Provides: bundled(openssl). > > Like Richard said, if there's no other app that uses ECC, I think this > is the right approach. > libaacs is probably not the only app that would benefit from ECC support. For example, openssh, bitcoin, some digital certificates are using ECC... There are propably others examples, but I've not done an extended research on the matter. And one would need to make -freeworld version of at least openssl, libgcrypt and possibly more do have full coverage. Anyway, could anyone give some pointers or even spec file for bundling and static linking ? I'd like to take a look before trying the same for libaacs. Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On Mon, Jun 11, 2012 at 12:23 PM, Richard Shaw wrote: > Unless something other than libaacs will use the freeworld package, I > think this is a prime example of why there needs to be exceptions to > the rules :) > > I don't know of any formal approval mechanism here, but my vote would > be to allow the bundled/static linking for this and just following the > Fedora guidelines for Provides: bundled(openssl). Like Richard said, if there's no other app that uses ECC, I think this is the right approach. - Ken
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 06/11/2012 06:08 PM, Nicolas Chauvet wrote: > Hi, > > As you may know, the libaacs package from RPM Fusion rely on openssl > functions that have been disabled in the fedora package for some > reason. This is actually libgcrypt, not openssl, but this is the same issue. ECC is possibly patent-encumbered and thus disabled in both packages. The issue is still blocked by Fedora Legal. > This lead the libaacs package to be partially unuseable for it's target usage. > > 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. That was the solution I was looking at, but I've not finished up the work yet. If this is not an acceptable solution, please let me know so I don't resume work on it if this is doomed to be rejected. > - 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. > > 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. > > Any thoughts on that ? Glad you ask the question on the list, I should have done that myself earlier. Regards, Xavier
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
Unless something other than libaacs will use the freeworld package, I think this is a prime example of why there needs to be exceptions to the rules :) I don't know of any formal approval mechanism here, but my vote would be to allow the bundled/static linking for this and just following the Fedora guidelines for Provides: bundled(openssl). Richard
