VOOZH about

URL: https://dev.gnupg.org/T4788

⇱ ⚓ T4788 System wide configuration of the GnuPG system


Maniphest T4788

System wide configuration of the GnuPG system
Closed, ResolvedPublic

Description

I think there must be an issue about this already but I could not find it.

My most important wish for a "professional" Gpg4win product is that it should be easier to deploy a configuration of GnuPG. For Example the compliance de-vs option. Currently our institutional deployment runs a login script for this.

Kleopatra uses the library KConfig to have a very nice configuration interface.
https://userbase.kde.org/KDE_System_Administration/Kiosk/Introduction

For GnuPG my proposal is:

  1. Read config from /etc/gnupg/

-> No new magic please like the profiles and all that stuff. Just read a "gpg.conf" "gpg-agent.conf" etc. from that location. Treat it as normal config files.

  1. Afterwards read the config from the GnuPG home dir.

If an option in the system wide configuration is marked with a "=" sign or something like that at the beginning of the line treat it as immutable. Otherwise prefer the user option.

E.g. if =enable-crl-checks is in the system wide config a "disable-crl-checks" should be ignored in the user config. Without an equal sign CRL checks should be disabled because the user has explicitly set it.

I'm mostly interested in Windows for this.

Revisions and Commits

rG GnuPG
rG7a3a1ef37071 gpgconf: Rewrite the gpgconf-comp module.
rGa028f24136a0 Backport of the new option parser from 2.3
rG451cd1b39281 gpgconf: Further simplify the gpgconf option processing.
rGb4f1159a5bd7 gpgconf: Rewrite the gpgconf-comp module.
rG833c04334a53 Use gpgrt's new option parser for the new keyboxd.
rG941a48f9b12b agent,dirmngr: Re-read the user specified config file.
rGba463128ce65 Use gpgrt's new option parser for the remaining daemons.
rG3bc004decd28 Use gpgrt's new option parser for the tools.
rG2c823bd878fc Use gpgrt's new option parser for gpgc, gpgsm, and gpg-agent.
rG0e8f6e2aa98c gpg: Use gpgrt's new option parser to provide a global conf file.
rE libgpg-error
rE2d1969ab465b core: Implement meta commands for the argparser.
rE2f169b341e41 core: Add meta command handler stubs to argparse.c.
rE9d268891dae6 core: Prepare argparse.c to track additional info for options.
rE6fc2d7cb8ce9 core: Add parser for meta commands to gpgrt_argparser.
rE933eb9346a84 core: Add a high level option/argument parser.

Event Timeline

werner raised the priority of this task from Wishlist to High.Dec 20 2019, 12:24 PM
Comment Actions

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

werner changed the task status from Open to Testing.Feb 27 2020, 2:58 PM
Comment Actions

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Example usage in gpg.conf

[force]
compliance de-vs
encrypt-to 0x12345678
[-force]
[ignore]
no-encrypt-to

Which enforces the use of a compliance option and makes sure that all encrypted data is also encrypted to the given key. The ignore meta command is then used to ignore any use of --no-encrypt-to in config files and the command line.

Comment Actions

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

I wanted this badly as a distributor.

werner changed the task status from Testing to Open.Feb 28 2020, 2:40 PM
Comment Actions

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

Comment Actions

i'd be unlikely to ship anything as or just because of the mess that admins have to deal with when shipped config files change.

But i agree that some sysadmins who use debian might find this feature super useful, and i'd be happy to advertise it in the debian file when it lands in a version that we can distribute.

werner changed the task status from Open to Testing.Mar 12 2020, 10:36 AM
Comment Actions

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

This comment was removed by werner.