On St, 2016-02-17 at 05:52 +0000, Christopher wrote: I am in favor of changing the default too. The question is whether it is not too late for Fedora 24 as I'd say this should be a Fedora Change and we are past the deadline for Changes proposals. So this will have to be postponed to Fedora 25. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.)

On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote: Which was a mistake, in my opinion. I am opposed to this. If a tool wants/needs to use v2 it should be using gpg2 not gpg. gpg v1.4.x is still active upstream and is shipped as gpg so we shouldn't be renaming it. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

On 17 February 2016 at 15:51, Tomas Mraz <tmraz(a)redhat.com&gt; wrote: If it helps, I lost about 2 hours the other day trying to work out why my keys were not visible when imported using gpgme. I'd be 100% behind the change to switch to gpg2 if it saves just one other person 2 hours of confusion. Richard

El mié, 17-02-2016 a las 16:04 +0000, Richard Hughes escribió: If it helps, openSUSE got rid of GPG1 and has been shipping GPG2 as /usr/bin/gpg for several years.

On St, 2016-02-17 at 08:10 -0800, Brian C. Lane wrote: I meant renaming the gnupg-1 binary to gpg1 and make the /usr/bin/gpg a symlink to it via the alternatives system so if user install only gnupg2 the symlink would point to gpg2. But the default can still be a symlink to gpg1. --  Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.)

On Wed, Feb 17, 2016 at 4:51 PM, Tomas Mraz <tmraz(a)redhat.com&gt; wrote: +1. I created on my machine a symlink /usr/bin/gpg to gpg2 to solve these kind of issues. -- google.com/+arnaudgabourygabx

On Wed, Feb 17, 2016 at 09:29:10AM -0700, Kevin Fenzi wrote: AFAIK there are no plans to stop. It can be used in places where gpg2 and its agent system don't make sense. Development on it has slowed, but it gets regular security updates and the occasional new feature. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

I seem to remember there was effort a few years ago to try and migrate everything to v2 but there ended up being a number of specific usecases that v2 didn't do that v1 did and the effort ended up migrating a bunch of stuff but not all so v1 stuck around. It might be useful to document these issues somewhere. Peter

Unless there are any issues with gpg, and to my knowledge there aren't, I can't see any important reason to default 'gpg' to 'gpg2', at least not for f24. I will say that if this is done, we need to be able to use the normal alternatives system (update-alternatives) to change what's used, without user changes worrying about being in conflict with package updates. On February 17, 2016 12:52:45 AM EST, Christopher <ctubbsii-fedora(a)apache.org&gt; wrote: -- Sent from my Android device. Please excuse my brevity.

This is still causing me headaches. GPG2 switched away from the secring.gpg file, and now I have multiple tools using different files for storing my credentials. And, depending on which command I use (sometimes I slip and use gpg instead of gpg2), I import stuff to the wrong keyring, and I can't find it later. That, combined with the fact that the gpg command doesn't use gnome-keyring-daemon's gpg-agent without some extra ENV setup, and the git bug from earlier in the thread, this is getting pretty annoying. Users can't uninstall gnupg and only use gnupg2, either, because important stuffs depend on it, like anaconda, initial-setup, libblockdev-*, monkeysphere, hplip, volume_key-libs (no idea why those last two should, but they do). Being able to use alternatives without messing with package files which are likely to get clobbered on update, would be nice, at the very least. But really, I think it's time to transition, since there's no technical reason why one should be using gnupg1 these days. We could transition in this way: 1. Have packages depend on gnupg2 instead. 2. Rename gnupg to gnupg1 3. Make gnupg a meta-package which depends on gnupg2 and sets up alternatives. 4. Make gpg1 lower priority in alternatives than gpg2 for /usr/bin/gpg 5. Don't install gnupg by default.

On Thu, Jul 21, 2016 at 8:31 PM Brian C. Lane <bcl(a)redhat.com&gt; wrote: That wasn't the only reason given. The other reasons include: * It doesn't provide anything that gpg2 doesn't already provide * It doesn't properly integrate with gnome-keyring-daemon or the default behavior of gpg-agent to use the "standard socket" out of the box, creating a bad user experience * It introduces unnecessary inconsistencies in where keys are stored, again creating a bad user experience when trying to execute commands to display stored keys * There isn't a good mechanism provided for switching between the two, and one cannot uninstall gpg without removing some important things which depend on it I don't see a problem with continuing to ship it, but because of the bad user experience with lack of using the "standard socket" and the inconsistency in where it stores keys, it probably shouldn't be the default. Not everyone. See above thread... I'm not the only one who thought we should move, and others cited precedents for packaging gpg2 as gpg from other downstream maintainers. I'm not arguing for complete removal... I'm just arguing for a change in the default, and a packaging strategy which takes advantage of the alternatives system, to give users a better way to choose, for a better overall out-of-the-box user experience. Essentially, gpg2 obsoletes gpg upstream... even if upstream continues to support it. So, why not move? Given the bad user experience, it seems to me that the argument for keeping it as is should be somewhat more than sticking with the status quo. Can you please explain why my proposal isn't a good compromise which addresses the problems above, and still provides folks the option to use gpg1? Is there a technical reason? Thanks.