Re: [lmi] Bad md5sum.exe link

[Greg Chicares]

On 2019-05-01 01:36, Vadim Zeitlin wrote:
> On Tue, 30 Apr 2019 00:36:07 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-04-29 23:47, Vadim Zeitlin wrote:
> GC> > On Mon, 29 Apr 2019 23:31:20 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> If we can wrap our existing MD5 or CRC32 code and build a standalone
> GC> > GC> msw binary, that'd be plenty good enough.
> GC> > 
> GC> >  This really shouldn't be difficult to do. And, FWIW, I can volunteer 
> to do
> GC> > it.
> GC> 
> GC> Your offer is gratefully accepted. If you're inclined to use MD5,
[...]
>  Can I leave the choice of whether to stay with MD5 or to switch to some
> modern cryptographic hash to you?

Sure. MD5. We already have the code for it, with some unit tests in
'authenticity_test.cpp'. It's more than strong enough: lmi is installed
on desktops only and doesn't face the web. No one with the skill to
attack MD5's weaknesses would wish to, because there'd be no benefit
worth the trouble; and there are much easier ways to get around lmi's
authentication ("use the source").

> GC> here are some thoughts:
> GC> 
> GC> Examining lmi's 'md5.?pp', I see that only two high-level functions:
> GC>   md5_stream()
> GC>   md5_buffer()
> GC> are called elsewhere, in these files:
> GC>   authenticity.cpp
> 
>  I still don't understand why do we use system_command("md5sum") in this
> file and md5_stream() almost immediately below. This seems so strange that
> I wonder if I'm not missing something.

We use system_command() to invoke 'md5sum --check --status [file-of-md5sums]',
to test a large number of MD5 sums in a file that's part of every distribution.

We use md5_stream() to validate the passkey, which isn't part of the above file.
That means we can extend the expiry date by providing a new passkey, without
changing anything else.

Instead of using system_command(), we could of course have written code to do
everything 'md5sum --check --status [file]' does. It's easier and more robust
to use an available, redistributable binary, which has been extensively tested
by many people over many years.

> GC>   authenticity.hpp
> GC>   authenticity_test.cpp
> GC>   generate_passkey.cpp
> GC> so a library that provides those two function would be sufficient.
> 
>  I actually thought to cheat and make all MD5 code inline, to avoid the
> need for the library. I believe it's not a bad solution, really, as each of
> md5sum.exe, lmi itself and generate_passkey programs would contain just a
> single copy of this code because all of them would use it in one
> translation unit only. The only drawback I see is that it would still need
> to be compiled thrice, but this seems relatively minor compared to adding
> another library to lmi build system.
> 
>  Would you still prefer to have such library?

I hadn't thought of that. It would be much better to have a header-only
implementation. (I don't recall whether there's some one-time initialization
that would make that difficult, but there are known ways to deal with that.)

Building a library means writing makefiles that require maintenance forever.
Header-only libraries don't. So what if rebuilding takes a few milliseconds
longer?

> GC> It would be good to remove 'md5.?pp' from the repository,
> 
>  If we do this, we just ought to use some existing 3rd party crypto library
> providing MD5 (and tons of other things, of course). But I don't believe
> it's worth doing this, unless there are good chances that we'd need any
> other cryptographic algorithms in the future.

Okay, then it should stay in the repository, somewhere. Or the existing
code could be replaced by the unaltered C originals.

> GC> or at least move them to tools/, because they'll never really be
> GC> concinnous with lmi code anyway.
> 
>  "tools" seems a rather strange name for a library... Shouldn't it rather
> go to third_party?

tools/ is a repository subdirectory; third_party/ is not.
tools/ is where PETE resides, and PETE is arguably a library.
Maybe tools/ wasn't the best name to pick, but I don't really
want to force-push a name change. And third_party/ isn't the
best name because it's the same as the name of a directory
that 'install_miscellanea.make' creates, which has nothing
to do with tools/ or PETE.