enigmail with pgp 2.2.4

[Dmitry Gudkov]

Hi Peter,

i thought you forgot about me)
thank you for your very detailed response

I have a confession to make, too. Not only I'm not a developer, but I'm
a fresh convert from os to linux). And it all started last year when I
stumbled upon gnupg just looking for a proper way to encrypt a flash drive)

Correct me if I'm wrong but the best conclusion I could make for your
letter is that unless I locally build a Debian package myself (the
epitome of thoroughness!), I can't be 100% sure everything works as it
should.

If that's the case. I do want to give it a shot but I doubt I can do it
without step-by-step guide without breaking something). I guess it must
be boring for you to dedicate more of your time on this, but I can't
help but asking to provide one for me in hope that there are some more
inexperienced GNU/Linux users on this mailing list who might be very
much interested in building the epitome of thoroughness themselves but
just too shy to ask for guidance)

respectfully,
Dmitry

On 25.02.2018 15:24, Peter Lebbing wrote:
> 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.
>


-------------- 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/7cd0ddb3/attachment.sig>