Hello Werner! On Mon, 21 Nov 2016 10:28:47 +0100, you wrote:
>On Sun, 20 Nov 2016 21:37, c...@nymph.paranoici.org said: > >>>Is there any chance to get that disentangled, maybe by defining a >>>separate secret key directory for each public .kbx keyring in use? > >No. > >> The silence makes me believe that what I described is intended behavior, >> not a 2.1 design flaw. I'd like to know whether that's correct. Any > >Correct. The gpg-agent takes care of private keys and does not know >about gpg or gpgsm. Deleting a private key is not easy because it may >be used by several protocols. This is the reason you see an extra >confirmation message when trying to delete a private key. > >BTW, the use of the --keyring option is in general not a good idea. We >would very much like to entirely get rid of them due to the problems >assocciated with that kludge (or well, that upward compatibility with >PGP). IMHO for several reasons there has to be some method to structure larger key depositories. Just to name a few ... - Performance drops with the number of available keys, especially when data lacking a key-ID (--throw-keyids) have to be decrypted. - In a multi-user environment the key owning recipient has to be granted access to the private key with some sender being restricted to only use the public key no matter whether there's any chance s/he guesses the correct passphrase. - There's no reason to have keys used for different tasks together on a single keyring, as key management gets chaotic with such a hodgepodge. And confusion would increase even more trying to mimic v1.4 by running multiple GPG Agents dedicated to tasks which have to be separated. Even if there's no chance to return to completely separated keyrings, which without doubt have stood the test of time in GnuPG 1.4, I think there at least has to be a method to group public as well as private keys in some way to allow the selection of only one or a few of these subsets to take part in processing. Currently for example apart from the accidental deletion of private keys I earlier described I don't see any concept of dealing with orphaned files in the private-keys and openpgp-revocs directory. An Agent managing all lists of key subsets would gain the information needed to solve all these problems, for example delete the private key file when all list entries associated with that privat key are removed. Though not very familiar with GnuPG internals I hope I made my concerns somewhat clearer. Good night, and good luck Caro _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users