| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
So the user knows why gpg is asking for this secret key to be backed up.
Before, this was done as soon as keysafe started, which didn't give the
user any indication what was going on, unless they had multiple keys and so
picked the key to back up from a list.
This commit was sponsored by Thomas Hochstein on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bugs with entry of gpg keyid in the keysafe.log. Gpg.anyKey was being
used in writing the log, which made the log contain gpg keys with an empty
keyid.
Fix bug in --autostart that caused the full gpg keyid to be
used in the name, so restores would only work when --gpgkeyid was
specifid.
Added a Distinguisher data type rather than the Gpg.anyKey hack.
This commit was sponsored by Thom May on Patreon.
|
| |
|
|
|
|
|
|
| |
offer to back them up.
Only ask once per key.
This commit was sponsored by Thomas Hochstein on Patreon.
|
| |
|
|
|
|
|
| |
Allow deserializing SecretKeySource so we can later know what gpg keys are
backed up.
Converted KeyId to Text as JSON can't handle ByteString.
|
| |
|
|
|
|
|
| |
gpg2 2.1.15 seems to have added some new fields to the --with-colons
--list-secret-keys output. These include "fpr" and "grp", and come before
the "uid" line. So, the parser was giving up before it saw the name. Fix by
continueing to look for the uid line until the next "sec" line.
|
| |
|
|
| |
Should also support gpg 1.
|
| | |
|
| | |
|
| |
|
|
|
| |
Don't need to check key server for --gpgkeyid backup, because the same
switch has to be provided at restore time.
|
| | |
|
| | |
|
| | |
|
| |
|
