Re: [lmi] Do we have zlib already?

[Vadim Zeitlin]

On Thu, 9 Jun 2016 21:39:29 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-09 20:45, Vadim Zeitlin wrote:
...
GC> > GC> so I was thinking that compressing them with
GC> > GC> zlib might be a good idea. AFAICT, libxml2 and thus xmlwrapp use
GC> > GC> zlib transparently if it's available. And if we already have
GC> > GC> zlib (e.g. because wx knows how to build it), this might be an
GC> > GC> easy enhancement.
...
GC> > Anyhow, should I try doing this?
GC> 
GC> Yes, please.

 I've added it near (but not quite at) the top of my TODO list.

GC> BTW, lmi's install-the-universe script does fetch it:
GC> 
GC> /MinGW_[0]$ls -l **/libz*
GC> 
GC> -rw-r--r-- 1 earl None 112904 Oct 30  2014 i686-w64-mingw32/lib/libz.a
GC> 
GC> -rw-r--r-- 1 earl None 120194 Oct 30  2014 i686-w64-mingw32/lib64/libz.a

 I'm almost certain these files are part of standard MinGW installation,
i.e. nothing special needs to be done to fetch them.

GC> I wonder why they distribute only a static library. (I tried
GC>   /MinGW_[0]$ls **/zlib*
GC> as well, but found no DLL.)

 I don't know neither. Curiously, the corresponding Debian package does
have the DLL (only), see
https://packages.debian.org/stretch/all/libz-mingw-w64/filelist

GC> If there's any possibility of a conflict, should we continue to disable
GC> zlib in wx, and use the toolchain's static library with libxml2?

 We could do this, but let me please check if anything untoward really
happens first. As I wrote earlier today, I prefer to use as standard build
of wxWidgets as possible.

GC> >  OTOH I also wonder if compressing files with zlib is really any different
GC> > from keeping them as plain text. I realize that you're not looking for a
GC> > three-letter-agency-proof solution, but plenty of programs have 
transparent
GC> > support for zlib/zip compression, so the end user might not even notice
GC> > that the file is obfuscated if it still opens as plain text when double
GC> > clicked.
GC> 
GC> Yet zlib is gzip, not the "zip" format built into msw, so would this
GC> obfuscation be transparent to a naive msw user?

 In the both the file manager I use under MSW (Total Commander) and Cygwin
shell (with zless script), it would. I realize neither are really standard
and likely to be used by naïve users, but zlib compression is, although not
quite as ubiquitous as zip, still very commonly supported and I wouldn't be
surprised if it could be opened by whatever tools the users do have.

GC> > Perhaps it would be better to use real encryption? Even if the
GC> > encryption key could always be extracted from lmi binary, an AES-encrypted
GC> > ZIP file is not just going to open on its own when double-clicked...
GC> 
GC> AIUI, that would require a surgical operation on xmlwrapp at least.

 No, I don't think it would be appropriate to add encryption support to
xmlwrapp, it would need to be done on lmi level by reading the file,
decrypting it and then passing it to xmlwrapp (and down to libxml2). So
yes, it's obviously not as transparent as simple compression. But it would
provide at least some security which wouldn't be completely trivial to
bypass (although still simple enough for anyone knowing to use a
disassembler and/or debugger).

GC> >  Please let me know if I should look at either (or both) compression or
GC> > (and) encryption and the priority of this compared to the other 
outstanding
GC> > tasks.
GC> 
GC> This has a lower priority. But it might still save us time: right
GC> now, we're using real encryption on distributions because someone
GC> raised this concern, and with this change maybe we wouldn't have
GC> to do that. That would mean less work for us and less hassle for
GC> brokers.

 Hmm, you'll know better, of course, but replacing real encryption with
compression doesn't look like a step in the right direction to me.

 But I'll check if we can do this easily and will let you know about the
results,
VZ