Yes, this affects me too - sorry for the "me too" email! It has actually prevented me from registering my key on keybase.io (if that's a "thing") --- I suppose I could go through the rigmarole of building the Faraday cage, getting the offline key out and revoking the offending signing keys, as if it wasn't fiddly and generally inconvenient enough already... but I really would like to have different signing and authentication keys on each smart card I use, even if the encryption key is the same. And of course the latest key I created is actually my "weakest" key (for an experiment with a Yubikey NEO). Sigh.
I wish it would make a decision more along the lines of "of the keys I have available, I'll pick the newest or 'strongest'", rather than "I don't care what keys I have available, I just want the newest". Sadly I don't think I have even the skills to find where this decision is made in the code, let alone change it. I really hope it gets some attention soon though! Thankyou for bumping the priority. Apart from that bugbear, love the software. Andy On 19 April 2017 at 16:46, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > On Tue 2017-04-18 15:41:08 +0000, Arthur Ulfeldt wrote: > > I had exactly the same problem, and there is an open bug about this > (wanna > > fix it?) I forgot the number. > > The open report is https://dev.gnupg.org/T1983 > > I've just moved this to priority "high" since it seems to continue to > affect people. > > --dkg > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
