[Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files

luigi scarso luigi.scarso at gmail.com
Mon Apr 11 20:28:48 CEST 2022


On Mon, Apr 11, 2022 at 5:52 PM Roland Clobus <rclobus at rclobus.nl> wrote:

> Hello Hans, Norbert,
>
> Thanks for your answers.
>
> On 11/04/2022 13:01, Norbert Preining wrote:
> >> it actually defeats one of the security properties of lua (which was
> >> explicitly introduced at some point: make sure that hashes have random
> order
> >> each run so that it's harder to retrieve sensitive data from mem)
> >
> > Well, that is a good point to *not* implement the change.
> >
> > Roland, do you have any comments? I guess the reproducability strive is
> > not as important as security.
>
> Well, reproducibility is *another* aspect of security; this time not for
> the regular environments that users will use, but for build environments.
>
> Reproducibility (as enforced by SOURCE_DATE_EPOCH) is typically enabled
> in an environment that generates binaries from source code for
> redistribution. It will guarantee that the build environment has not
> been tampered with, because you can (if you have made a similar build
> environment yourself) generate the binary files bit-for-bit identical.
> For a regular, production environment you should not have
> SOURCE_DATE_EPOCH set.
>
> Other programming languages also have solved the security risks
> associated with the randomness of the hashes and reproducibility, see
> [1]. For Perl, the hashes can be de-randomized with PERL_HASH_SEED.
> Python uses PYTHONHASHSEED.
> For Lua an environment variable LUA_HASH_SEED could be introduced, or
> per default the value of SOURCE_DATE_EPOCH (if set) instead of
> time(NULL) could be used to seed the hashes.
>
> The texlive-binaries in Debian contain an embedded copy of Lua 5.3. The
> Lua 5.4 version of luai_makeseed is more complex, see [2]. I'll write a
> feature request for Lua later, that is out-of-scope for this scenario.
>
> > So if something in this way should be done, it would need to
> > changes sort order if and only if FORCE_SOURCE_DATE=1 in the env
> > (this is what has required for tex engines to obey SOURCE_DATE_EPOCH
> > settings).
> >
> > Roland, if you have time, please adjust the patch to work within the
> > above constraints.
>
> Ack. Thanks for the pointer to luai_makeseed, that was some missing
> information that I needed. I'll post an updated patch soon (most
> probably much smaller and more elegant). As written above, the hash seed
> will be de-randomized only when both FORCE_SOURCE_DATE=1 and
> SOURCE_DATE_EPOCH are set.
>

I am perplexed,  perhaps I misunderstood something.
The distinction among "the regular environments that users will use" and
the "build environments"
seem to be  done at runtime for the same binary by setting an env. variable
--  but in this case a malicious "regular" user could also  set
LUA_HASH_SEED, breaking the
security property.

In this *specific* case, one can check by sorting -- as done by the patch:

#!/bin/sh
export FORCE_SOURCE_DATE=1
export SOURCE_DATE_EPOCH=$(date +%s)
for i in `seq 1 10`; do
 luahbtex -ini -jobname=luahbtex -progname=luabhtex  luatex.ini
1>/dev/null;
 gunzip -d -c luahbtex.fmt|tail -1 |xxd -i |perl -pe
's{,\s*}{\n}g;s{^\s*}{}g;'|sort|md5sum ;
 md5sum luahbtex.log;
done

because *in this case* two distinct fmt differ only at the last line -- but
perhaps choosing another format (lualatex) could make  more sense.


-- 
luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ntg.nl/pipermail/dev-luatex/attachments/20220411/d3df30f8/attachment-0001.htm>


More information about the dev-luatex mailing list