libopenmpt modplug compat in Debian

[James Cowgill]

Hi,

On 09/01/17 20:44, Jörn Heusipp wrote:
> Hello
> 
> CCing James Cowgill and Stephen Kitt (Debian libmodplug maintainer)
> 
> On 01/09/2017 05:05 PM, Lionel Debroux wrote:
> 
>> James Cowgill uploaded an update to the existing Debian openmpt source
>> package, containing the libmodplug compat layer. At the time of this
>> writing, it's still "NEW" ( https://ftp-master.debian.org/new.html ),
>> but it should transition into unstable well in time for the hard freeze
>> of Stretch. And even if it didn't, chances are that the security team
>> will insist for the libmodplug compat layer to become available in
>> Stretch, per the discussion I started several days ago...
> 
> What was that discussion about?
> Is it available in public (quick googling did only turn up [1] and [2]
> regarding libopenmpt and Debian).

It wasn't CCed to any public mailing lists.

My (hopefully accurate) summary of it:

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.

> I'll refer to the 2 different ways of packaging the libopenmpt
> libmodplug compat layer as per [2].
> 
> 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!

> Option 2 has of course risks associated with it. Please see the comment
> at the top of libopenmpt_modplug_cpp.cpp [3]. 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 [4])),
> 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.

> Also, from my outside view on the security implications of libmodplug,
> the situation is probably not worse for the next Debian release than it
> already was for the last release.

That doesn't mean that we shouldn't try to improve the situation for
Stretch :)

> Same as already discussed by James and Johannes, I can also see some use
> in actually having the compat layer included in Debian, but that use
> probably only exists for users if they can actually switch between
> original libmodplug and the libopenmpt compat layer by
> installing/uninstalling the appropriate packages. That will only work
> with option 2 and the two packages conflicting with each other (as I had
> outlined in the documentation at [5] already). I do not follow Debian
> development closely, but as far as I understand, it's probably way way
> too late for that to be implemented in Stretch.

Yes I think so.

> Longer term, there already exists a gstreamer plugin using libopenmpt in
> the gst-nonstream-audio project [6] , 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.

> In general, I think I agree with Stephen's opinion at [7].
>  
> [1] https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2017-January/056752.html
> [2] https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2017-January/056760.html
> [3] https://source.openmpt.org/browse/openmpt/trunk/OpenMPT/libopenmpt/libopenmpt_modplug_cpp.cpp
> [4] https://lib.openmpt.org/libopenmpt/#sec_faq
> [5] https://lib.openmpt.org/doc/packaging.html
> [6] https://github.com/dv1/gst-nonstream-audio
> [7] https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2017-January/056774.html
>  
> If anyone wants to take this discussion to the appropriate public Debian
> mailing list, feel free to do so and feel also free to quote as needed.
> Please keep me and Johannes CCed though, as we are not subscribed to any
> Debian list. (Do I need to be subscribed to post there?).

I've added the multimedia list. You don't need to be subscribed to post
there.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170109/7513ed9c/attachment.sig>