Re: [lmi] Measuring MD5 overhead

[Vadim Zeitlin]

On Tue, 7 Apr 2020 15:16:20 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2020-04-06 18:19, Vadim Zeitlin wrote:
[...]
GC> >  Do we need to do it in order to immediately detect any tampering or
GC> > corruption? Or was this just the simplest way to do it and we wouldn't 
lose
GC> > anything if we postpone validating them until their first use?
GC> 
GC> The original code was just simplest way to use an external program
GC> for MD5 validation. I.e., we didn't want to parse out individual
GC> lines in 'validated.md5' and then shell out to some MD5 '.exe' to
GC> validate files piecemeal at various times.
GC> 
GC> As for the actuarial tables in 'tables.*': End users would find it
GC> infeasible to modify those files, but they could copy over older
GC> versions--so these files do need to be validated. And lmi can't
GC> really do anything without accessing these files, so validating
GC> them on startup is good enough--I see no good reason to delay that
GC> until they're first used.

 I think speeding up the program startup is a very good reason. It makes an
excellent impression if the program launches immediately and, on the
contrary, a bad one if it takes a long time to appear. Without doing any
measures, I'd say that IME lmi startup time is middling, i.e. it doesn't
seem especially slow, but it doesn't appear on the screen as immediately as
I'd like/expect it to neither, so IMO it would be worth improving this.

 Again, if we really need to do the validation on startup, we can still do
it, but it would be better to do it in a background thread. Once its
results are available, the main thread could show an error message and
exit, but in normal case the main thread would be free to show its window
as fast as possible while the validation would happily succeed in the
background.

GC> > GC>  - 'whatever_product.{database,funds,policy,rounding,strata}, which 
most
GC> > GC>    end users can modify using the product editor;
GC> > 
GC> >  Sorry, but it's my day of stupid questions today: if they can be 
modified,
GC> > how does it work with the existing validation schema? AFAICS, wrap_fardel
GC> > target includes all these files in validated.md5, so changing them would
GC> > result in a validation failure during the next run. What am I missing?
GC> 
GC> Today, end users can do this:
GC>  - start lmi (thus validating all files)
GC>  - use the product editor (or a text editor) to modify some product
GC>  - produce PDF illustrations using that modified product
GC> because files are validated only at startup. That's the reason for
GC> this comment:
GC> 
GC>   // TODO ?? Known security hole: data files can be modified after they
GC>   // have been validated.
GC> 
GC> A validation error would subsequently occur, true; but it would occur
GC> only after exiting and restarting lmi. Thus, we address the validation
GC> with a very large hammer, with which we don't strike at the ideal time.

 Sorry, I just can't wrap my head around this. So people who do need to
modify some product have to do it every time when running lmi and then undo
their changes to prevent their modifications from resulting in an error
when lmi runs the next time? And what happens if they forget to revert the
changes, do they lose the ability to run lmi at all until the next month?

 This is not really important, of course, as it doesn't really change
anything about the conclusion of your previous message, but I just don't
understand why you don't seem to see the above scenario as a huge problem.

 Regards,
VZ

pgpCqUJdx7Ogi.pgp
Description: PGP signature