GNU bug report logs - #78340
[PATCH] New option for comp *.eln file name by the file timestamp of *.el

Previous Next

Full log

Message #56 received at 78340 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: sunlin7 <at> hotmail.com, acorallo <at> gnu.org, 78340 <at> debbugs.gnu.org
Subject: Re: bug#78340: [PATCH] New option for comp *.eln file name by the
 file timestamp of *.el
Date: Mon, 12 May 2025 19:13:55 +0300

> From: Lynn Winebarger <owinebar <at> gmail.com>
> Date: Mon, 12 May 2025 11:37:13 -0400
> Cc: acorallo <at> gnu.org, sunlin7 <at> hotmail.com, 78340 <at> debbugs.gnu.org
> 
> There's nothing there saying the check is to make sure that the code in the .eln is safe, only that the eln
> filename is unique when a library is recompiled with different source.  There's nothing that implies that it
> would be *unsafe* to load a library generated from a version with a different content hash than the one that
> happens to exist on disk at the moment.  A compile-time time stamp would probably be adequate for the
> stated purpose of ensuring a unqiue file name.

So now you are saying that what we do is NOT enough, and more should
be done to make sure the loaded .eln file is safe?

Or are you saying that, because (in your opinion) the current tests
are not enough, we could well throw them away completely, because it
will save us some milliseconds per file?

Or what is it that you are saying?

Whatever you claim about the current code, it withstood the test of 2
major Emacs releases: I've yet top hear any report about Emacs
crashing because it loaded an incompatible .eln file.  That's not
nothing.

> I don't see anything in comp.c storing the content hash in the .eln file for verification purposes.  It looks like
> if I modify an elisp library, then copy the existing .eln to have a filename with the content hash from the new
> version, but without any modification of the eln contents, it should load the same way the older byte-compiled
> version would.  Are you (or Andrea) saying that would risk a crash?  
> Am I missing something?

Maliciously tampering with files can still crash Emacs, yes.  That's
not what those safeguards are about.

>  So it is not clear to me that this complication (which will as a side
>  effect make the .elc files incompatible with previous Emacs versions)
>  is justified.  Someone will have to show a significant speedup to make
>  it worth considering.
> 
> I didn't suggest reading the whole file, only the leading comment block. If the performance impact is from
> reading a single block of a file, the you're right.  I thought the issue was having to do a computation linear in
> the size of the file.

Not on Windows, at least that's not my guess.  The CPU processing
power is the same on Windows as on other systems, but I/O is slower.
Opening a file and reading some of it is slower.

Of course, this is just a guess, and someone needs to measure this.

> If the only purpose of the content hash is to certify that some valid elisp source (with respect to the running
> emacs) is known to exist, then emacs should be able to keep a table in memory loaded at startup and just
> consult that for verification.  That should address any concern about crashing, at least, unless I have
> completely misunderstood the concern about (which is very possible).

You lost me here.  What would be the contents of that table, how it
will be produced, and how it will be used?

And, btw, what does all that have to do with the current bug, which is
very specific and narrow?  It sounds like you'd like to start a
discussion on emacs-devel where you would like to suggest how to
redesign the way we validate and load *.eln files.  It's a separate
discussion with much broader scope and implications.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.