Re: [lmi] Measuring MD5 overhead

[Greg Chicares]

On 2020-04-07 15:28, Vadim Zeitlin wrote:
> 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> 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.
[...]
>  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.

Agreed. And if we use the 'cache_file_reads' for all data files, then we
might read them all at startup time, in a background thread: then startup
feels faster, and subsequent operations that use those files are faster too.

> GC>   // TODO ?? Known security hole: data files can be modified after they
> GC>   // have been validated.

[...snip attempted explanation...]

>  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

Yes. Being able to modify products is enormously empowering, but not
at all convenient. OTOH, preventing unauthorized end users from messing
with anything is good "governance": a proper and necessary exercise of
corporate control, much like using tamper-resistant screws on sensitive
and dangerous machinery.

> 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?

In practice, they would just reinstall lmi afresh, thereby discarding
their modifications.

>  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.

It is a huge problem, but only for users who actually modify products,
and they are very few these days.