4:08 p.m.
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).
6:23 p.m.
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
8:56 p.m.
On Mon, Jun 11, 2012 at 12:23 PM, Richard Shaw <hobbes1069(a)gmail.com> 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
7:35 p.m.
On 06/11/2012 10:56 PM, Ken Dreyer wrote:
On Mon, Jun 11, 2012 at 12:23 PM, Richard Shaw
<hobbes1069(a)gmail.com> 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
6:27 p.m.
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
1:50 p.m.
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.s...
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
3:17 p.m.
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
3:40 p.m.
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
3:48 p.m.
On Fri, Jul 19, 2013 at 10:40 AM, Xavier Bachelot <xavier(a)bachelot.org>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
9:21 p.m.
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.s...
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
9:30 p.m.
On Wed, Jul 31, 2013 at 4:21 PM, Xavier Bachelot <xavier(a)bachelot.org>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.s...
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
4 p.m.
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=</path/to/freeworld/lib>
Thanks,
Richard
1:56 p.m.
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=</path/to/freeworld/lib>
It works for me, without any trick involved.
Before installing libgcrypt-freeworld :
$ldd /usr/lib64/libaacs.so.0
linux-vdso.so.1 => (0x00007fffe66f0000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x0000003a83400000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000348f000000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00000034a7600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000348f400000)
libc.so.6 => /lib64/libc.so.6 (0x000000348e800000)
/lib64/ld-linux-x86-64.so.2 (0x000000348e000000)
After installing libgcrypt-freeworld :
$ ldd /usr/lib64/libaacs.so.0
linux-vdso.so.1 => (0x00007fff34f78000)
libgcrypt.so.11 => /usr/lib64/libgcrypt-freeworld/libgcrypt.so.11
(0x00007fdb80dce000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000348f000000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00000034a7600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000348f400000)
libc.so.6 => /lib64/libc.so.6 (0x000000348e800000)
/lib64/ld-linux-x86-64.so.2 (0x000000348e000000)
Sorry for the late answer, I'm on vacation until end of next week, mostly away
from any computer.
Regards,
Xavier
9:01 p.m.
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 => (0x00007fff29f5f000)
libaacs.so.0 => /usr/lib64/libaacs.so.0 (0x0000003ecf800000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0
(0x0000003086600000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000003070200000)
libc.so.6 => /usr/lib64/libc.so.6 (0x000000306fe00000)
libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x0000003ecf400000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000003070600000)
/lib64/ld-linux-x86-64.so.2 (0x000000306fa00000)
Richard
10:37 p.m.
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 => (0x00007fff29f5f000)
libaacs.so.0 => /usr/lib64/libaacs.so.0 (0x0000003ecf800000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x0000003086600000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000003070200000)
libc.so.6 => /usr/lib64/libc.so.6 (0x000000306fe00000)
libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x0000003ecf400000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000003070600000)
/lib64/ld-linux-x86-64.so.2 (0x000000306fa00000)
Richard
Probably an rpath issue with aacs_info, not an issue with libgcrypt-freeworld
itself. I'll take a look asap.
Xavier
11:07 a.m.
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 => (0x00007fff29f5f000)
> libaacs.so.0 => /usr/lib64/libaacs.so.0 (0x0000003ecf800000)
> libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x0000003086600000)
> libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000003070200000)
> libc.so.6 => /usr/lib64/libc.so.6 (0x000000306fe00000)
> libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x0000003ecf400000)
> libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000003070600000)
> /lib64/ld-linux-x86-64.so.2 (0x000000306fa00000)
>
> 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
8:13 a.m.
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.s...
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
9:27 a.m.
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
9:16 a.m.
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
10:05 a.m.
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
7:43 p.m.
2012/6/13 Kevin Kofler <kevin.kofler(a)chello.at>:
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)
12:19 a.m.
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
12:55 a.m.
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
9:04 p.m.
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
6:49 a.m.
2012/8/19 Julian Sikorski <belegdol(a)gmail.com>:
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)
3831
days inactive
4330
days old
rpmfusion-developers@lists.rpmfusion.org
25 comments
6 participants
participants (6)
-
Julian Sikorski -
Ken Dreyer -
Kevin Kofler -
Nicolas Chauvet -
Richard Shaw -
Xavier Bachelot