Re: enigmail with pgp 2.2.4

[Dmitry Gudkov]

thank you for being patient with super noobs like me
hope you will find some time to build those packages
in the meantime I'll keep on learning GnuPG
by the way distro-packaged 2.1.11 in /usr/bin/gpg2 and freshly compiled
2.2.4 in /usr/local/bin/gpg live peacefully together on my ubuntu 16.04
machine to date
however I don't get to do much with it so far except for encrypt/decrypt
correspondence and files, edit/export/import keys to other machines,
backup, etc.

regards,
Dmitry

On 05/03/2018 14:53, Peter Lebbing wrote:
> On 25/02/18 15:45, Dmitry Gudkov wrote:> i thought you forgot about me)
> 
> It's all a matter of free time and willingness. If I have 5 minutes and
> see a question I can quickly answer, I might do that. But if an answer
> takes a lot of time, it will have to wait.
> 
>> I have a confession to make, too. Not only I'm not a developer, but I'm
>> a fresh convert from os to linux).
> 
> Ah, welcome :-). Using software that was not provided by or specifically
> for your distribution is an advanced topic, so it's not surprising you
> might feel uncertain what to do at times.
> 
>> 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.
> 
> Well, building Debian packages is the best way to integrate into the
> Ubuntu ecosystem. But that doesn't mean it's the only good solution.
> Installing stuff into /usr/local is a time-honored Unix tradition. Many
> distributions will respect those traditions. I'm merely indicating that
> I'm not sure I'm giving 100% correct advice. But if I'm right, it should
> just work fine.
> 
>> 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)
> 
> It's not boring, it's time-consuming, that's the problem. I will not
> build packages for Ubuntu 16.04. As a matter of fact, I think interest
> in 16.04 will drop a bit in one and a half month :-). But if I can find
> the time for it, I might have a look at building those equivs-packages
> so you can use your local installation in /usr/local instead of the
> packaged version.
> 
> But I haven't found that time yet.
> 
> I did notice an old post on gnupg-devel that was replied to just now,
> where Phil Pennock says he's packaging GnuPG 2.2 for Ubuntu 16.04:
> 
> 
> But he's explicitly staying out of the way of the 2.1.11 offered by
> Ubuntu. That makes it more difficult to use for the end user. It seems
> wise when the system has 2.0 installed. But I think there's something to
> be said for going a bit further in the case of 16.04 and install a
> recent 2.2 for usage by the whole system. The system already has a 2.1+
> version, so anything that depends on gpg2 being 2.0 will already be
> broken; you can't break it any further anyway. And 2.1.11 has known bugs
> and deficiencies, and the fixes have not been backported by Ubuntu. It
> seems nothing but a win to replace it with 2.2.
> 
> Peter.
> 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Peter Lebbing]

On 25/02/18 15:45, Dmitry Gudkov wrote:> i thought you forgot about me)

It's all a matter of free time and willingness. If I have 5 minutes and
see a question I can quickly answer, I might do that. But if an answer
takes a lot of time, it will have to wait.

> I have a confession to make, too. Not only I'm not a developer, but I'm
> a fresh convert from os to linux).

Ah, welcome :-). Using software that was not provided by or specifically
for your distribution is an advanced topic, so it's not surprising you
might feel uncertain what to do at times.

> 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.

Well, building Debian packages is the best way to integrate into the
Ubuntu ecosystem. But that doesn't mean it's the only good solution.
Installing stuff into /usr/local is a time-honored Unix tradition. Many
distributions will respect those traditions. I'm merely indicating that
I'm not sure I'm giving 100% correct advice. But if I'm right, it should
just work fine.

> 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)

It's not boring, it's time-consuming, that's the problem. I will not
build packages for Ubuntu 16.04. As a matter of fact, I think interest
in 16.04 will drop a bit in one and a half month :-). But if I can find
the time for it, I might have a look at building those equivs-packages
so you can use your local installation in /usr/local instead of the
packaged version.

But I haven't found that time yet.

I did notice an old post on gnupg-devel that was replied to just now,
where Phil Pennock says he's packaging GnuPG 2.2 for Ubuntu 16.04:


