GNU bug report logs - #74879
30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 15 Dec 2024 00:40:02 UTC

Severity: normal

Found in version 30.0.92

Full log


View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers
Date: Sat, 11 Jan 2025 13:39:32 +0100
Stefan Kangas <stefankangas <at> gmail.com> writes:

>> 3. Installation of packages is confirmed via package.el and does not
>> happen without user consent.
>
> Yes, it is "not our fault" because "you shouldn't have done that" and so
> on.  However, whether or not we are technically at fault, we should
> still work to make Emacs safer to use, IMO.

As I argued, using bwrap for package compilation will not yield
additional security benefits, since this will only push the confirmation
slightly to the future, to the time when the package is loaded.
Confirmation should happen as early as possible and as soon as the
confirmation is given, the package is trusted. When confirming, a
reasonable amount of information should be shown, e.g., a diff, if the
user has requested that such that they can evaluate if they indeed trust
the package.

I think it is not a good idea to have some packages in the elpa/
directory which are marked as trusted and some packages in the directory
which are not trusted. I only want to have trusted packages there and
nothing else. This means that trusting the packages has to happen before
installation.

>> As soon as the user agrees to install a package, they agree that the
>> package will shortly become part of the `load-path', and that its code
>> will be executed shortly. If we believe that package installation is not
>> safe enough, additional louder confirmations and warnings could be
>> added: When adding new archives (additional validation of
>> `package-archives') and second and when installing or upgrading
>> packages. For example `package-upgrade-all' tells me how many packages
>> it wants to upgrade but not even which packages - I really want to
>> inspect the list of upgradeable packages first.
>
> Good ideas, thanks.  Feel free to submit feature requests.

Thanks. I have already submitted some of them. Most of them are
relatively small issues to improve.

>> Which additional benefits do you see if ELPA packages are compiled
>> inside bwrap? The trust will only be pushed a little to the future.
>
> Consider packages that are used very rarely.  I'd prefer to have
> `php-mode' installed, but I can't even remember the last time I had to
> look at a PHP file.  It could be more than 10 years ago.

I see your point. Like you, I probably have not opened certain file
types in years, but I have the modes around. So what do you envision?
You want to confirm package loading for rarely loaded packages? You want
to have an additional confirmation step for rarely loaded packages or
for all packages? My argument is that the `php-mode' you have installed
is considered to be safe, since you trusted it back then. Hopefully you
have checked it carefully back then and installed it from a source you
trust.

The situation is different when upgrading the package. Then I argue that
additional confirmation is needed and more information should be shown
*before* the upgrade, e.g., the diff. But as soon as the upgrade is
confirmed, the package should be trusted, since it may get loaded.

Daniel




This bug report was last modified 55 days ago.

Previous Next


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