Apply Legacy GnuPG Defaults to Existing User Homes Safely

applygnupgdefaults pushes the legacy GnuPG defaults file out to existing users, and it is not a permanent enforcement mechanism. Treat it as a controlled, one-off write to other people's configuration, not something you run on a whim. These examples use GnuPG 2.4.4 from the installed gnupg-utils package, version 2.4.4-2ubuntu17.6.

Allow about fifteen minutes, plus a maintenance window if several users or services rely on GnuPG. You need a root shell, a readable copy of the policy you intend to use, and a list of affected users. Do not run the wrapper casually: it writes configuration files inside multiple users' GnuPG home directories.

1. Confirm the installed command

Start with read-only checks. None of these need elevated privileges unless your system locks down the binary or package database:

$ command -v applygnupgdefaults
/usr/sbin/applygnupgdefaults
$ dpkg-query -W -f='${Package} ${Version}\n' gnupg-utils
gnupg-utils 2.4.4-2ubuntu17.6

The local manual is honest about what this is: a legacy script, a wrapper around gpgconf --apply-defaults, run for every real user who already has a GnuPG home directory. It is not a general GnuPG initialisation command, and it will not create a home directory for anyone.

2. Understand what policy file the wrapper consumes

The wrapper hands the apply-defaults operation to gpgconf, which reads values from the global configuration file, normally /etc/gnupg/gpgconf.conf, and writes them into user configuration files. This is a legacy mechanism; modern applications should use the per-component global configuration files under /etc/gnupg/ instead.

Inspect the file as root first, without applying anything:

# ls -l /etc/gnupg/gpgconf.conf
# gpgconf --check-config /etc/gnupg/gpgconf.conf
# gpgconf --list-config /etc/gnupg/gpgconf.conf

A clean syntax check normally produces no output and returns status 0. The listing is colon-separated data, so do not edit it as if it were a shell script. If the file is missing, empty, or not the one your change process actually approved, stop here: the apply command is not a dry run, and its manual documents no preview mode.

Do not mix gpgconf.conf with the modern per-component global files without a deliberate migration plan. The local gpgconf manual advises against using both, and two policy mechanisms make it much harder to explain a user's final configuration later.

3. Record the users and homes in scope

The wrapper's scope is narrower than "every account": it only touches real users with an existing GnuPG home directory. Accounts without one are not turned into GnuPG users by this command.

Before you change anything, write a change record with the policy file checksum, the maintenance time, and the accounts you expect to be affected:

# sha256sum /etc/gnupg/gpgconf.conf
# getent passwd | awk -F: '$3 >= 1000 && $7 !~ /(nologin|false)$/ {print $1}'
# find /home -maxdepth 2 -type d -name .gnupg -print

That account query is a review aid, not the wrapper's authoritative selection logic. User homes can live outside /home, and a numeric UID range is specific to your site. Check your directory service, home layout and backups before trusting the list.

4. Protect the current configuration before applying

Do not copy private keys into a shared or world-readable backup location. Preserve ownership and permissions, and restrict access to administrators authorised to handle those homes. If your backup process cannot preserve those properties, use a tested system backup instead of improvising a tar archive.

There is no universal undo in applygnupgdefaults. Recovery means restoring the affected configuration files from backup, with their original owner and mode, then checking the relevant GnuPG component. Keep the policy file too; the next run will just reproduce its values.

5. Apply the defaults during the maintenance window

Only root should run the wrapper, since it has to act on other users' homes:

# /usr/sbin/applygnupgdefaults
# printf 'applygnupgdefaults status: %s\n' "$?"
applygnupgdefaults status: 0

The command's synopsis has no documented options and takes no per-user argument, so do not append a username expecting to limit the run. A zero status means the wrapper completed successfully: it does not mean every account had a home, every intended option was accepted, or that a user cannot later edit the file it just wrote.

GnuPG configuration changes can ripple into agents, clients and automation. Avoid running this while users are actively changing their own GnuPG settings: the gpgconf manual warns that concurrent access is not fully locked, so coordinate with anything else that might write the same files.

6. Verify the result without assuming enforcement

Recheck the policy syntax, then inspect a representative user's configuration after the run:

# gpgconf --check-config /etc/gnupg/gpgconf.conf
# stat -c '%U %a %n' /home/EXAMPLE_USER/.gnupg/*
# grep -n '^' /home/EXAMPLE_USER/.gnupg/CONFIG_FILE

Replace EXAMPLE_USER and CONFIG_FILE with a real account and a configuration file covered by the approved policy. Check more than one home if your host has different account types or home locations. Confirm ownership and modes are still sane, and ask the application owner to test the affected GnuPG operation.

This wrapper is not a bulletproof enforcement mechanism. A user can directly edit the generated configuration and bypass the defaults outright. If a setting genuinely needs enforcing against deliberate changes, use a policy design built for that and document its operational impact. Do not claim enforcement just because this command returned 0.

Common traps

• Running as an ordinary user. The manual specifies root; a user-level run cannot reach every relevant home.
• Expecting new homes. Only real users with an existing GnuPG home are in scope.
• Looking for a preview that does not exist. There is no documented dry-run option; inspect and back up first instead.
• Editing the wrong policy. /etc/gnupg/gpgconf.conf is the usual legacy file, but verify the installed gpgconf behaviour and your own deployment.
• Overclaiming the result. A generated setting can be changed by the user and is not a permanent security boundary.