[gentoo-dev] gnupg-1, gnupg-2, gpgme, & slight apology

[gentoo-dev] gnupg-1, gnupg-2, gpgme, & slight apology

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

First off to get the apology out of the way. Me being a user of both
seahorse and gnupg, I wasn't fully aware of the mess going on in between
the two. So in that regard I do apologize to Alon Bar-Lev ( alonbl ).
Things are not so cut and dry, and I could see where one might have the
need for eselect there. Although there might be other options as well.

The story as clear and concise as I can make it. Yes upstream created
gnupg-1 and gnupg-2 to co-exist. However upstream did not do anything to
address a VERY popular wrapper to gnugp, gpgme. Presently most apps like
seahorse use gpgme to interface with gnupg. Instead of doing it
directly. At the present time you end up linking gpgme to either gnupg-1
or gnupg-2. No means to do both, and that's where the eselect part comes
into play. Ideally apps should interface directly, but upstream didn't
really encourage that, and it's why gpgme exists in the first place.
Which might die.

There are other issues, like gpgme executing gpg on each invocation. So
it's hardly ideal and from what Robin (robbat2) has told me. They might
be getting rid of gpgme and/or introducing a --server flag or something
like that for gnupg. Not 100% clear there and doesn't really matter per
our present problems and situations. But would be a performance benefit
from that change :)

Despite other distros shipping both gnupg-1 and gnupg-2. They are just
now seeing the problems. Because being binary, I don't believe gpgme was
ever linked against gnupg-2. So it's there for users, but apps really
aren't bound to it. So some like Debian are hitting this now, when we
ran into it a year ago.

Now that their is full understanding, and some clarity. It still doesn't
present us with a solution at this time. Seems like most all issues with
gnupg-2 have been worked out, but a few remain. Not sure how important
it is to address those. I have no doubt both Alon and Robin are working
on those as time permits.

Slots and eselect is one way to go. I mentioned to Robin, maybe doing a
USE flag on gpgme, to control what it's bound to, like gpg2 or gpg,
since the later is already a USE flag I believe. Slotting both in the
mean time, till the gpgme mess is cleared up. That way users could chose
what gpgme is linked to, and still use gnupg-2/gnupg-1 or etc. But like
before, totally up to those working on it, Alon and Robin.

Anyway just wanted to take a moment to apologize a bit. It's quite a
mess, and I do appreciate those in Gentoo undertaking it, and seeing it
through. Very sorry for any flack or abrasiveness. Just got sucked into
all this as just a user of said apps.

But really most all are problems are gpgme. Upstream is JUST now
starting to acknowledge that problem. When people have been pointing it
out for over a year :) It's a wonderful mess.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] gnupg-1, gnupg-2, gpgme, & slight apology

[Alon Bar-Lev]

Hello,

I believe that part of distribution function is to provide a simple
and maintainable
system to its users.

If upstream is doing something wrong, we don't have to move the problem to
our users to handle, but handle/solve the problem on behalf of our user base.

The gnupg issue falls in this category. It looks like this upstream
(g10) made some
incorrect decisions. They wanted to make gnupg modular, this indeed correct
approach, as gpg and gpgsm have a lot in common. But as they were doing so
they also broke backward compatibility of "gpg" command-line. They had not
needed to do so, but they chose to do so anyway.

Their solution to the problem was to install gpg utility for version 1.X and
gpg2 utility for version 2.X. But now, applications should be aware
which version they work with, as the filename was modified. Forcing
users to keep both versions around for infinite.

For us and our users, maintaining this kind of a solution is much more complex,
and will introduce hidden costs, as you don't know which version is
used by which
component.

The correct solution is to keep backward compatibility of the interface,
and make the software modular.... If upstream doesn't care, someone should.

Backward compatibility is gone... We cannot do much about this.
So the only thing we can do is modify application to use the new interface
if required. This will enable us to provide much simpler configuration for
our users.

The funny thing is that even gpgme, a g10 solution, does not work correctly with
both gnupg-1.X and gnupg-2.X... Even latest release (1.6 a week ago) did not
pass its own internal tests.

g10 is one of the worse upstreams I have ever worked with... They keep breaking
their software, and uncooperative when it comes to bug reports, look
at bug#204662.
For example, they notified that soon applications will not be able to pass
the passphrase to gpg via command-line or file description. This will
surely break
almost any batch application.

The only regression left is mail-client/squirrelmail gpg plugin.
http://bugs.gentoo.org/show_bug.cgi?id=202406
If someone has this installed, know some php and willing to help, it
would be great!
Its upstream is aware of this issue, and looks like doesn't care.

