Re: [lmi] Do we have zlib already?

[Greg Chicares]

On 2016-06-09 20:45, Vadim Zeitlin wrote:
> On Thu, 9 Jun 2016 20:24:47 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I just built wx, and I see:
> GC> |  Which libraries should wxWidgets use?
> GC> ...
> GC> |    zlib               sys
> GC> Does that mean we already have zlib?
> 
>  Yes, it's included in MinGW-w64 distribution and so will be detected and
> used by configure unless --with-zlib=builtin (or --without-zlib, of course)
> option is used.

Then I should make sure we include it in lmi's installation
procedures, if we decide to use it.

> GC> Here's why I ask. We've been distributing product files as plain
> GC> xml. They contain proprietary product data (no personal data),
> GC> with an appropriate notice at the top, and they're distributed
> GC> only under nondisclosure agreements. Now at least one person has
> GC> suggested that it would be even better if they weren't readily
> GC> human-readable, so I was thinking that compressing them with
> GC> zlib might be a good idea. AFAICT, libxml2 and thus xmlwrapp use
> GC> zlib transparently if it's available. And if we already have
> GC> zlib (e.g. because wx knows how to build it), this might be an
> GC> easy enhancement.
> 
>  Yes, I don't have any conscious experience with using libxml2 with zlib
> (maybe I did use them both together, but then it happened without me
> realizing it), but it's supposed to work without any extra effort on our
> part, except for configuring libxml2 to use zlib. So it could be as simple
> as just removing --without-zlib option from install_libxml2_libxslt.make.
> Notice, however, that libxml2 would embed its own version of zlib.a from
> MinGW-w64 distribution, there is no way to reuse the version already linked
> into wxWidgets currently (even though we keep being asked about it) and, in
> fact, we could even have a conflict between the two if we link everything
> statically. OTOH as long as these two versions are completely identical,
> it's probably not going to result in any problems -- but still something to
> think of. Anyhow, should I try doing this?

Yes, please.

BTW, lmi's install-the-universe script does fetch it:

/MinGW_[0]$ls -l **/libz*

-rw-r--r-- 1 earl None 112904 Oct 30  2014 i686-w64-mingw32/lib/libz.a

-rw-r--r-- 1 earl None 120194 Oct 30  2014 i686-w64-mingw32/lib64/libz.a


and for now obviously we want the one that's not in 'lib64'.

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

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

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

Yet zlib is gzip, not the "zip" format built into msw, so would this
obfuscation be transparent to a naive msw user?

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

AIUI, that would require a surgical operation on xmlwrapp at least.
Or lmi would have to interpose an encryption layer between itself
and xmlwrapp, which would be worse. At least that's the impression
I got from quickly browsing the code. OTOH, since zlib is already
built into the lowest level, libxml2, that makes everything easy.

>  Please let me know if I should look at either (or both) compression or
> (and) encryption and the priority of this compared to the other outstanding
> tasks.

This has a lower priority. But it might still save us time: right
now, we're using real encryption on distributions because someone
raised this concern, and with this change maybe we wouldn't have
to do that. That would mean less work for us and less hassle for
brokers.