On 08/12/15 00:00, Dark Penguin wrote: > Erm... sorry, I am still not very good with understanding the bug > report flow; I would have checked the Debian GPA bug page before > writing here if I knew about its existence. ^_^' And yes, here it is, > my "Unsupported certificate" bug!..
No problem, it's what mailing lists are for: to give pointers in the right direction. > I'm not sure if this idea makes sense, but maybe it would be easy to > add a check on the version of said gpg-agent before attempting to use > it?.. I know certain recent versions of GnuPG complain and warn about the hijacking, but that is during usage on the terminal. > On one side, GPA is probably supposed to work with whatever > GPG_AGENT_INFO is set to No, this variable is part of the internal architecture of GnuPG and should be set to the gpg-agent that is part of the installed version of GnuPG. This is why I use the term "hijack", rather than something like "provide an alternative service". It has never been intended that other software packages use this variable and start imitating internal parts of GnuPG. > on the other side, if all the other software is fine working with > GNOME Keyring and only GPA needs "only its own" gpg-agent Again, no. Lots of programs get vague problems. It's just that it used to be that GNOME Keyring said "those problems are in GnuPG", whereas the GnuPG project said "those problems are caused by GNOME Keyring breaking our software". The result is that nobody fixed it. I hope that when Debian Stretch is released, we can finally put this behind us, as the problem has been fixed in recent versions that are unfortunately too recent for Jessie AFAIK. > maybe it would make sense to disregard GPG_AGENT_INFO if it points to > GNOME Keyring one, or maybe even disregard it always, or maybe even > have GPA use another fixed path to always connect to "our" > gpg-agent? GnuPG 2.1 already always uses a fixed path and disregards the variable. And recent GnuPG 2.0 versions already warn about the hijack. The problem is that two software projects want opposite things; this would lead to an arms race. But fortunately, it will all go away when distributions start using recent versions of the software, as the issue has finally been resolved. Oh, by the way, the functionality that GNOME Keyring is providing is that it offers the option of unlocking your GnuPG keys when you log in. I've never understood why this is so darn important. Without GNOME Keyring, you would type two passphrases per login session: once to login, and for the second time when you use your GnuPG key for the first time. The gpg-agent can then keep the key unlocked for the rest of the time if you want it to. With GNOME Keyring, it is reduced to one passphrase: your login passphrase. Some might say that's a 50% gain, I say it is the smallest possible gain: you gain one less passphrase-entering moment per session. Whooptie-friggin'-doo. I don't get it. 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> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
