GNU bug report logs - #45068
[PATCH] 28.0.50; Update Modus themes 1.0.2 (backward-incompatible)

Previous Next

Package: emacs;

Reported by: Protesilaos Stavrou <info <at> protesilaos.com>

Date: Sun, 6 Dec 2020 12:25:02 UTC

Severity: normal

Tags: patch

Fixed in version 28.1

Done: "Basil L. Contovounesios" <contovob <at> tcd.ie>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: info <at> protesilaos.com, eliz <at> gnu.org, 45068 <at> debbugs.gnu.org
Subject: bug#45068: [PATCH] 28.0.50; Update Modus themes 1.0.2 (backward-incompatible)
Date: Tue, 02 Mar 2021 08:56:22 -0300
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> I'll just say that I raised the question because (usually) theme files
>> are just settings, so for a user to check the safety it is normally
>> enough to go through the custom-theme-set-* functions and see what the
>> theme is setting.  Now the user would be asked to check a require-theme
>> call for its safety, and since a call to require-theme looks a lot like
>> require, it might not be obvious that it can load (and enable) any theme
>> it wants.
>
> I'm suggesting that require-theme never enables any themes.  And to the
> eyes of the user, it would be no different than a call to require or
> load, which we already don't warn a second time about.

Then there's no reason for me to worry at all.

>> And if a theme uses require-theme to do that, it can "hide"
>> the "unsafe theme" settings, because the first element of
>> custom-enabled-themes will just be the "safe" theme.
>
> Sorry, I'm not sure what you mean, could you please elaborate on the
> steps involved?

With the require-theme posted that included a (load-theme t) call, I
thought about the following steps:

The user enables super-safe-theme which hasn't been marked as safe.
The theme has a call to require-theme:
(require-theme 'should-be-safe-theme)
and the user thinks it's fine because should-be-safe-theme comes from
the same author as super-safe-theme.  The user doesn't check
should-be-safe-theme.el (shame on him), and is neither prompted because
of the NO-CONFIRM non-nil.

should-be-safe-theme.el has this call:
(require-theme 'not-so-safe-theme)
and the user is again not prompted for this theme.

After all the loading and enabling, custom-enabled-themes looks like
this:
(super-safe should-be-safe not-so-safe)
and it's not entirely obvious which setting came from which theme.

Of course all of this is already possible, but the theme has to put a
(load-theme t) call in front of the user eyes.

But anyway, if you're thinking about a require-theme that never enables
any theme, this is not relevant anymore.




This bug report was last modified 4 years and 138 days ago.

Previous Next


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