I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6. I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
On St, 2016-02-17 at 05:52 +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=130 9175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6. I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
On Wed, 17 Feb 2016 10:29:29 +0100 Tomas Mraz tmraz@redhat.com wrote:
On St, 2016-02-17 at 05:52 +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=130 9175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6. I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
Yeah, I'm in favor too. Perhaps you could file this change/start working on it just after we branch f24?
kevin
On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6.
Which was a mistake, in my opinion.
I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6.
Which was a mistake, in my opinion.
I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
What would be your opinion for using alternatives for the /usr/bin/gpg?
The problem is that now the keystores are incompatible and it creates big confusion to the users when they see some key in gnupg-1 and do not see it in gnupg-2 and the other way around.
On 17 February 2016 at 15:51, Tomas Mraz tmraz@redhat.com wrote:
The problem is that now the keystores are incompatible and it creates big confusion to the users when they see some key in gnupg-1 and do not see it in gnupg-2 and the other way around.
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
On February 17, 2016 6:04:04 PM GMT+02:00, Richard Hughes hughsient@gmail.com wrote:
On 17 February 2016 at 15:51, Tomas Mraz tmraz@redhat.com wrote:
The problem is that now the keystores are incompatible and it creates big confusion to the users when they see some key in gnupg-1 and do
not
see it in gnupg-2 and the other way around.
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
Same here. But all upstream documentation explicitly mentions gpg2. A change like this would probably make other people spend 2 hours of searching the "right" binary.
El mié, 17-02-2016 a las 16:04 +0000, Richard Hughes escribió:
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.
If it helps, openSUSE got rid of GPG1 and has been shipping GPG2 as /usr/bin/gpg for several years.
On Wed, Feb 17, 2016 at 04:51:48PM +0100, Tomas Mraz wrote:
On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6.
Which was a mistake, in my opinion.
I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
What would be your opinion for using alternatives for the /usr/bin/gpg?
I'm not sure what you're asking here. We have 2 different binaries already. I don't see any reason to add more or rename the existing ones.
The problem is that now the keystores are incompatible and it creates big confusion to the users when they see some key in gnupg-1 and do not see it in gnupg-2 and the other way around.
Right, the problem is that gpg2 was updated to 2.1.x which changed the keystore, not that anything in gpg v1 has changed. Anything using gpg2 needs to do so explicitly.
On St, 2016-02-17 at 08:10 -0800, Brian C. Lane wrote:
On Wed, Feb 17, 2016 at 04:51:48PM +0100, Tomas Mraz wrote:
On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi? id=1 309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6.
Which was a mistake, in my opinion.
I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
What would be your opinion for using alternatives for the /usr/bin/gpg?
I'm not sure what you're asking here. We have 2 different binaries already. I don't see any reason to add more or rename the existing ones.
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 06:41:51PM +0100, Tomas Mraz wrote:
On St, 2016-02-17 at 08:10 -0800, Brian C. Lane wrote:
I'm not sure what you're asking here. We have 2 different binaries already. I don't see any reason to add more or rename the existing ones.
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.
I think using the alternatives would just cause confusion. I think the best approach is to find the things that are assuming gpg 1 and 2 are the same and fix them to use the right one.
On Wed, Feb 17, 2016 at 4:51 PM, Tomas Mraz tmraz@redhat.com wrote:
On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6.
Which was a mistake, in my opinion.
I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
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.
What would be your opinion for using alternatives for the /usr/bin/gpg?
+1. I created on my machine a symlink /usr/bin/gpg to gpg2 to solve these kind of issues.
The problem is that now the keystores are incompatible and it creates big confusion to the users when they see some key in gnupg-1 and do not see it in gnupg-2 and the other way around.
-- 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.)
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Wed, 17 Feb 2016 07:29:26 -0800 "Brian C. Lane" bcl@redhat.com wrote:
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.
Is there any sense upstream how much longer 1.x will be still supported?
I was unaware it was still being maintained, so yeah, seems like a bad idea to change it until it's gone.
kevin
On Wed, Feb 17, 2016 at 09:29:10AM -0700, Kevin Fenzi wrote:
On Wed, 17 Feb 2016 07:29:26 -0800 "Brian C. Lane" bcl@redhat.com wrote:
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.
Is there any sense upstream how much longer 1.x will be still supported?
I was unaware it was still being maintained, so yeah, seems like a bad idea to change it until it's gone.
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.
On Wed, Feb 17, 2016 at 1:18 PM Brian C. Lane bcl@redhat.com wrote:
On Wed, Feb 17, 2016 at 09:29:10AM -0700, Kevin Fenzi wrote:
On Wed, 17 Feb 2016 07:29:26 -0800 "Brian C. Lane" bcl@redhat.com wrote:
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.
Is there any sense upstream how much longer 1.x will be still supported?
I was unaware it was still being maintained, so yeah, seems like a bad idea to change it until it's gone.
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.
As I understand it, it's still being supported with bug fixes, security fixes, and maybe the occasional feature, but most new features are primarily targeting gpg2.
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.
Is there any sense upstream how much longer 1.x will be still supported?
I was unaware it was still being maintained, so yeah, seems like a bad idea to change it until it's gone.
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.
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
On Thu, Feb 18, 2016 at 09:58:04AM +0000, Peter Robinson wrote:
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.
When I asked Werner Koch about gpg1 in December he told me that with adding support to pass the password to some gpg2 component, there is no major technical reason to still use gpg1.
Regards Till
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@apache.org wrote:
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6. I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Wed, Feb 17, 2016 at 1:09 PM John M. Harris, Jr. johnmh@openmailbox.org wrote:
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.
The biggest reason I can think is to make things consistent with the out-of-box behavior of gpg-agent, and Gnome's keyring.
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.
I agree.
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 07:57:47PM -0000, Christopher Tubbs wrote:
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:
- Have packages depend on gnupg2 instead.
- Rename gnupg to gnupg1
- Make gnupg a meta-package which depends on gnupg2 and sets up alternatives.
- Make gpg1 lower priority in alternatives than gpg2 for /usr/bin/gpg
- Don't install gnupg by default.
I don't see the point. Switching because you accidentally type the wrong thing isn't a valid reason.
Upstream still ships and supports gpg, people (like me, the gpg maintainer) still use it instead of gpg2 for various things. Until upstream stops shipping it, or renames it, it should continue to be called gpg.
If you want gpg2, type gpg2. Problem solved and everyone is happy :)
On Thu, Jul 21, 2016 at 8:31 PM Brian C. Lane bcl@redhat.com wrote:
On Thu, Jul 21, 2016 at 07:57:47PM -0000, Christopher Tubbs wrote:
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:
- Have packages depend on gnupg2 instead.
- Rename gnupg to gnupg1
- Make gnupg a meta-package which depends on gnupg2 and sets up
alternatives.
- Make gpg1 lower priority in alternatives than gpg2 for /usr/bin/gpg
- Don't install gnupg by default.
I don't see the point. Switching because you accidentally type the wrong thing isn't a valid reason.
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
Upstream still ships and supports gpg, people (like me, the gpg maintainer) still use it instead of gpg2 for various things. Until upstream stops shipping it, or renames it, it should continue to be called gpg.
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.
If you want gpg2, type gpg2. Problem solved and everyone is happy :)
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.
devel@lists.stg.fedoraproject.org
-
arnaud gaboury -
Brian C. Lane -
Christopher -
Christopher -
John M. Harris, Jr. -
Kevin Fenzi -
Michael Catanzaro -
Nikos Roussos -
Peter Robinson -
Richard Hughes -
Till Maas -
Tomas Mraz