enigmail with pgp 2.2.4

[Peter Lebbing]

On 22/02/18 21:50, Dmitry Gudkov wrote:
> my bad, I should have started a new thread, well noted
> 
> on the other hand that's probably why I suddenly had all the big gnupg
> minds helping me)

Hehe, I think this is all just pure chance, it depends who has the time
to read and respond. I don't think it's related to threading. What does
make a difference, possibly a large one, by the way, is when the
question is accompanied by much useful contextual information. If I'm
reading a mail here and can already get a long way towards the solution
by all the information in a question, I'm more inclined to respond then
when my response would still be asking a lot of questions back. But this
is just some general musing on my part. And it is also unrelated to your
specific mail, it's a general observation.

And by the way, my knowledge of GnuPG is not exceptional, I'm not a
developer, just an enthousiast who has made it a hobby to try and help
people here on the list :-).

> seriously now ...

Yes, let's :-).

> it was a fresh ubuntu 16.04 install
> 
> it came with gnupg 1.4.20 and 2.1.11
> 
> i compiled gnupg 2.2.4

Ah! I see. I didn't know or had forgotten that Ubuntu 16.04 forked
Debian at a time when the gnupg2 package was a 2.1. AFAICT, looking at
.deb files, /usr/bin/gpg is GnuPG 1.4 from the gnupg package and
/usr/bin/gpg2 is 2.1 from the gnupg2 package in Ubuntu, which
corresponds to what you say.

Now let's list problems and solutions:

- Programs invoking "gpg" (or explicitly /usr/bin/gpg) expect it to be a
1.4 installation.

This should be fixed by having your locally installed GnuPG 2.2.5
provide a "gpg2" binary, not a "gpg" binary:

./configure --enable-gpg-is-gpg2

(include whatever other configure options you want, but also include
that one).

Since it requires recompilation, let's pick the latest and greatest
2.2.5 :-).

Since in Ubuntu 16.04, anything invoking "gpg2" or "/usr/bin/gpg2" is
either working with a 2.1 version or is not working as shipped by the
distribution, you won't create more breakage (anything working with 2.1
should work with 2.2).

- You have a GnuPG 2.1.11 in /usr/bin/gpg2 and a 2.2.4 in
/usr/local/bin/gpg2. A similar situation occurs with any locally
compiled libraries and stuff.

The best solution would be to create Debian packages yourself, based on
the Ubuntu packaging but utilising the latest GnuPG 2.2 instead of the
2.1.11 of Ubuntu that was last updated 2 years ago (on 8 April 2016, to
be precise) and contains known bugs.

That is some work, but doable. It requires looking at how Ubuntu
packaged it, and create something equal but using a vanilla 2.2.5
instead of a 2.1.11 with backported fixes. Well, with a 2.1.11 that had
backported fixes 2 years ago. I think it's unfortunate they stopped
backporting fixes once they released 16.04.

I'm not 100% sure about other good solutions. I think it's not a good
idea to have 2.1.11 in /usr and 2.2.5 in /usr/local. But if it works for
you, you could see if it keeps working for you. I'll come back to this.

Another solution is installing the stuff in /usr/local like you did, but
with some additional actions:

Make sure everything has /usr/local/bin in its PATH and ld.so is looking
for libraries in /usr/local/lib. On Debian, I think this is already in
place.

And then replace the gnupg2 package, the gpg-agent package and all the
others for which you just installed a /usr/local package by an equivs
package. Just have a look at each file you installed in /usr/local with
your local compile, and do something like:

You see:
/usr/local/bin/gpg2

You inquire:
dpkg -S /usr/bin/gpg2

And dpkg tells you it is part of package gnupg2, so you need to build an
equivs for that. Etcetera.

Install the "equivs" package. Read its manual, and create packages named
"gnupg2" etcetera. Replace all real Ubuntu packages by these dummy
equivs package.

What did I just propose doing?

I don't like the situation where there is a full real GnuPG in /usr and
another one in /usr/local. The one in /usr might interfere with what you
intend with the one in /usr/local. But you can't just deinstall the
Ubuntu packages, because stuff depends on it. It would force
deinstallation of all packages depending upon gnupg2, gpg-agent etcetera.

With equivs, you can build an empty package. It doesn't install anything
in /usr, so there will no longer be a /usr/bin/gpg2 at all. But any
package that depends on "gnupg2" will see the empty equivs package named
"gnupg2" and be happy that it is installed.

I have done this myself with other packages, but never with GnuPG.

> it worked just fine in terminal and after configuring Enigmail with the
> new gpg location works there as well

You could just see if it gives you any issues. I'm slightly worried
about silent issues, though, where you think everything is working fine
but it is failing in some subtle but nefarious way. I'm also slightly
worried about the 2.1.11 Ubuntu 16.04 users have installed, which hasn't
seen any maintenance since Ubuntu 16.04 was released two years ago.

> do you think i still have a problem?

It is your decision how thorough you wish to be. IMO, a true locally
built Debian package is the epitome of thoroughness ;-).

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180225/23ae3cc5/attachment.sig>