But he's explicitly staying out of the way of the 2.1.11 offered by
Ubuntu. That makes it more difficult to use for the end user. It seems
wise when the system has 2.0 installed. But I think there's something to
be said for going a bit further in the case of 16.04 and install a
recent 2.2 for usage by the whole system. The system already has a 2.1+
version, so anything that depends on gpg2 being 2.0 will already be
broken; you can't break it any further anyway. And 2.1.11 has known bugs
and deficiencies, and the fixes have not been backported by Ubuntu. It
seems nothing but a win to replace it with 2.2.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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" etcet

Re: 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 sinc

Re: enigmail with pgp 2.2.4

[Dmitry Gudkov]

Hi Peter,

thank for your attention to this smallest problem of mine which I
wouldn't even hope to have your attention for to begin with)

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)

what a rewarding side effect of unwittingly breaking the housekeeping rules)

seriously now ...

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

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

do you think i still have a problem?


thank you

Dmitry



On 22.02.2018 23:17, Peter Lebbing wrote:
> On 22/02/18 18:10, Dmitry Gudkov wrote:
>> problem solved by configuring Enigmail to use the new gnupg location in
>> /usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
>> the default setting /usr/bin/gpg2)
> While my mind was idly mulling this over, I suddenly wondered if what
> you are doing is even supposed to work at all. I think perhaps you just
> haven't discovered the dire consequences of it yet.
>
> GnuPG 1.4 and 2.0 are co-installable, and will happily work installed on
> the same system.
>
> GnuPG 1.4 and 2.1+ are in the basis co-installable, but still can
> present you with issues like keyrings going out of sync or requiring
> careful crafting of configuration files, off the top of my head.
>
> But 2.0 and 2.1+ are definitely not co-installable. You can't have them
> both on the same system. Right now you put GnuPG 2.2 and its
> dependencies in /usr/local, but GnuPG 2.0 and its dependencies are still
> in /usr. Their dependencies might start to mingle.
>
> The only way in which this might work is if I misinterpreted "not
> co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
> an instance of "co-installation". But I don't think that's the case. It
> might also work by pure chance and break horribly on the next update.
>
> A solution, where GnuPG 2.1+ is statically linked against its
> dependencies, was discussed here:
> 
>
> Werner introduced the partial static linking in the just released 2.2.5.
>
>
> Oh, and by the way, a little housekeeping information... You started
> your thread on the mailing list by replying to a completely unrelated
> thread (wotmate: simple grapher for your keyring). Could you please
> start a new thread the next time? Just address a message to
>  instead of replying to an existing message.
> Those of us with a threading view of the mailing list now see it as
> somehow being a part of the "wotmate: simple grapher for your keyring"
> thread, but they bare no relation whatsoever.
>
> HTH,
>
> Peter.
>




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Peter Lebbing]

On 22/02/18 21:17, Peter Lebbing wrote:
> The only way in which this might work is if I misinterpreted "not
> co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
> an instance of "co-installation". But I don't think that's the case. It
> might also work by pure chance and break horribly on the next update.

I think I might be a bit dense, as this cropped up in the other thread
as well yet I again forgot to account for it.

See


Other programs on your system might pick up your /usr/local/bin/gpg and
start using it as if it were /usr/bin/gpg at version 1.4. This will
expose wrong assumptions in those programs, causing them to malfunction.
The thing about the partially statically linked version mentioned in

> 

is that it is in /opt, where your system will not use it unless very
explicitly configured to do so. In fact, I wouldn't even add it to your
own $PATH, because some other program you invoke might use it as well.

I notice that often when someone asks "I do this and it goes wrong, what
am I doing wrong", I will think "oh, this and that is what is going
wrong, do it like this" instead of "Wait, should you even be doing
that?" :-).

I don't think there is a fool-proof way to install GnuPG 2.1+ on a Linux
distribution that ships 1.4 and/or 2.0. It will always require being
cautious and knowing exactly what is using what. Luckily, if we as
end-users have a bit more patience, I think in the end all our
distributions will have done the hard work of fixing all of this for
you. I count myself lucky to be running Debian stable. For once, that
means I'm running a newer version than others! :-D

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Peter Lebbing]

