Bug#926118: Alternative for unblock: libmspack/0.10.1-1

2019-06-06 Thread Jens Reyer
On 06.06.19 22:24, Jens Reyer wrote:
> The referenced ChangeLog was:
[...]
I missed a second entry:> chmd_read_headers(): a CHM file name beginning
"::" but shorter
> than 33 bytes will lead to reading past the freshly-allocated
> name buffer - checks for specific control filenames didn't take
> length into account. Thanks to ADLab of Venustech for the report
> and proof of concept.



Bug#926118: Alternative for unblock: libmspack/0.10.1-1

2019-06-06 Thread Jens Reyer
Hi all,

first off, many thanks for your efforts here, Paul!


On 06.06.19 15:54, Paul Gevers wrote:
> On 06-06-2019 04:23, Marc Dequènes (duck) wrote:
>> I'm not committing to this plan for the above stated reasons. I also
>> feels uncomfortable uploading with a know security problem, so unless
>> upstream or our security team says it's low risk, I'm not taking such
>> responsibility.
>
> Sorry, I am mising something here. Can you please point me to it again?


AFAICT duck had this in his original unblock request:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923885#5:
> Please unblock package libmspack. 0.9.1-1 should have made it
> but somehow the build failed on big-endian systems (see #914794),
> maybe gcc changes in the meanwhile; anyway upstream kindly fixed
> it but it took some time.
>
> 0.10.1 is a maintenance release with only few fixes, among which
> fixing chmd_read_headers() closed a security problem (see upstream
> ChangeLog in debdiff). There is also a simple one-liner fix for
> the doc (compared to 0.9.1-1, which had ample time to be tested).
> I would also note that 0.9.1-1 fixed a regression (see #912687).
> Thus I believe 0.10.1-1 is a much better fit for release and hope
> you would conclude the same.


The referenced ChangeLog was:

2019-02-18  Stuart Caie :
> chmd_read_headers(): CHM files can declare their chunks are any
> size up to 4GB, and libmspack will attempt to allocate that to
> read the file.
>
> This is not a security issue; libmspack doesn't promise how
> much memory it'll use to unpack files. You can set your own
> limits by returning NULL in a custom mspack_system.alloc()
> implementation.
>
> However, it would be good to validate chunk size further. With
> no offical specification, only empirical data is available. All
> files created by hhc.exe have a chunk size of 4096 bytes, and
> this is matched by all the files I've found in the wild, except
> for one which has a chunk size of 8192 bytes, which was created
> by someone developing a CHM file creator 15 years ago, and they
> appear to have abandoned it, so it seems 4096 is a de-facto
> standard.
>
> I've changed the "chunk size is not a power of two" warning to
> "chunk size is not 4096", and now only allow chunk sizes between
> 22 and 8192 bytes. If you have CHM files with a larger chunk
> size, please send them to me and I'll increase this upper limit.
>
> Thanks to ADLab of Venustech for the report.



On 06.06.19 15:54, Paul Gevers wrote:
> On 06-06-2019 04:23, Marc Dequènes (duck) wrote:
>> On 2019-06-04 03:53, Paul Gevers wrote:
>> Currently the current version has been sitting in unstable for three
>> months without any single bug reported, this feels like a good progress
>> towards saying this version is safe.
>
> It's a valid argument for sure.

And the previous 0.9.1-1 is even 7 months old now, having been blocked
only by the big endian issue.  Personally I doubt an in-depth code
review is really helpful here.  Anyway, I'm attaching 2 new debdiffs:

Upstream did a "tab to spaces".  A "debdiff --ignore-space" reduces the
diff from 11176 to 4819 lines.  I think this is also a point for
0.10.1-1 in buster, because it will make eventual security updates easier.

I further removed the diff of generated, examples and test files (I
marked those files in the diffstat).  Yay, the diff had 678 lines
improving the tests!

I did this both for each 0.8-1 (in the archive since 2018-10-24) and
0.9.1-1 (2018-11-06) compared to 0.10.1-1 (2019-03-05).

So if at all, I'd suggest to only have a look at the last one of these
diffs:

$ wc -l debdiff_libmspack_0.*
 11176 debdiff_libmspack_0.8-1_0.10.1-1.diff
  4819 debdiff_libmspack_0.8-1_0.10.1-1_ignore-space.diff
  1724 debdiff_libmspack_0.8-1_0.10.1-1_ignore-space_edited.diff
  1067 debdiff_libmspack_0.9.1-1_0.10.1-1_ignore-space.diff
   731 debdiff_libmspack_0.9.1-1_0.10.1-1_ignore-space_edited.diff

Thanks again and greets
jre
diffstat for libmspack-0.8 libmspack-0.10.1

 ChangeLog   |  107 +
 Makefile.am |   66 
-Makefile.in |  737 +++---
 README  |   17 
 acinclude.m4|   12 
 config.h.in |   27 
-configure   |  402 +++--
 configure.ac|   20 
 debian/changelog|   18 
 debian/control  |2 
 debian/copyright|2 
 debian/libmspack-doc.docs   |   12 
 debian/rules