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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: acorallo <at> gnu.org, jm <at> pub.pink, monnier <at> iro.umontreal.ca, 75017 <at> debbugs.gnu.org
Subject: bug#75017: 31.0.50; Untrusted user lisp files
Date: Mon, 23 Dec 2024 16:29:25 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 23 Dec 2024 14:10:30 +0000
> Cc: monnier <at> iro.umontreal.ca, jm <at> pub.pink, 75017 <at> debbugs.gnu.org, 
> 	acorallo <at> gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So if such a file somehow materializes there, I want to know, pronto.
> 
> First, I note that it's likely already game over if an attacker can
> write to `site-init-file`, because they can then just as easily write to
> your init file (or other relevant files in `load-path`) instead.
> 
> But to do what you suggest, we would need to start with deciding under
> what circumstances it is not expected to find a file in this location,
> and then not just warn but refuse to load it if it meets that criteria.
> I don't know how to design such criteria.
> 
> If we can figure out a way to do that, then I agree that it would be
> consistent not to treat this file as `trusted-content-p`, when it exists
> unexpectedly.

I think this is over-engineering.  Yes, there are situations where it
makes sense to trust site-init-file.  No, they are not 100% of the
possible situations.  Which in my book means we should leave it to
users to decide whether to trust that file or not.

Previous Next

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