transition script up to 0.23 fails for servers whose keys initial self-sigs are expired
It appears that gpg --export-secret-keys only exports the first self-sigs on each user id of the secret key.
It also appears that gpg --import fails (returns non-zero) if no valid (non-expired) self-sigs on any user ID are present in the incoming data. It behaves this way even if valid self-sigs for the same key were found in earlier packets in the input stream, or if the local public keyring has valid self-sigs for the given key.
This means that if you run transitions/0.23 on a host whose original self-sigs have since expired, the gpg --import of the host secret key material into the new host keyring will fail, even if there are currently-valid self-sigs in the pubring.
This causes the transition script to fail, and unfortunately, it fails uncleanly by leaving the new /var/lib/monkeysphere/host directory around, which means that the remaining steps of the transition script are not run.
Even worse, aptitude tries to run the transition script a second time, after the first run fails, and this second run behaves differently because the first run quit in a partial state.
What's the right way to fix this? There are probably several parts:
- file a bug with gpg -- it should not be behaving this way, especially not for keys with current, non-expired self-sigs
- think about how to properly handle transitions where gpg does fail (for example, on hosts where all the self-sigs are actually expired due to sloppy administration)
- update the transition script to not create the target directories in-place; it should create them with random names and then move them into place when it is satisfied that the right things have been done.
(from redmine: created on 2009-02-22, closed on 2009-03-01)