GNU bug report logs - #75017
31.0.50; Untrusted user lisp files

Previous Next

Full log

View this message in rfc822 format

From: john muhl <jm <at> pub.pink>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75017 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#75017: 31.0.50; Untrusted user lisp files
Date: Mon, 23 Dec 2024 11:53:38 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: john muhl <jm <at> pub.pink>
>> Cc: 75017 <at> debbugs.gnu.org
>> Date: Sun, 22 Dec 2024 18:32:00 -0600
>> 
>> Specifically, I was surprised to find that user-init-file is
>> assumed safe but not early-init-file. After reading the
>> trusted-content part of the manual where it says “…which means no
>> file is trusted.” I assumed that included user-init-file. When I
>> saw that wasn’t the case I then assumed early-init-file would get
>> the same treatment. Maybe a little extra clarity there would be
>> sufficient for now.
>
> Maybe we should trust the early-init-file as well, but then where does
> this end?  The init files can load gobs of other files.  And there's
> also custom-file (when it isn't nil), desktop-dirname and
> desktop-base-file-name, etc. etc.

For Emacs 30 I’d end it with user-init-file, early-init-file and
custom-file. The latter is already an implicit part of trusting of
the user-init-file so it shouldn’t add any additional risk. The
former two are I think in the same category of presumed safeness
so distinguishing one as trusted and the other not seems odd.

Longer term I agree with you that more experience will lead to
better understanding of where to draw the line.

Previous Next

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