Hi,
On Mon, Nov 14, 2016 at 04:07:17PM +0900, Marc Dequènes wrote:
> Quack,
>
> On 2016-11-14 04:06, Julius Schwartzenberg wrote:
> > I just discovered that there's an old package already called mscompress
> > which contains an msexpand binary. This binary seems to support fewer
> > formats than the one from libmspack though.
>
> Thanks for the report; it would be nice to simplify indeed.
>
> > My suggestion would be to remove the mscompress package and replace it
> > with the binaries from libmspack.
>
> The sources in test/ are clearly not indented to be more than mere tests.
> As for the expand functionality, test/expand.c should work but the command
> line options differ, so as is it cannot be renamed and replace mscompress's
> one directly.
> I see no program to compress, so I guess it would have to be written.
A later commit moved[1] them from test/ to src/ or examples. But upstream
still say in one of the latest Changelog entries:
* src/chmextract.c: add anti "../" and leading slash protection to
chmextract. I'm not pleased about this. All the sample code provided
with libmspack is meant to be simple examples of library use, not
"productised" binaries. Making the "useful" code samples install
as binaries was a mistake. They were never intended to protect you
from unpacking archive files with relative/absolute paths, and I
would prefer that they never will be.
So those are meant as simple examples of the libary use, and not
"productised" binaries.
Just a general comment, maybe not specific for this bug, as I stumpled
while checking another issue over this upstream changelog entry.
Regards,
Salvatore
[1]
https://github.com/kyz/libmspack/commit/d3ff5b280a834cd430ab484fab32b6c29c75d3c1