Best Regards,
Alon Bar-Lev.

On 1/9/08, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> First off to get the apology out of the way. Me being a user of both
> seahorse and gnupg, I wasn't fully aware of the mess going on in between
> the two. So in that regard I do apologize to Alon Bar-Lev ( alonbl ).
> Things are not so cut and dry, and I could see where one might have the
> need for eselect there. Although there might be other options as well.
>
> The story as clear and concise as I can make it. Yes upstream created
> gnupg-1 and gnupg-2 to co-exist. However upstream did not do anything to
> address a VERY popular wrapper to gnugp, gpgme. Presently most apps like
> seahorse use gpgme to interface with gnupg. Instead of doing it
> directly. At the present time you end up linking gpgme to either gnupg-1
> or gnupg-2. No means to do both, and that's where the eselect part comes
> into play. Ideally apps should interface directly, but upstream didn't
> really encourage that, and it's why gpgme exists in the first place.
> Which might die.
>
> There are other issues, like gpgme executing gpg on each invocation. So
> it's hardly ideal and from what Robin (robbat2) has told me. They might
> be getting rid of gpgme and/or introducing a --server flag or something
> like that for gnupg. Not 100% clear there and doesn't really matter per
> our present problems and situations. But would be a performance benefit
> from that change :)
>
> Despite other distros shipping both gnupg-1 and gnupg-2. They are just
> now seeing the problems. Because being binary, I don't believe gpgme was
> ever linked against gnupg-2. So it's there for users, but apps really
> aren't bound to it. So some like Debian are hitting this now, when we
> ran into it a year ago.
>
> Now that their is full understanding, and some clarity. It still doesn't
> present us with a solution at this time. Seems like most all issues with
> gnupg-2 have been worked out, but a few remain. Not sure how important
> it is to address those. I have no doubt both Alon and Robin are working
> on those as time permits.
>
> Slots and eselect is one way to go. I mentioned to Robin, maybe doing a
> USE flag on gpgme, to control what it's bound to, like gpg2 or gpg,
> since the later is already a USE flag I believe. Slotting both in the
> mean time, till the gpgme mess is cleared up. That way users could chose
> what gpgme is linked to, and still use gnupg-2/gnupg-1 or etc. But like
> before, totally up to those working on it, Alon and Robin.
>
> Anyway just wanted to take a moment to apologize a bit. It's quite a
> mess, and I do appreciate those in Gentoo undertaking it, and seeing it
> through. Very sorry for any flack or abrasiveness. Just got sucked into
> all this as just a user of said apps.
>
> But really most all are problems are gpgme. Upstream is JUST now
> starting to acknowledge that problem. When people have been pointing it
> out for over a year :) It's a wonderful mess.
>
> --
> William L. Thomson Jr.
> Gentoo/Java
>
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] gnupg-1, gnupg-2, gpgme, & slight apology

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]


On Fri, 2008-01-11 at 17:06 +0200, Alon Bar-Lev wrote:
> Hello,
> 
> I believe that part of distribution function is to provide a simple
> and maintainable
> system to its users.
> 
> If upstream is doing something wrong, we don't have to move the problem to
> our users to handle, but handle/solve the problem on behalf of our user base.

Understood, I just kinda wanted to see a band aid applied for the last
year to save users grief. After all I am a user of gnupg and seahorse,
and I suffered :). But seems things have progressed well so is likely
moot at this point. If there is even a need. Not to mention band aid,
likely would not have covered the entire wound :) Thanks for your
efforts.

> g10 is one of the worse upstreams I have ever worked with... They keep breaking
> their software, and uncooperative when it comes to bug reports

That alone fully justifies pushing the problem to getting those
downstream of them to update to gpg2, etc. Before it seemed like forcing
allot of downstream projects to adapt a bit ahead of schedule. Now the
entire mess is allot clearer.

Thanks for undertaking such a head ache app to maintain. Sorry for any
flack from a users perspective there. Just because we hold -dev titles
and status. Doesn't mean we develop/work with every program in tree.
Many we just use as our users do. So let us not forget that aspect :)

Anyway again, sorry for grief, thanks for your efforts. Good luck with
upstream, if you don't mind. I would like to steer clear of this, and
leave it to crypt herd peeps :)


FYI, compnerd added a default xinitrc.d script to seahorse in gnome
overlay. Per the upstream session integration docs. Eva/EvaSDK's
contributed xinitrc sript :) That should allow it to work out of the box
as before, and with gnupg-2 :) Testing it out on a new box, but do not
expect any problems.

-- 
William L. Thomson Jr.
Gentoo/amd64/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]