Fixes#263. Really though decision to make whether a paper printout with the password is a good way to go (recoverable but needs a really good place to keep) or not (more protection, but possibly worthless).
The master key is now created with `--batch` and a configuration script.
The subkeys are created with the quick key manipulation
interface (`--quick-add-key`).
Also provided two configuration scripts as templates for a RSA4096 or a
ED25519 master key.
Signed-off-by: apiraino <apiraino@users.noreply.github.com>
````nixpkgs/nixos/modules/installer/cd-dvd/installation-cd-graphical-kde.nix```` no longer exists.
Update to ````nixpkgs/nixos/modules/installer/cd-dvd/installation-cd-graphical-plasma5.nix````
Some GitHub users have asked in the issues why can't I use two Yubikeys (one as a backup). It's a question often asked
The usual answer given across the web is that you can't as GPG replaces the key with key stubs when you quit and save (if you don't save then the Yubikey appears useless as GPG doesn't delete the keys and carries on using them off the keyring.
If once you have run keytocard to transfer your keys to the Yubikey#1 you QUIT WITHOUT SAVING then you can repeat the whole process again and put in your Yubikey#2 and keytocard again. this time QUIT AND SAVE.
GPG will now replace the keys with a key stub pointing to the Yubikey with the card serial number (see Yubikey serial on back of key) when you try to decrypt/sign/authenticate. The first Yubikey will be ignored despite the fact it has a copy of the Yubikey.
However you can use gpg-connect-agent to force read the Yubikey and repoint the key stubs to the keys on the Yubikey inserted.
Just run the script and insert whichever key you have to have (primary or backup) when prompted
NB once this script has been run GPG will be pointing the stubs at the recently used Yubikey ... to go back to your first Yubikey again switch Yubikeys and re-run script
Simples :)
When using a previously provisioned YubiKey on a new computer,
I was met with an "Unusable public key" error when trying to insert
a new password, despite being able to decrypt pass entries.
I tried setting the trust on the key via `gpg --edit-key`, but was
then met with "Need secret key to do this."
I found that the solution is apparently to use the `trust-key`
directive in `~/.gnupg/gpg.conf`, which is not mentioned in the README
at the moment.
