Re: [lmi] Bad md5sum.exe link

[Vadim Zeitlin]

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,

 I'm not sure about this one. On one hand, we already have the code for MD5
and we don't (AFAIK) have the code for any other hash. And while code for
many much better, cryptographically speaking, hash functions such as bcrypt
or argon2, is also readily available in the public domain, it is more
complex and we don't really need any industrial-grade hashing here. OTOH
using MD5 in 2019 does feel a bit dirty...

 Can I leave the choice of whether to stay with MD5 or to switch to some
modern cryptographic hash to you? At least, if you decide to use something
else, I could choose which particular hash function to pick myself...

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.

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?

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.

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?


 I realize that this is not the most urgent thing to do, but it would be
great to have your input about the questions above (MD5 or not; inline code
or library; tools or third_party) as I'm afraid I can't really make these
choices myself.

 Thanks in advance,
VZ