Page MenuHome GnuPG

Kleopatra: Use windows registry additionally to config files
Open, NormalPublic

Description

We make use of the Windows Registry to set cofiguration values for Kleopatra. https://gnupg.com/vsd/kleopatra-settings.html

For that we use the following patch:
https://invent.kde.org/frameworks/kconfig/-/merge_requests/146

That patch is a bit stupid, it should use QSettings instead of manually reading the registry. But the biggest issue I have with it is that it is not generic enough. It only works for kleopatrarc but not for something like kleopatragroupsrc or libkleopatrarc etc.

But still in general it is ok. The order should be:

  1. Read values from XDG_SYSTEM_DIRS
  2. Read from HKLM registry
  3. Read from HKCU registry
  4. Read from XFDG_CONFIG_DIRS

And write only to the local XDG_CONFIG_DIRS stuff.

We need it to be configurable where the "root" key is. Currently we set it this way:

diff --git a/src/kleopatraapplication.cpp b/src/kleopatraapplication.cpp
index 0528076b..d4cb93ac 100644
--- a/src/kleopatraapplication.cpp
+++ b/src/kleopatraapplication.cpp
@@ -299,6 +299,7 @@ void KleopatraApplication::init()
 {
 #ifdef Q_OS_WIN
     QWindowsWindowFunctions::setWindowActivationBehavior(QWindowsWindowFunctions::AlwaysActivateWindow);
+    KConfig::setWindowsRegistryKey(QStringLiteral("SOFTWARE\\GNU\\Kleopatra"));
 #endif
     const auto blockedUrlSchemes = Settings{}.blockedUrlSchemes();
     for (const auto &scheme : blockedUrlSchemes) {

Better would be e.g. an API where it uses organization name by default and a way to override that so that it works for us. It must be compatible with the current registry settings we have as linkled above.

Event Timeline

aheinecke created this task.
aheinecke renamed this task from Kleopatra: Evaluate registry settings to Kleopatra: Use windows registry additionally to config files.Feb 8 2024, 9:23 AM
aheinecke reassigned this task from aheinecke to TobiasFella.
aheinecke updated the task description. (Show Details)
TobiasFella moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Feb 15 2024, 8:59 AM
TobiasFella changed the task status from Open to Testing.Oct 1 2025, 3:07 PM
ebo edited projects, added vsd33; removed Restricted Project.Oct 1 2025, 3:13 PM
ebo added a subscriber: ebo.

As this was finished more than a year ago, this should be included (and testable) in vsd

timegrid changed the task status from Testing to Open.Fri, Oct 31, 11:02 AM
timegrid moved this task from QA to WiP on the vsd33 board.
timegrid added a subscriber: timegrid.

The configuration readout order still needs to be specified/fixed.

  • The description says, it should be:
    1. XDG_SYSTEM_DIRS
    2. HKLM
    3. HKCU
    4. XDG_CONFIG_DIRS
  • The current implementation is:
    1. HKLM
    2. HKCU
    3. XDG_SYSTEM_DIRS
    4. XDG_CONFIG_DIRS

The current (vsd3.3.3-beta90.29) XDG_SYSTEM_DIRS/kleopatrarc contains:

[KDE Action Restrictions][$i]
action/help_contents=false
action/help_check_updates=false
action/help_about_kde=false

[UpdateNotification][$i]
NeverShow=true

[Smartcard]
AlwaysSearchCardOnKeyserver=true
[General]
ProfilesDisabled=true

Questions:

  • Should settings in XDG_SYSTEM_DIRS (ours) override HKLM (admins)?
  • Should immutable values in XDG_SYSTEM_DIRS (ours) be overridable by HKLM (admins)?

And we shouldn't change the precedence in a minor release, I believe.

Though as the changes made seem all to be from 2022 this should be included since vsd 3.1.26. or were there commits in 2024 which were not attached to the ticket? @TobiasFella please clarify if and - if applicable - since when the changes are "live".

I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is

  1. HKLM
  2. HKCU
  3. XDG_SYSTEM_DIRS
  4. XDG_CONFIG_DIRS

Note: In vsd 3.3.2 there is no XDG_SYSTEM_DIRS/kleopatrarc file

So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.

The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?

Yes, by definition an immutable group doesn't allow any changes for that group. Don't mark a group as immutable if you want to allow changes.

  • Should immutable values in XDG_SYSTEM_DIRS (ours) be overridable by HKLM (admins)?

Certainly not. Immutable means immutable and not immutable except if... . If admins need to override settings in XDG_SYSTEM_DIRS then the settings in XDG_SYSTEM_DIRS shouldn't be present in the custom installer for those admins in the first place.

So this means, the order in the description should be implemented, right?

  1. XDG_SYSTEM_DIRS
  2. HKLM
  3. HKCU
  4. XDG_CONFIG_DIRS

And we need to check, if the [KDE Action Restrictions][$i] is intended or not.