https://0xacab.org/monkeysphere/monkeysign/issues/50 shows how a programmatic
user of GnuPG struggled with the silent deprecation of --secret-keyring.
If this option is actually deprecated, there should probably be a warning so
folks know to stop using it.
The developer on that bug report ended up resolving his issues by setting up
symlinks to the standard gpg-agent socket, aiui. If this is the preferred
mechanism, maybe it should also be documented?
thank you for taking time to formulate this correctly, dkg. :)
regarding symlinks, i got the idea from reading the caff source code. after a
quick chat with the caff author, i was pointed towards that discussion:
https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029301.html
... where Werner Koch suggests symlinks as a solution.
in my opinion, the solution is sub-optimal: symlinks increases the attack
surface and adds un-necessary overhead. i would prefer an a commandline flag
(e.g. --agent-socket) or environment variable to be able to select relevant
agents...
the same applies to dirmngr, apparently - caff creates symlinks for both the
agent and dirmngr. i am not sure why, but i suspect I may have to do the same,
since I have seen stray dirmngr processes lying around in my session. a
different issue, maybe, but related, implementation-wise.
For many years I was convinced that my secret keys are stored in an encrypted folder. The .keyring file was there, everything looked correct...
I think this is the worst usability bug that I've encountered in my whole life, based on how dangerous this can be.
Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.
Sorry, I don't understand what you are trying to say, so let me give you some more detail.
I have been running gnupg with
gpg --no-default-keyring --keyring /encrypted/folder/path/keys.gpg
Where /encrypted/folder/path is some encfs mount.
My understanding of this was that keys.gpg would contain my private keys, and would be the only file that contains them. If my laptop were stolen, the thief would not have access to the private keys, or even know that they exist. Turns out my understanding was wrong as the private keys were stored in the unencrypted ~/.gnupg all the time.
Perhaps what you are saying is that my understanding has a bug and gnupg interface doesn't? I think it would be very easy to argue otherwise, so I hope that's not your point.
You should have read the release notes of 2.1 (first point). We can't keep a bug open because you had a wrong understanding of GnuPG properties. Sorry.
This is very saddening and alarming from a respected member of the community whose opinion matters.
"You crashed your car because the gas and the cludge are swapped? Your fault since you didn't read the release notes for this other model from 6 years ago."
I believe you have a dangerous interface bug, and the fact that this bug is documented does not make it any less serious. It is neither reasonable nor feasible to expect your users to read all of your release notes before they can operate your software safely.
I feel pretty strongly about this, so could I offer you $1000 to have a conversation, and/or $5000 to fix this bug? I would have offered privately of course, but I didn't find a direct way to contact you. Feel free to get in touch at avatar@@hot.ee.
I'll open this once more to make sure you've seen the offer, and if you choose to close it, I'll take it as a rejection and won't approach you again.
I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.
diff --git a/g10/gpg.c b/g10/gpg.c index 54f7eb542..af77f072e 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2886,7 +2886,7 @@ main (int argc, char **argv) break; case oSecretKeyring: - /* Ignore this old option. */ + obsolete_option (configname, pargs.lineno, "secret-keyring"); break; case oNoArmor: opt.no_armor=1; opt.armor=0; break;
The option has been removed form the repo more than 11 years ago and the gnupg with this changes (2.1.0) was released 7 years ago including an extensive writeup on all the major changes including notices that the secret keys will be converted and moved.
Anyyway, Ingo's suggestion is a good one. The use of obsolete_option() in gpg started only quite recenlty with 2.3.0
I'm still sad that you don't acknowledge the problem I am describing. It seems that you are writing your software for the kind of user who reads all your documentation first. That kind of user does not exist.
I'm glad this particular instance got fixed though - thanks a lot! Please get in touch to collect the bounty.
Not at all. But 2.1 was such a large change that users really should have read the announcement and think about their use case. We have exensivly communicated the changes and can expect that users test their new installation. IF you have further comments, please use the mailing list.
Nah, I think I laid out all my arguments by now. I don't have more to add, so I'll just let it be.