Page MenuHome GnuPG

Kleopatra: Do not offer deprecated gpg/keyserver option in GnuPG System configuration dialog
Closed, ResolvedPublic

Description

Kleopatra shall not offer gpg's deprecated keyserver option in the GnuPG System configuration dialog (see T5462: gpgconf: Make gpg/keyserver option available again).

Old description (changed following discussion in this task):

Several options listed by gpgconf --list-options have expert level invisible which means "This option should normally never be displayed, not even to expert users."

Kleopatra currently lists all options (except in de-vs compliance mode). I think Kleopatra shouldn't offer invisible options in its configuration dialog, e.g. it shouldn't list gpg's deprecated keyserver option (see T5462: gpgconf: Make gpg/keyserver option available again.)

Event Timeline

FWIW, GPA has a setting where you can select at which level options are shown (but not invisible). IIRC we had the same in Kleopatra but it has been removed.

:-) I thought about such a setting, but at first I want to exclude invisible options from Kleopatra's UI.

I had explicitly added these options because for me the whole "GnuPG System" is an expert level configuration. I would rather move the very important options like the agent timeout settings out of this and then maybe show an info when the user first selects those settings that changing options here could lead to errors in operation.

To be honest I have added them because of disagreement what is expert setting and what is not. Ideally I would like to see all gnupg options listed because editing config files is not really something that is good for support. And there are some settings in the "invisible" part that are important for users. Of course, stuff like "faked-system-time" I would also say, that could be hidden. But "auto-key-retrieve" "trust-model" "completes-needed" "marginals-needed" I think they are arguably important.

And please do not use some "advanced" or "expert" mode, this is something that I was explicitly told in an UI workshop that such things are very bad design and I agree with that because users cannot decide this and it is just confusing the UI.

Okay, but then we need a new level for those options that really must not be shown in a UI, but that still need to be accessible via gpgconf. In fact, there is the level "internal" which does not yet seem to be used for any options, but that seems suitable at least for the deprecated gpg/keyserver option.

Regarding modes, I know that, in general, modes are a bad thing from a UX perspective. But I'm not sure that this applies in that generality to configuration dialogs. I have seen some examples of configuration dialogs which hide expert options unless one enables them. Another possibility is to put all expert options on a separate page/tab together with a warning at the top. Moreover, I think there is a huge difference between corporate users and normal users. I'm pretty sure that most corporate admins would prefer that their users cannot change a single config option because each option that their users can fiddle around with will cause a support issue.

Okay, but then we need a new level for those options that really must not be shown in a UI, but that still need to be accessible via gpgconf. In fact, there is the level "internal" which does not yet seem to be used for any options, but that seems suitable at least for the deprecated gpg/keyserver option.

I think this is something to rather hardcode / filter this on Kleopatras side. Because Kleopatra knows "I have already handled keyserver differently in my current version, so I should hide that option". And GnuPG does not know this.

Regarding modes, I know that, in general, modes are a bad thing from a UX perspective. But I'm not sure that this applies in that generality to configuration dialogs. I have seen some examples of configuration dialogs which hide expert options unless one enables them. Another possibility is to put all expert options on a separate page/tab together with a warning at the top.

Yes, for me this is already the GnuPG-System page, I think this is mostly useful for support. E.g. to set debug logging.

Moreover, I think there is a huge difference between corporate users and normal users. I'm pretty sure that most corporate admins would prefer that their users cannot change a single config option because each option that their users can fiddle around with will cause a support issue.

Yes, we have two possibilities here. Using "NoDisplay=true" in the kleopatra_config_gnupgsystem.desktop to just hide the GnuPG-System settings.

And in general to set "action/options_configure=false" to hide all configuration.

Regarding the level "internal" I just remembered that gpgconf doesn't list "internal" options. Given that didn't find any internal options that could probably be changed. Or we add yet another level. Or, all invisible options, that shall be offered to users are promoted (or demoted?) from "invisible" to "expert" level.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

Please no new levels. And also consider the problems with global config files, conditionals and values taking from the registry. We can't simply do everything in the GUI - it would get too complex and we end up supporting the supportive config dialogs. Maybe a syntax checking editor would eventually be better.

FWIW, To help with support, I added a "gpgconf --show-configs" just today.

ikloecker renamed this task from Kleopatra: Do not offer "invisible" options in GnuPG System configuration dialog to Kleopatra: Do not offer deprecated gpg/keyserver option in GnuPG System configuration dialog.Nov 8 2021, 9:41 AM
ikloecker changed the task status from Open to Testing.
ikloecker updated the task description. (Show Details)
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ebo claimed this task.
ebo added a subscriber: ebo.

Keyserver option is no longer shown in the OpenPGP tab of GnuPG System

ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 5 2023, 2:58 PM