Mageia Bugzilla – Bug 15218
libmspack is bundled into some packages (one package remaining: calibre)
Last modified: 2016-10-10 23:03:30 CEST
While investigating a recent vulnerability in libmspack
which we didn't have packaged, we found that it is bundled into some packages like cabextract and clamav. Oden discovered it in a few more:
Oden gave some details on how to potentially fix this:
Steps to Reproduce:
Maybe some other distros like Debian or OpenSuSE have some patches that can help.
Just FYI, Shlomi fixed cabextract in 1.5-2.mga5. Thanks Shlomi.
Shlomi, I also CC'd you for pidgin-msn-pecan.
(In reply to David Walser from comment #2)
> Just FYI, Shlomi fixed cabextract in 1.5-2.mga5. Thanks Shlomi.
> Shlomi, I also CC'd you for pidgin-msn-pecan.
pidgin-msn-pecan should be fixed now too - at least in Cauldron.
-- Shlomi Fish
Sophie shows there's other packages linked against it, eg: wxgtk
Copying a comment from Oden from the clamav bug:
libmspack in cabextract, evolution-ews and pidgin-msn-pecan has been unbundled in cauldron. What remains is calibre who needs hands on by a python wizard.
CC'ing Oden and Philippe on this bug.
(In reply to Thierry Vignaud from comment #6)
> And wxgtk...
It doesn't appear to bundle the mspack code, but it does support linking to libmspack with the --enable-libmspack option.
CC'ing Jani since he maintains wxgtk. It also could be updated to 3.0.2.
For calibre, no distro has a patch to make it use the system libmspack. The bundled code looks really old:
I don't know how the build system for this package works, so I don't know how one would go about making it link to the system libmspack.
For calibre we can try to disable the extension, or try to build with unbundled, seems that the code is there : https://github.com/kovidgoyal/calibre/blob/master/setup/extensions.py
Debian just don't build the unrar extension http://bazaar.launchpad.net/~calibre-packagers/calibre/debian/view/head:/debian/patches/dont_build_unrar_plugin.patch
In fact in Calibre the code is only use with the LIT Input plugin.
"LIT is a proprietary file extension for the Microsoft eBook Booklover, based on the chm file format logic."
And I'm even not sure that the code is touched by the vulnerability in libmspack, the code seems to come from http://www.russotto.net/chm/
I suggest to let calibre as is.
The code from the recent libmspack vulnerability isn't even present in this really old version of the code bundled into calibre. The point is, we don't want bundled libraries at all if we can avoid it.
(In reply to David Walser from comment #11)
> The point is, we don't want bundled libraries at all if we can avoid it.
I understand that, but I'm not sure that the code is really from libmspack.
For me it is a code from http://www.russotto.net/chm/
Disabling the extension is possible. Unbundle, I'm not sure.
No other distro unbundle it or disable it for what I know.
I let the maintainer decide.
It is some of the same code that's still in libmspack today, just an older version of it. libmspack is code for supporting the CHM file format. I don't know what that rusotto thing is, but it's probably based on the same code (as is cabextract).
As far as unbundling it, looking at the code, it's not obvious to me at all how you would do that.
For what I see in calibre, the produced lxc.so is only use by this thin wrapper :
if you can load a lib generated by libmspack instead of lxc.so, then it will be possible to unbundle.
Just don't build lxc.so (remove it from https://github.com/kovidgoyal/calibre/blob/master/setup/extensions.py) and change calibre/ebooks/lit/lzx.py to load your system lib, or symlink your system lib to calibre/plugins/lzx.so and test with a LIT file ?
Installing calibre and test with symlink to libmspack system lib instead of calibre/plugins/lzx.so can be the first test to see if we can easily unbundle.
but I have to LIT file to test.
FYI, wxgtk was updated to 3.0.2 and linked against system libmspack.
(In reply to Philippe Makowski from comment #14)
> Installing calibre and test with symlink to libmspack system lib instead of
> calibre/plugins/lzx.so can be the first test to see if we can easily
> but I have to LIT file to test.
But I don't have any LIT file to test, if someone get one ...
(In reply to Philippe Makowski from comment #16)
> (In reply to Philippe Makowski from comment #14)
> > Installing calibre and test with symlink to libmspack system lib instead of
> > calibre/plugins/lzx.so can be the first test to see if we can easily
> > unbundle.
> > but I have to LIT file to test.
> But I don't have any LIT file to test, if someone get one ...
I was long time looking this but i can not find a solution. Symlinking does not work. Also calibre developer doesn't a packager friendly one:
"WARNING: calibre is a highly complex piece of software with lots of very finicky dependencies. If you install from source, you are on your own. Please do not open bug reports or expect any form of support. You have been warned" from http://calibre-ebook.com/download_linux
Here is a link to a lit format file; altough the file is written in Turkish it should not be a problem playing with it.
Calibre uses libmspack source code not as is but a modified version of them. I think we have two choices; one is disabling lzx support which is not a thing that i want to do, other is let calibre continues to use internal lzx module.
Philippe, would you mind to inform me if you had tested provided .lit document against system libmspack or had found a solution for this?
no solution for now, Calibre use old code, so we keep bundle
Assigning to calibre maintainer since it's the only one remaining now.