Re: [lmi] PATCH: use compressed .mst files

[Vadim Zeitlin]

On Mon, 29 Oct 2018 10:25:12 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-10-25 18:00, Vadim Zeitlin wrote:
GC> [...]
GC> >   https://github.com/vadz/lmi/pull/100
GC> 
GC> I've done something quite similar in commit 0f81d542.

 So do I understand correctly that the idea of using LZMA compression for
these files is abandoned now?

GC> >  The code changes are really simple and the only potentially questionable
GC> > thing is the use of access() to test for the file existence, but this is
GC> > how lmi seems to do it elsewhere, so I did it here too, even though this
GC> > code could use wxFileName::Exists() instead or even just try to open the
GC> > file input stream and rely on the error generated by it -- except that 
this
GC> > would have required dealing with wxLog and lmi code does not do this
GC> > anywhere else, so I didn't do it here neither.
GC> 
GC> This would have introduced a dependency on classes
GC>     wxFileInputStream
GC>     wxLZMAInputStream
GC>     wxStringOutputStream
GC> which aren't otherwise used in lmi code.

 The use of wxFileInputStream and wxStringOutputStream could be avoided,
they just provide the most succinct way of using wxLZMAInputStream in this
situation. And I didn't think there was any point in avoiding them in the
code which already uses wxWidgets anyhow (as indicated by the "_wx" suffix
in the file name...).

GC> Sorry, I had thought it might be possible to use wx's builtin liblzma
GC> more directly.

 Even if it were possible, you wouldn't really want to do it. liblzma API
is not bad, but it's nowhere near as simple as using it via streams
interface, see code starting at

https://github.com/wxWidgets/wxWidgets/blob/25a54a9b56d9a3eda3f9c657f4aa438b1d5932a4/src/common/lzmastream.cpp#L111


GC> But, given that the only purpose is obfuscation, I decided to XOR the
GC> MST files' contents with 0xFF instead of calling into any libraries.
GC> I should have thought of that simple, robust solution up front.

 I don't think it's especially robust. Using compressed files had a
marginal but potentially useful side effect of detecting not just tampering
but any other accidental modification, as a corrupted file would fail to
decompress, while XOR encryption doesn't provide any integrity protection
whatsoever. I do agree that it's simpler, but OTOH the complexity of using
LZMA is completely hidden inside wxLZMAInputStream (for deobfuscation) and
"xz" tool (for obfuscation), so we don't really gain anything at lmi code
level.

 Regards,
VZ