On 22/02/18 18:10, Dmitry Gudkov wrote:
> problem solved by configuring Enigmail to use the new gnupg location in
> /usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
> the default setting /usr/bin/gpg2)

While my mind was idly mulling this over, I suddenly wondered if what
you are doing is even supposed to work at all. I think perhaps you just
haven't discovered the dire consequences of it yet.

GnuPG 1.4 and 2.0 are co-installable, and will happily work installed on
the same system.

GnuPG 1.4 and 2.1+ are in the basis co-installable, but still can
present you with issues like keyrings going out of sync or requiring
careful crafting of configuration files, off the top of my head.

But 2.0 and 2.1+ are definitely not co-installable. You can't have them
both on the same system. Right now you put GnuPG 2.2 and its
dependencies in /usr/local, but GnuPG 2.0 and its dependencies are still
in /usr. Their dependencies might start to mingle.

The only way in which this might work is if I misinterpreted "not
co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
an instance of "co-installation". But I don't think that's the case. It
might also work by pure chance and break horribly on the next update.

A solution, where GnuPG 2.1+ is statically linked against its
dependencies, was discussed here:


Werner introduced the partial static linking in the just released 2.2.5.


Oh, and by the way, a little housekeeping information... You started
your thread on the mailing list by replying to a completely unrelated
thread (wotmate: simple grapher for your keyring). Could you please
start a new thread the next time? Just address a message to
 instead of replying to an existing message.
Those of us with a threading view of the mailing list now see it as
somehow being a part of the "wotmate: simple grapher for your keyring"
thread, but they bare no relation whatsoever.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Dmitry Gudkov]

dear all,

thank you for your time and help

problem solved by configuring Enigmail to use the new gnupg location in
/usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
the default setting /usr/bin/gpg2)

 Dmitry

On 22.02.2018 19:14, Damien Goutte-Gattat wrote:
> Hi,
>
> On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:
>> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
>> [...]
>> *and all works fine in terminal*
>>
>> however after installing Enigmail I get this error
>
> You installed GnuPG 2.2.4 in /usr/local, but you still have an older
> version in /usr.
>
> Everything works fine in the terminal because your shell finds the
> newer /usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2
> (as you can see in the error message, which includes the exact command
> used to invoke gpg).
>
> You must configure Enigmail to use /usr/local/bin/gpg (in the
> "Preferences" dialog, "Basic" tab, override the default setting).
>




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Damien Goutte-Gattat]

Hi,

On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:

sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
[...]
*and all works fine in terminal*

however after installing Enigmail I get this error


You installed GnuPG 2.2.4 in /usr/local, but you still have an older 
version in /usr.


Everything works fine in the terminal because your shell finds the newer 
/usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2 (as you 
can see in the error message, which includes the exact command used to 
invoke gpg).


You must configure Enigmail to use /usr/local/bin/gpg (in the 
"Preferences" dialog, "Basic" tab, override the default setting).




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Peter Lebbing]

On 22/02/18 15:21, Dmitry Gudkov wrote:
> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local

That would mean that GnuPG is in /usr/local/bin/gpg

Yet:

On 22/02/18 11:04, Dmitry Gudkov wrote:
> Error - key extraction command failed
> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch
> --no-tty --status-fd 2 -a --export 0xFB417E72

So probably /usr/bin/gpg2 is the distribution-provided older version, hence your
issues.

You should probably configure all your GnuPG-using software to use
/usr/local/bin/gpg. Also, it might make sense to explicitly configure all those
tools to use a non-default GNUPGHOME. That way, should one of your tools
accidentally pick /usr/bin/gpg2, it will hopefully also pick the default
homedir, and not interfere with all your correctly-configured tools. This is
just an idea that occured to me and is completely untested. Then again, mixing
these versions with identical homedirs is tested and has failed the test, so I'm
hoping for a net improvement ;-).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Dmitry Gudkov]

Hi Werner,

yes, i am.

*I just manually compiled it on the fresh install of ubuntu 16.04 per
the below script:*

