1 |
Hello, |
2 |
|
3 |
I believe that part of distribution function is to provide a simple |
4 |
and maintainable |
5 |
system to its users. |
6 |
|
7 |
If upstream is doing something wrong, we don't have to move the problem to |
8 |
our users to handle, but handle/solve the problem on behalf of our user base. |
9 |
|
10 |
The gnupg issue falls in this category. It looks like this upstream |
11 |
(g10) made some |
12 |
incorrect decisions. They wanted to make gnupg modular, this indeed correct |
13 |
approach, as gpg and gpgsm have a lot in common. But as they were doing so |
14 |
they also broke backward compatibility of "gpg" command-line. They had not |
15 |
needed to do so, but they chose to do so anyway. |
16 |
|
17 |
Their solution to the problem was to install gpg utility for version 1.X and |
18 |
gpg2 utility for version 2.X. But now, applications should be aware |
19 |
which version they work with, as the filename was modified. Forcing |
20 |
users to keep both versions around for infinite. |
21 |
|
22 |
For us and our users, maintaining this kind of a solution is much more complex, |
23 |
and will introduce hidden costs, as you don't know which version is |
24 |
used by which |
25 |
component. |
26 |
|
27 |
The correct solution is to keep backward compatibility of the interface, |
28 |
and make the software modular.... If upstream doesn't care, someone should. |
29 |
|
30 |
Backward compatibility is gone... We cannot do much about this. |
31 |
So the only thing we can do is modify application to use the new interface |
32 |
if required. This will enable us to provide much simpler configuration for |
33 |
our users. |
34 |
|
35 |
The funny thing is that even gpgme, a g10 solution, does not work correctly with |
36 |
both gnupg-1.X and gnupg-2.X... Even latest release (1.6 a week ago) did not |
37 |
pass its own internal tests. |
38 |
|
39 |
g10 is one of the worse upstreams I have ever worked with... They keep breaking |
40 |
their software, and uncooperative when it comes to bug reports, look |
41 |
at bug#204662. |
42 |
For example, they notified that soon applications will not be able to pass |
43 |
the passphrase to gpg via command-line or file description. This will |
44 |
surely break |
45 |
almost any batch application. |
46 |
|
47 |
The only regression left is mail-client/squirrelmail gpg plugin. |
48 |
http://bugs.gentoo.org/show_bug.cgi?id=202406 |
49 |
If someone has this installed, know some php and willing to help, it |
50 |
would be great! |
51 |
Its upstream is aware of this issue, and looks like doesn't care. |
52 |
|
53 |
Best Regards, |
54 |
Alon Bar-Lev. |
55 |
|
56 |
On 1/9/08, William L. Thomson Jr. <wltjr@g.o> wrote: |
57 |
> First off to get the apology out of the way. Me being a user of both |
58 |
> seahorse and gnupg, I wasn't fully aware of the mess going on in between |
59 |
> the two. So in that regard I do apologize to Alon Bar-Lev ( alonbl ). |
60 |
> Things are not so cut and dry, and I could see where one might have the |
61 |
> need for eselect there. Although there might be other options as well. |
62 |
> |
63 |
> The story as clear and concise as I can make it. Yes upstream created |
64 |
> gnupg-1 and gnupg-2 to co-exist. However upstream did not do anything to |
65 |
> address a VERY popular wrapper to gnugp, gpgme. Presently most apps like |
66 |
> seahorse use gpgme to interface with gnupg. Instead of doing it |
67 |
> directly. At the present time you end up linking gpgme to either gnupg-1 |
68 |
> or gnupg-2. No means to do both, and that's where the eselect part comes |
69 |
> into play. Ideally apps should interface directly, but upstream didn't |
70 |
> really encourage that, and it's why gpgme exists in the first place. |
71 |
> Which might die. |
72 |
> |
73 |
> There are other issues, like gpgme executing gpg on each invocation. So |
74 |
> it's hardly ideal and from what Robin (robbat2) has told me. They might |
75 |
> be getting rid of gpgme and/or introducing a --server flag or something |
76 |
> like that for gnupg. Not 100% clear there and doesn't really matter per |
77 |
> our present problems and situations. But would be a performance benefit |
78 |
> from that change :) |
79 |
> |
80 |
> Despite other distros shipping both gnupg-1 and gnupg-2. They are just |
81 |
> now seeing the problems. Because being binary, I don't believe gpgme was |
82 |
> ever linked against gnupg-2. So it's there for users, but apps really |
83 |
> aren't bound to it. So some like Debian are hitting this now, when we |
84 |
> ran into it a year ago. |
85 |
> |
86 |
> Now that their is full understanding, and some clarity. It still doesn't |
87 |
> present us with a solution at this time. Seems like most all issues with |
88 |
> gnupg-2 have been worked out, but a few remain. Not sure how important |
89 |
> it is to address those. I have no doubt both Alon and Robin are working |
90 |
> on those as time permits. |
91 |
> |
92 |
> Slots and eselect is one way to go. I mentioned to Robin, maybe doing a |
93 |
> USE flag on gpgme, to control what it's bound to, like gpg2 or gpg, |
94 |
> since the later is already a USE flag I believe. Slotting both in the |
95 |
> mean time, till the gpgme mess is cleared up. That way users could chose |
96 |
> what gpgme is linked to, and still use gnupg-2/gnupg-1 or etc. But like |
97 |
> before, totally up to those working on it, Alon and Robin. |
98 |
> |
99 |
> Anyway just wanted to take a moment to apologize a bit. It's quite a |
100 |
> mess, and I do appreciate those in Gentoo undertaking it, and seeing it |
101 |
> through. Very sorry for any flack or abrasiveness. Just got sucked into |
102 |
> all this as just a user of said apps. |
103 |
> |
104 |
> But really most all are problems are gpgme. Upstream is JUST now |
105 |
> starting to acknowledge that problem. When people have been pointing it |
106 |
> out for over a year :) It's a wonderful mess. |
107 |
> |
108 |
> -- |
109 |
> William L. Thomson Jr. |
110 |
> Gentoo/Java |
111 |
> |
112 |
> |
113 |
-- |
114 |
gentoo-dev@l.g.o mailing list |