libopenmpt modplug compat in Debian
osmanx at problemloesungsmaschine.de
Mon Jan 9 23:41:13 UTC 2017
On 01/09/2017 11:59 PM, James Cowgill wrote:
> Lionel found (and he may be able to expand on this) a large number of
> potential security bugs in libmodplug recently which have not yet been
> fixed. To try and improve the security situation of various package in
> Debian, he requested that the security team start to move packages away
> from libmodplug. From this Moritz (security team member) concluded that
> widely used packages (like gstreamer and VLC) cannot use libmodplug at
> all in stretch.
> The suggestion was to use the libopenmpt modplug compatibility layer as
> a "free" way to fix this since it would require no code changes to the
> affected packages. I'm guessing it was just a coincidence that Johannes
> raised the issue with me the previous week.
That's the context I was missing, thanks for explanation.
So, I gather the plan here is to re-link VLC and gstreamer (and maybe
others) against the libopenmpt modplug compat layer for Stretch, right?
Given the time pressure, that choice appears logical now.
ffmpeg already has native libopenmpt support.
>> I'll refer to the 2 different ways of packaging the libopenmpt
>> libmodplug compat layer as per .
>> While option 1 is surely the safe choice, it is probably also rather
>> useless in general. The chances of programs opting in to use libopenmpt
>> instead of libmodplug is probably zero. After all, neither the
>> libmodplug nor the libopenmpt API is that complicated at all. It
>> probably only takes some hours to convert existing code from one to the
>> other, which programs which actually want to switch could do easily. I
>> do not expect it to matter much at all whether the compat layer gets
>> included this way in Stretch or not.
> I agree that in the long run it isn't the best option, but it is the
> easiest way to keep functionality for Stretch. If the relevant packages
> can be ported in time for Stretch (you have maybe 2 weeks at the most)
> that's great, but if they can't be then this can be used as a fallback.
> I also don't see many downsides in making the compat layer available for
> use (even if nothing uses it) especially given that I've already
> packaged it!
Well, the only "real" downside may be that something might start
actually depending on it. Especially, I would rather not want to see any
upstream projects integrating support for linking the libopenmpt modplug
compat layer instead of porting to the libopenmpt API.
>> Option 2 has of course risks associated with it. Please see the comment
>> at the top of libopenmpt_modplug_cpp.cpp . While, to the best of my
>> knowledge, libopenmpt emulates the libmodplug C API/ABI completely and
>> 100% compatible (it ignores DSP post-processing effects though,
>> libopenmpt just does not include the corresponding code, and misses some
>> other (almost certainly irrelevant) features (see the FAQ )),
>> emulating the C++ API is in a really hacky state. Thus, personally, I'd
>> feel rather uneasy if Debian is going to rely on that in any package at
>> all (to my knowledge, the original xmms-modplug plugin and the
>> libmodplug gstreamer plugin are using the C++ API, but there might also
>> be other users).
> I think the problem with option 2 is that it requires checking every
> package which uses libmodplug to see if it works properly with the
> compat layer (as opposed to a few packages using option 1). Having 2
> packages providing the same library also complicates things.
> For Buster, I think we should completely replace libmodplug with the
> libopenmpt compatibility layer while at the same time trying to port as
> much stuff away from the libmodplug api as possible. It's too late to do
> that for Stretch though.
>> Longer term, there already exists a gstreamer plugin using libopenmpt in
>> the gst-nonstream-audio project  , which IMHO should be much
>> preferred to using the existing libmodplug gstreamer plugin with the
>> libopenmpt libmodplug compat layer.
> This is a good idea for Buster.
So, at least for Buster, the overall plan seems clear ;)
More information about the pkg-multimedia-maintainers