cd ~/Downloads
version=gnupg-2.2.4
wget https://gnupg.org/ftp/gcrypt/gnupg/$version.tar.bz2
wget https://gnupg.org/ftp/gcrypt/gnupg/$version.tar.bz2.sig
tar xf $version.tar.bz2
cd $version
sudo apt-get update
sudo apt-get install -y libldap2-dev
sudo apt-get install -y gtk+-2
sudo apt-get install -y rng-tools
sudo apt-get install -y libbz2-dev
sudo apt-get install -y zlib1g-dev
sudo apt-get install -y libgmp-dev
sudo apt-get install -y nettle-dev
sudo apt-get install -y libgnutls28-dev
sudo apt-get install -y libsqlite3-dev
sudo apt-get install -y adns-tools
sudo apt-get install -y libreadline-dev
sudo apt-get install -y qtbase5-dev
sudo apt-get install -y pinentry-gtk2
sudo apt-get install -y pcscd scdaemon
sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
speedo_pkg_gnupg_configure='--enable-g13 --enable-wks-tools' native
sudo ldconfig

# use nano to create a configuration file: nano ~/.gnupg/gpg-agent.conf
# add the line: pinentry-program /usr/bin/pinentry-gtk-2
# chmod 600 ~/.gnupg/gpg-agent.conf

*the result is the following:*

bereska@bereska-VPCZ21AGX:~/.gnupg$ gpg --version
gpg (GnuPG) 2.2.4
libgcrypt 1.8.2
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/bereska/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
    CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

*then I imported my existing keys for the other machine*

*and all works fine in terminal*

however after installing Enigmail I get this error when I try to attach
my public key to the message

thank you for your time to this matter

Dmitry




On 22.02.2018 16:19, Werner Koch wrote:
> Hi!
>
> On Thu, 22 Feb 2018 11:04, bere...@hotmail.com said:
>
>> gpg: skipped packet of type 12 in keybox
> Are you sure this if gpg 2.2.4 ?  The error looks more like this is a
> gpg version < 2.1.20.
>
> Type 12 are ring trust packets which are used internally by gpg.  The
> code which shows this error is 
>
>   /* Filter allowed packets.  */
>   switch (pkt->pkttype)
> {
> case PKT_PUBLIC_KEY:
> case PKT_PUBLIC_SUBKEY:
> case PKT_SECRET_KEY:
> case PKT_SECRET_SUBKEY:
> case PKT_USER_ID:
> case PKT_ATTRIBUTE:
> case PKT_SIGNATURE:
> ===>case PKT_RING_TRUST:
>   break; /* Allowed per RFC.  */
>
> default:
>   /* Note that can't allow ring trust packets here and some of
>  the other GPG specific packets don't make sense either.  */
>   log_error ("skipped packet of type %d in keybox\n",
>  (int)pkt->pkttype);
>   free_packet(pkt, &parsectx);
>   init_packet(pkt);
>   continue;
> }
>
> Thus a ring trust packet can't show this error.  Note that the comment
> in the default case is misleading.
>
>
> Shalom-Salam,
>
>Werner
>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Werner Koch]

Hi!

On Thu, 22 Feb 2018 11:04, bere...@hotmail.com said:

> gpg: skipped packet of type 12 in keybox

Are you sure this if gpg 2.2.4 ?  The error looks more like this is a
gpg version < 2.1.20.

Type 12 are ring trust packets which are used internally by gpg.  The
code which shows this error is 

  /* Filter allowed packets.  */
  switch (pkt->pkttype)
{
case PKT_PUBLIC_KEY:
case PKT_PUBLIC_SUBKEY:
case PKT_SECRET_KEY:
case PKT_SECRET_SUBKEY:
case PKT_USER_ID:
case PKT_ATTRIBUTE:
case PKT_SIGNATURE:
===>case PKT_RING_TRUST:
  break; /* Allowed per RFC.  */

default:
  /* Note that can't allow ring trust packets here and some of
 the other GPG specific packets don't make sense either.  */
  log_error ("skipped packet of type %d in keybox\n",
 (int)pkt->pkttype);
  free_packet(pkt, &parsectx);
  init_packet(pkt);
  continue;
}

Thus a ring trust packet can't show this error.  Note that the comment
in the default case is misleading.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpqL4ETYbFSz.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users