Re: GnuPG 2.2.0 and replacement of GnuPG1
by Till Maas
On Mon, Sep 04, 2017 at 08:56:31AM +0200, Remi Collet wrote:
> gnupg v2 is a nightmare for "server", I maintain some PHP extensions and
> libraries which works perfectly against v1, and not against v2
Would it be ok for you to patch the libraries to use /usr/bin/gpg1
instead?
> And, AFAIK, v1 is still maintained.
It is on life-support but not properly maintained. GPG2 uses a better
file format for private keys that GPG1 does not understand. Therefore
GPG2 allows for example to merge GPG subkeys for private keys. If one
relies on GPG2. Also the GPG agent for GPG2 seems to be better than the
GPG1 agent. AFAIK there is no benefit for anyone to still use GPG1 over
GPG2 except for not updating code now. For me it only causes problems
when I accidentally use GPG1 instead of GPG2 because the gpg command
points to GPG1. Also I remember that there might be issues with GPG
signing GIT commits since it defaults to using the gpg command instead
of using the gpg2 command.
Eventually GPG1 will die anyhow. Also the default library gpgme supports
GPG2 correctly and it would be better for code to use GPG via gpgme
instead of writing own wrappers as an extension/library anyhow IMHO.
Kind regards
Till
6 years, 7 months
Re: GnuPG 2.2.0 and replacement of GnuPG1
by Michael J Gruber
Till Maas venit, vidit, dixit 04.09.2017 18:24:
> On Mon, Sep 04, 2017 at 08:56:31AM +0200, Remi Collet wrote:
>
>> gnupg v2 is a nightmare for "server", I maintain some PHP extensions and
>> libraries which works perfectly against v1, and not against v2
>
> Would it be ok for you to patch the libraries to use /usr/bin/gpg1
> instead?
>
>> And, AFAIK, v1 is still maintained.
>
> It is on life-support but not properly maintained. GPG2 uses a better
> file format for private keys that GPG1 does not understand. Therefore
> GPG2 allows for example to merge GPG subkeys for private keys. If one
> relies on GPG2. Also the GPG agent for GPG2 seems to be better than the
> GPG1 agent. AFAIK there is no benefit for anyone to still use GPG1 over
> GPG2 except for not updating code now. For me it only causes problems
> when I accidentally use GPG1 instead of GPG2 because the gpg command
> points to GPG1. Also I remember that there might be issues with GPG
> signing GIT commits since it defaults to using the gpg command instead
> of using the gpg2 command.
It uses gpg if present, and gpg2 if gpg is not present; also gpg.program
can be set in global config to force a specific program.
Note that Git uses "gpg" in a way that works with both versions (as far
as the commandline is concerned).
So, the only problem for Git is when gpg(1) is installed along with gpg2
and users expect Git to "magically" use gpg2 when they prefer that (key
store, agent set-up).
> Eventually GPG1 will die anyhow. Also the default library gpgme supports
> GPG2 correctly and it would be better for code to use GPG via gpgme
> instead of writing own wrappers as an extension/library anyhow IMHO.
>
> Kind regards
> Till
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
6 years, 7 months
Re: How should we handle gnupg v1.4.X as gpg1?
by Dominik 'Rathann' Mierzejewski
On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane <bcl(a)redhat.com> wrote:
>
> > The time for change is finally, almost here :) Upstream is talking about
> > installing the v1.4 series as gpg1. They have already switched the
> > default install of 2.2 to /usr/bin/gpg, but we currently override this
> > with the --enable-gpg-is-gpg2 switch in gnupg2.
> >
> > Tracker bug here - https://dev.gnupg.org/T3443
> > Discussion -
> > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
> >
> > When this happens I plan on tracking upstream's change and installing as
> > gpg1, but I'm pretty sure we need a plan so that things don't end up all
> > broken.
> >
>
> Have you considered using alternatives as part of that plan, with gpg2 set
> to higher priority than gpg1? Since upstream calls both binaries "gpg", it
> kind of already makes sense to deconflict them with the alternatives system
> in this way.
Alternatives are for things that are drop-in replacements. As far as I
know, gpg2 is not a drop-in replacement for gpg1.
Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
6 years, 6 months
Re: How should we handle gnupg v1.4.X as gpg1?
by Christopher
On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net> wrote:
> On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane <bcl(a)redhat.com> wrote:
> >
> > > The time for change is finally, almost here :) Upstream is talking
> about
> > > installing the v1.4 series as gpg1. They have already switched the
> > > default install of 2.2 to /usr/bin/gpg, but we currently override this
> > > with the --enable-gpg-is-gpg2 switch in gnupg2.
> > >
> > > Tracker bug here - https://dev.gnupg.org/T3443
> > > Discussion -
> > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
> > >
> > > When this happens I plan on tracking upstream's change and installing
> as
> > > gpg1, but I'm pretty sure we need a plan so that things don't end up
> all
> > > broken.
> > >
> >
> > Have you considered using alternatives as part of that plan, with gpg2
> set
> > to higher priority than gpg1? Since upstream calls both binaries "gpg",
> it
> > kind of already makes sense to deconflict them with the alternatives
> system
> > in this way.
>
> Alternatives are for things that are drop-in replacements. As far as I
> know, gpg2 is not a drop-in replacement for gpg1.
>
I suppose it depends on which characteristics you're considering when you
compare the two. I can't be the only one who has noticed their command-line
usage similarities, which is the characteristic I would expect to matter
when considering using the alternatives system.
6 years, 6 months
How should we handle gnupg v1.4.X as gpg1?
by Brian C. Lane
The time for change is finally, almost here :) Upstream is talking about
installing the v1.4 series as gpg1. They have already switched the
default install of 2.2 to /usr/bin/gpg, but we currently override this
with the --enable-gpg-is-gpg2 switch in gnupg2.
Tracker bug here - https://dev.gnupg.org/T3443
Discussion - https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
When this happens I plan on tracking upstream's change and installing as
gpg1, but I'm pretty sure we need a plan so that things don't end up all
broken.
I'm not sure of all the corners where we use gpg so we need to track
those down and make a list of things that need changing. In some cases
using gpg 2.2.x will be fine, but I'm sure there will continue to be
cases where gpg1 is needed.
This would be for rawhide only of course, any updates to previous
releases would continue to use /usr/bin/gpg
--
Brian C. Lane (PST8PDT)
6 years, 6 months
Re: How should we handle gnupg v1.4.X as gpg1?
by Christopher
On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane <bcl(a)redhat.com> wrote:
> The time for change is finally, almost here :) Upstream is talking about
> installing the v1.4 series as gpg1. They have already switched the
> default install of 2.2 to /usr/bin/gpg, but we currently override this
> with the --enable-gpg-is-gpg2 switch in gnupg2.
>
> Tracker bug here - https://dev.gnupg.org/T3443
> Discussion -
> https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
>
> When this happens I plan on tracking upstream's change and installing as
> gpg1, but I'm pretty sure we need a plan so that things don't end up all
> broken.
>
Have you considered using alternatives as part of that plan, with gpg2 set
to higher priority than gpg1? Since upstream calls both binaries "gpg", it
kind of already makes sense to deconflict them with the alternatives system
in this way.
6 years, 6 months
Re: How should we handle gnupg v1.4.X as gpg1?
by Christopher
On Wed, Oct 11, 2017 at 4:09 AM Tomas Mraz <tmraz(a)redhat.com> wrote:
> On Wed, 2017-10-11 at 05:33 +0000, Christopher wrote:
> > On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> > dominik(a)greysector.net> wrote:
> >
> > > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane <bcl(a)redhat.com>
> > > > wrote:
> > > >
> > > > > The time for change is finally, almost here :) Upstream is
> > > > > talking
> > >
> > > about
> > > > > installing the v1.4 series as gpg1. They have already switched
> > > > > the
> > > > > default install of 2.2 to /usr/bin/gpg, but we currently
> > > > > override this
> > > > > with the --enable-gpg-is-gpg2 switch in gnupg2.
> > > > >
> > > > > Tracker bug here - https://dev.gnupg.org/T3443
> > > > > Discussion -
> > > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > > 51.html
> > > > >
> > > > > When this happens I plan on tracking upstream's change and
> > > > > installing
> > >
> > > as
> > > > > gpg1, but I'm pretty sure we need a plan so that things don't
> > > > > end up
> > >
> > > all
> > > > > broken.
> > > > >
> > > >
> > > > Have you considered using alternatives as part of that plan, with
> > > > gpg2
> > >
> > > set
> > > > to higher priority than gpg1? Since upstream calls both binaries
> > > > "gpg",
> > >
> > > it
> > > > kind of already makes sense to deconflict them with the
> > > > alternatives
> > >
> > > system
> > > > in this way.
> > >
> > > Alternatives are for things that are drop-in replacements. As far
> > > as I
> > > know, gpg2 is not a drop-in replacement for gpg1.
> > >
> >
> > I suppose it depends on which characteristics you're considering when
> > you
> > compare the two. I can't be the only one who has noticed their
> > command-line
> > usage similarities, which is the characteristic I would expect to
> > matter
> > when considering using the alternatives system.
>
> I think that the incompatibility of the key storage warrants for not
> using the alternatives system in this case.
>
>
The alternatives system is there to provide choice between different
implementations. The fact that they have different implementations of their
backend storage is not a reason to avoid alternatives... it's a reason to
use it to provide users a choice. Not using alternatives is just going to
make it harder for users to switch back to gpg1 when gpg2 is made the
default gpg, if a user needs to continue using the old storage format. It
won't affect me, though. I'll be using gpg2, regardless. I was just
thinking of trying to support those other users who need/want to stay on
the old implementation.
6 years, 6 months
Re: How should we handle gnupg v1.4.X as gpg1?
by Tomas Mraz
On Wed, 2017-10-11 at 05:33 +0000, Christopher wrote:
> On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> dominik(a)greysector.net> wrote:
>
> > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane <bcl(a)redhat.com>
> > > wrote:
> > >
> > > > The time for change is finally, almost here :) Upstream is
> > > > talking
> >
> > about
> > > > installing the v1.4 series as gpg1. They have already switched
> > > > the
> > > > default install of 2.2 to /usr/bin/gpg, but we currently
> > > > override this
> > > > with the --enable-gpg-is-gpg2 switch in gnupg2.
> > > >
> > > > Tracker bug here - https://dev.gnupg.org/T3443
> > > > Discussion -
> > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > 51.html
> > > >
> > > > When this happens I plan on tracking upstream's change and
> > > > installing
> >
> > as
> > > > gpg1, but I'm pretty sure we need a plan so that things don't
> > > > end up
> >
> > all
> > > > broken.
> > > >
> > >
> > > Have you considered using alternatives as part of that plan, with
> > > gpg2
> >
> > set
> > > to higher priority than gpg1? Since upstream calls both binaries
> > > "gpg",
> >
> > it
> > > kind of already makes sense to deconflict them with the
> > > alternatives
> >
> > system
> > > in this way.
> >
> > Alternatives are for things that are drop-in replacements. As far
> > as I
> > know, gpg2 is not a drop-in replacement for gpg1.
> >
>
> I suppose it depends on which characteristics you're considering when
> you
> compare the two. I can't be the only one who has noticed their
> command-line
> usage similarities, which is the characteristic I would expect to
> matter
> when considering using the alternatives system.
I think that the incompatibility of the key storage warrants for not
using the alternatives system in this case.
--
Tomáš Mráz
Red Hat
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
* Google and NSA associates, this message is none of your business.
* Please leave it alone, and consider whether your actions are
* authorized by the contract with Red Hat, or by the US constitution.
* If you feel you're being encouraged to disregard the limits built
* into them, remember Edward Snowden and Wikileaks.
6 years, 6 months
Re: Wasn't gpg supposed to be renamed to gpg1?
by Igor Gnatenko
Seems that I missed writing announcement, but there is a package
called `gnupg1` which provides `gpg1` binary.
So you should be fine with that I hope. And sorry for this trouble.
On Wed, Dec 19, 2018 at 11:25 AM Bruno Wolff III <bruno(a)wolff.to> wrote:
>
> gnupg2 is now obsoleting gnupg and the previous gpg command is not available.
> The change page said gpg would be renamed gpg1, but this was not done.
> Unfortunately gpg2 will not read my existing secret keys. (They are pretty
> old and probably should be replaced.) For now using rpm --nodeps allowed
> me to replaced the gnupg2 version of gpg with the gnupg version so I could
> get at some encrypted data, but it would be nice if the plan from the change
> page had been used instead of what was done. If the plan has changed, then
> updating the change page to match what was done would be nice. Though in
> the latter case there should be a warning about breaking things for some
> people.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
5 years, 4 months
Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
== Summary ==
The /usr/bin/gpg path representing the main GPG implementation will
now use GnuPG 2 instead of GnuPG 1.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:till|Till
Maas]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain(a)fedoraproject.org, opensource(a)till.name,
ngompa13(a)gmail.com
== Detailed Description ==
For long time, GnuPG 2 is de-facto standard and it is unfortunate to
have /usr/bin/gpg to point to GnuPG 1 given that all major
repositories already have it that way.
Some of them don't even have GnuPG 1 shipped (RHEL is one example).
== Benefit to Fedora ==
This change will bring Fedora in line with other major distributions,
users will get consistent experience between distributions and the
naive expectation that "gpg" binary is the latest and greatest
implementation of GnuPG.
== Scope ==
* Proposal owners:
** Rename gnupg package to gnupg1
** Rename gpg binary to gpg1
** Rename gpg2 binary to gpg
** Create gpg2 → gpg symlink
** Check and fix if needed existing packages which require /usr/bin/gpg
* Other developers: Everything can be handled by change owners.
* Release engineering: [https://pagure.io/releng/issue/7920 #7920]
* Policies and guidelines: No changes are needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Users will have to adapt to change that gpg is now called gpg1 if
their usage is not compatible with both 1.x and 2.x.
== How To Test ==
Before change is implemented, owners will prepare COPR repository. You
will need to enable it and update and ensure that your
applications/scripts still work.
== User Experience ==
* /usr/bin/gpg is pointing to latest release of GnuPG 2 which makes
consistent user experience between distributions
== Dependencies ==
What can't be adopted to this change will be patched to use gpg1
explicitly, no action is needed from any developers.
== Contingency Plan ==
* Contingency mechanism: Owners will revert changes and postpone
change to next release.
* Contingency deadline: Beta Freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
Both gpg1 and gpg2 have their own documentation shipped with them.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 5 months
