enigmail with pgp 2.2.4
bereska at hotmail.com
Sun Feb 25 15:45:38 CET 2018
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
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)
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
> 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:
> 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 ;-).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users