On 12/07/2020 17:45, Ayoub Misherghi wrote: > Sorry for going off list and messing everybody up. Now I disserve > punishment.
Heh :-). It's just that if I reply off-list, it only helps you, but if it is on-list, other people can find it in a search engine when they're facing something similar. On 11/07/2020 21:07, Ayoub Misherghi wrote: > My current intended usage is in non-interactive mode, completely. > I can remove them from the gpg.conf but I would have to issue them > every time. My understanding is that non-interactive mode requires > those commands. Well, in that case, you should supply --no-batch when you're using it interactively; I'll show why further down. My personal choice would be to have my scripts and programs supply the --batch on invocation rather than put it in the config file, because you only need to write that command invocation in the script once (as you're writing the script), whereas you'll be writing the --no-batch every time you /do/ use it from an interactive shell. > I selected "expert" mode because I am using ED2599 incrpytion that is > available only in this mode (I know, I am newbie) You only need the --expert on commands creating or adding keys for that. Once you have the key, you no longer need --expert to just use it. > All the config lines I showed are in my user config. > A few days ago, my set up, which is still in development phase, > worked until my short lived gpg keys expired. I fell in deep ***** when > I created new keys. It all worked, with the passphrase-file option and > without, before I fell. Can you pull this dumb newbie out? I think the combination that worked might have been --8<---------------cut here---------------start------------->8--- pinentry-mode loopback passphrase-file /home/ayoub/.gnupg/output.png --8<---------------cut here---------------end--------------->8--- but once you commented out the passphrase-file entry, GnuPG had no way to get the passphrase. Normally you should use the pinentry (so comment out the pinentry-mode line as well), but you force it to use the loopback pinentry-mode. gpg _could_ ask for your passphrase that way. But, you also specify --batch. --batch tells GnuPG that the human is currently unavailable and it needn't bother trying to interact with it. So it has no way to get the passphrase and gives up. It will ask you for the passphrase when you comment out --batch, but I recommend also commenting out the --pinentry-mode line so it'll just launch a pinentry like it wants to do. Now about this configuration: --8<---------------cut here---------------start------------->8--- pinentry-mode loopback passphrase-file /home/ayoub/.gnupg/output.png --8<---------------cut here---------------end--------------->8--- If this file is stored with the same access conditions as ~/.gnupg/private-keys-v1.d/, it serves no good purpose. You should then just use a key without a passphrase. With a key without a passphrase, an attacker would just need the file ~/.gnupg/private-keys-v1.d/[...].key and they're good to go. With your passphrase-file, they need two files: ~/.gnupg/private-keys-v1.d/[...].key ~/.gnupg/output.png and once again they're good to go, they have your private key. Why would it be more difficult to get a hold of two files rather than one? Just drop the passphrase, and all your problems magically disappear :-). But given its name, I suppose output.png is generated by some unlocking process. Suppose you did it like this before: $ my-unlocker >~/.gnupg/output.png You can actually unlock keys the way GnuPG intends to do that with: $ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset <keygrip> You can find the keygrip for your keys with: $ gpg --with-keygrip --list-secret-keys You do need it for every subkey you want to use like this separately, and also, it does not verify whether the passphrase was correct. Also, put allow-preset-passphrase max-cache-ttl <seconds> in ~/.gnupg/gpg-agent.conf and issue $ gpgconf --kill gpg-agent to reload. <seconds> is how long you want the passphrase to stay available after gpg-preset-passphrase, and it defaults to a mere 2 hours. You could set it to 4294967295 to specify a lifetime of 136 years, i.e., infinitely for all practical purposes. Watch out that my-unlocker doesn't leak the passphrase in any way. I thought it was unhelfpul that you can't use the pinentry with gpg-preset-passphrase and I proposed a hack more than two years ago: https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059917.html It's pretty hacky, but it does seem to work. You could actually just unlock your key by using it once when you start up your system, and then use the caching feature to keep it available for non-interactive use for the rest of the time. Then you don't use gpg-preset-passphrase, but put, e.g., this in your gpg-agent.conf default-cache-ttl 4294967295 max-cache-ttl 4294967295 and unlock your key by doing one decryption: $ echo Open Sesame | gpg -r develop1 -e | gpg -d This will pop up a pinentry for your passphrase, and since you set the cache-ttl to infinity, it will never popup a pinentry again on decryptions until you restart gpg-agent. It's a pretty good workflow that uses all parts as they were intended. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
