GPG Agent forwarding has a broader usage, not only
limited to ssh-agent forwarding.
In this commit gpg-agent forwarding is raised as a
separate section as it can not be contained by #SSH
any longer.
More details are added for gpg-agent forwarding, including
some important notes taken from practice and analysis.
For ssh-agent forward, older method are contained, and new
method will be included as framework has been structured.
if not done, in the next step you get error:
gpg: keyblock resource '/home/..../gnupg-workspace/pubring.kbx': No such file or directory
gpg: no writable keyring found: Not found
As mentioned in #197, the previous behaviour would require users to
touch their key any time an authentication, signing, or encryption
operation was performed. In some situations, this behaviour would be
undesirable and the only way to revert it would be fully resetting the
key and starting from scratch. Rather than using `fixed`, this commit
simply turns the feature `on` so the user can change it later if they
wish.
Additionally, a note about the other policies was included so users can
decide for themselves which fits their situation better.
Setting the touch policy to `on` does not prevent the policy from
later being turned off again. Setting it to `fixed` is more secure
because it can not be turned off.
If someone wants to disable the touch policy they can always restore
the keys from the backups created in the guide.
I missed the error message when attempting to set a PIN of only 5 characters due
to the UI repeating the options below it.
Pinentry happily stores the bogus PIN and even counts down the retry counter
when entering the correct (default) one. This can be resolved by unblocking the
PIN.
Once I ran the gpg-agent with debug output (a tip found in the added link), the
issue was obvious.
According to 'man gpg' the order of arguments should be
gpg [--homedir name] [--options file] [options] command [args]
In this case '--gen-revoke' is the command, '$KEYID' is an argument and
'--output $GNUPGHOME/revoke.asc' is an option. Previously this was
incorrect (option came first) and would spawn an error.
As discussed in issue #164, the current section on Rotating Keys
presents two alternatives: replacing the existing keys with a newly
generated key or extending the validity of existing keys by changing
their expiration. However, it only provides instructions for the
first approach. This commit adds instructions for renewing sub-keys.
I am far from an expert, and am submitting this change mostly in hopes
that it will provide documentation for the next time I need to renew
my sub-keys. I would welcome any changes or clarifications others
would care to offer.
Zenithal