Re: GPG2 as default /usr/bin/gpg

[Christopher]

On Thu, Jul 21, 2016 at 8:31 PM Brian C. Lane  wrote:

> On Thu, Jul 21, 2016 at 07:57:47PM -, 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:
> >
> > 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.
>
> 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 mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Brian C. Lane]

On Thu, Jul 21, 2016 at 07:57:47PM -, 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:
> 
> 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.

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 :)

-- 
Brian C. Lane | Port Orchard, WA (PST8PDT)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Christopher Tubbs]

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Till Maas]

On Thu, Feb 18, 2016 at 09:58:04AM +, 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Peter Robinson]

>> > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[arnaud gaboury]

On Wed, Feb 17, 2016 at 4:51 PM, 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 +, 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



-- 

google.com/+arnaudgabourygabx
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Brian C. Lane]

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.
-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Christopher]

On Wed, Feb 17, 2016 at 1:09 PM John M. Harris, Jr. 
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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Christopher]

On Wed, Feb 17, 2016 at 1:18 PM Brian C. Lane  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"  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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Tomas Mraz]

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 +, 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.)


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Brian C. Lane]

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"  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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Michael Catanzaro]

El mié, 17-02-2016 a las 16:04 +, 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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Kevin Fenzi]

On Wed, 17 Feb 2016 07:29:26 -0800
"Brian C. Lane"  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




pgpOsio104xDF.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Nikos Roussos]

On February 17, 2016 6:04:04 PM GMT+02:00, Richard Hughes  
wrote:
>On 17 February 2016 at 15:51, Tomas Mraz  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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Richard Hughes]

On 17 February 2016 at 15:51, Tomas Mraz  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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Brian C. Lane]

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 +, 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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Tomas Mraz]

On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote:
> On Wed, Feb 17, 2016 at 05:52:45AM +, 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.

-- 
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

Re: GPG2 as default /usr/bin/gpg

[John M. Harris, Jr.]

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  
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

-- 
Sent from my Android device. Please excuse my brevity.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Brian C. Lane]

On Wed, Feb 17, 2016 at 05:52:45AM +, 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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Kevin Fenzi]

On Wed, 17 Feb 2016 10:29:29 +0100
Tomas Mraz  wrote:

> On St, 2016-02-17 at 05:52 +, 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




pgpc2byPpQFg1.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GPG2 as default /usr/bin/gpg

[Tomas Mraz]

On St, 2016-02-17 at 05:52 +, 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.

-- 
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