Sorry, I was using --check-trustdb as a shorthand for the actual function.

I think that I fixed this issue in master. If you have time, please test, from
git repo.

bkuptocard had been not implemented, but it was finally implemented in 2.1.11.
If any problem, please let us know.

I cannot reproduce this with current master and a Yubikey4. Can you please
retry with the current master?

Also, are you sure that you are not mixing GnuPG components you compiled with
the ones provided by your operating system? Also, what made you try to compile
GnuPG in the first place?

Please open a separate bug for the other issue. No 'by the way's in bug reports
please.

Fixed in eea139c.

On Sunday 06 March 2016 at 15:18:54, Neal Walfield via BTS wrote:

is for --check-trustdb

Thanks for reporting this. The right solution is for --check-trustdb to ignore
legacy keys.

If i remove the com-certs I get the exact same behavior as I'm seeing on windows.

aheinecke@esus ~/a/e/src> export GNUPGHOME=$(mktemp -d)
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keybox '/tmp/tmp.hyElMR6oUi/pubring.kbx' created
aheinecke@esus ~/a/e/src> gpg2 --import
~/arbeit/gpg4win/zertifikate/testuserA-pub.asc
gpg: /tmp/tmp.hyElMR6oUi/trustdb.gpg: trustdb created
gpg: key 6CFBC912: public key "Test UserA <testusera@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keydb_search failed: Invalid argument

From the debug output it looks to me that gnupg is using keyring functions to
work with the keybox.

I can reproduce this now without Kleopatra and on GNU/Linux:

export GNUPGHOME=$(mktemp -d)
gpgsm -k

< imports /opt/gnupg/share/gnupg/com-certs.pem >
(this is not done on windows so maybe the errors differ because of that)

gpg2 --import ~/arbeit/gpg4win/zertifikate/testuserA-pub.asc

Result:

gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_get_keyblock failed: Value not found
gpg: [don't know]: invalid packet (ctb=00)
gpg: /tmp/tmp.f5ub2ZRYC0/pubring.kbx: copy to
'/tmp/tmp.f5ub2ZRYC0/pubring.kbx.tmp' failed: Invalid packet
gpg: error writing keyring '/tmp/tmp.f5ub2ZRYC0/pubring.kbx': Invalid packet
gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_search failed: Invalid packet
gpg: key 6CFBC912: public key "[User ID not found]" imported
gpg: [don't know]: invalid packet (ctb=00)
gpg: error reading
'/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc': Invalid packet
gpg: import from '/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc'
failed: Invalid packet
gpg: Total number processed: 0
gpg: imported: 1

gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.7.0-beta307

I'll try now with git master.

The debug output from gnupg for an import that caused a corruped keybox.

It's not for the attached pubring.kbx but I have the file that was generated If
you need it.

What I did in the log was to start kleopatra (The output of process is 2428 is
likely the debug output of the initial keylisting kleopatra did)

Then imported a test key and afterwards closed kleopatra.

Fixed in ec412b9d.

Fixed in c7cb4008. This will take effect next the web site is published.

This is a feature of the org-mode export. I'm looking into this.

Yes you are using pinentry, and we need to know what kind of pinentry (there are
several flavors) and which version you are using in order to help you.

Please do 'pinentry --version' and report the output.

To see whether this pinentry is the one you are using, or to play around with it
and the variants, you can do:

echo -e "SETDESC Does this look like your pinentry window?\nGETPIN" | pinentry

You can try replacing pinentry with pinentry-qt for example.

D344: 787_fix-2235.patch

I believe your problem is fixed in 9f0ba508. With that change I was able to
build gnupg-2.1.11 using speedo in a very minimal Debian jessie chroot.

To test this change, please apply the attached patch (generated using 'git diff
gnupg-2.1.11 dirmngr/Makefile.am' from gnupg master).

If the problem persists, feel free to reopen this bug.

That particular problem is fixed in 9a1778ab. Can you be more specific on the
other problem(s)?

Thanks for the patch, but I decided to fix it by skipping the test instead.

Fixed in a883d4c0.

The reason that we encrypted the SED packet with AES256 is that is the preferred
cipher in my public key. I think that the cipher for the s2k function should be
chosen similarly.

Merged, thanks!

Fixed in 3e1b451c.

I could reproduce this with gnupg-2.0.29. I will have a look.

Hi Arthur,
sorry for the late reply:

Outlook 2010 has new code for supporting OpenPGP and S/MIME,
we will tackling the problem differently there.
I think that the last code for GPgOL for Outlook 2007 uses
encryption.

If this is still relevant for you: Can you retest?

Hi,

as the extended support period of Outlook 2003 ended in 2014,
we will not get around fixing this for Outlook 2003.

Please open a new issue, if you encounter problems with a more recent version.

Best,
Bernhard

Since the last activity on this report, GpgOL was changed a lot.
Probably the original reporter does not use the Windows/Outlook combination
anymore. Thus closing this report.

awk --version
GNU Awk 4.1.1, API: 1.1 (GNU MPFR 3.1.3, GNU MP 6.0.0)
Copyright (C) 1989, 1991-2014 Free Software Foundation.

Running the filter from the CLI: nothing happens.
root@/home/actionmystique/Program-Files/Ubuntu/GnuPG/git-libgpg-error# awk
'/^\"POT-Creation-Date:/&&!s{s=1;next};!/^#: /{print}'

^C

Ibraheem very kindly tested again. However, it is still not working completely.
He writes:

It's still core dumping... Out of curiosity, I explicitly defined

'USE_DOUBLE_FOR_ALIGNMENT 1' and the checks were passing on Solaris with no more
core dumps. I guess that means they're on the right track, just have to get the
preprocessor directives right for gcc and Solaris.

Full details are in
https://mail-index.netbsd.org/pkgsrc-users/2016/03/01/msg023078.html

Running from the command line with gawk and mawk, I don't get an error message.
What version of awk are you using? Does this occur when triggering this from
the command line or only when running it from smartgit?

Thank you for clarification. I didn't know that pkgsrc supports other
platforms. Now, I understand.

I changed more:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=34b07146bbb0863436fc9381a84314b18bdfb807;hp=49655fb6ef39b307787e1b6e00c996f9c7db64f7

The intention is that USE_DOUBLE_FOR_ALIGNMENT for Solaris 32-bit version.
I thought that checking ILP32 worked (but not, in fact). I believe that LP64
checking works (at least with GCC).

Ah nevermind, gpg-agent should probably do cleanups on shutdown to avoid leaking
secrets in memory. So TerminateProcess is no good for this. :-(

I wonder though, how is such a cleanup handled currently on Windows? E.g. If a
user logs out. I would expect some kind of Window Message support but I don't
see any. Only some dead / dummy code in w32main.c.

Werner: Is there a good reason that gpg-agent has to be called with
gpg-connect-agent?

I see several problems with that:

• Multiple Agents in different homedirs. Not really a real world problem but

happens regularly for me in testing.

• Wasting time if no agent is running as it starts an agent just to quit it.
• Multiple users.

And if this fails we can't really handle the error anymore in Gpg4win as we just
call the gnupg-2.1 installer as a subprocess and won't see it if that installer
want's the user to restart.

Do you strongly object to just calling a TerminateProcess on all gpg-agent's we
can access in the uninstallation? This would remove that window and work more
robustly imo.

I've started doing this for GPA and Kleopatra in gpg4win (rev. 929ebdc5-929d94b)
Should I write a similar patch for the GnuPG-2.1 installer?

I'm working on pkgsrc, which is a portable packaging system origination on
NetBSD. I myself work mostly on NetBSD.

However, we have patches for non-NetBSD platforms in pkgsrc, and this patch was
worked on by the two people mentioned earlier. Since I can not test on Solaris,
I asked them to test on Solaris, and Ibraheem did that.

I hope that clears it up.

Let me clarify/confirm. Does it work on Solaris? And now do you speak for NetBSD?
My fix is specific to Solaris (no matter if it's Sparc or not). It doesn't
handle any issues for NetBSD.

I seems that Sparc GNU/Linux doesn't have this alignment issue, but (for me) it
is highly likely that sparc architecutre requires the alignment of 8-byte.

Thank you for the patch.
I don't have the environment, but I asked the original reporter to test.
Sadly, his reply is negative, see:

https://mail-index.netbsd.org/pkgsrc-users/2016/02/27/msg023071.html

Thanks for looking at it. I'll let you know if I find a workaround.

On Friday 26 February 2016 at 11:45:07, xyzspeedy via BTS wrote:

We think, there ist a Problem in the Oulook-(Plugin)-Config on the tested
Systems, but i'm not sure,

Hi,

If Gpg4win was already installed a new install with inst_gpgol=false will not
uninstall it. For this you have to uninstall first.
(With the upcoming gpg4win-3.0.0 we are changing that and are always calling
uninstall first on update.)

You can disable an installed GpgOL by setting the registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\GNU.GpgOL]
"LoadBehavior"=dword:00000000

As this can be overridden on a user level you might also want to check the same
key in HKEY_CURRENT_USER context.

With regards to the crashes. I'm sorry to hear that. We had an extremely nasty
bug that could cause random crashes unrelated to crypto operations ( T1837 )
that bug was only fixed with gpg4win-2.3.0.

Regards,
Andre

Hello Andre,

i think, we can close this Ticket, You're Right.

But:
We have tested on more than five Systems with the attached INI and with

[gpg4win]
inst_gpgol = false

Call: gpg4win.exe /S /C={path}\gpg4win.ini (local or Network)

But gpgOL was installed an all Systems.

Then - after reading your Post - we tested on fresh Systems with Outlook 2013:
In all INI-Variations with 'inst_gpgOL=false', gpgOL was NOT installed.

We think, there ist a Problem in the Oulook-(Plugin)-Config on the tested
Systems, but i'm not shure, what we can do but not creating new Profiles.
I don't know, why the gpgol.dll ist installed on the mismatched
Outlook-Configurations. On fresh Systems 'inst_gpgol=false' works.
December 2015 up to January 2016, Outlook 2010 and 2013 running very
instable (crash one to five times per day) - with or without pgp.

When we have an answer from our Side, we tell you.

Greetings,
Joachim

Thank you for your report. Yes, it is the alignment issue.

Please try:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=5168b97fb5e2eebdc99b40f96f9b6289647e87d2

Reading the report, it seems for me that there is nothing we can do as GnuPG Team;
When poll/select returns 0 for /dev/random, it is natural for GnuPG (or any
applications) to wait.
If it is Solaris 10 kernel which changed the behaviour of /dev/random, it should
be fixed or it is better (for us) to know some way to workaround this change.

Fixed in
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=5168b97fb5e2eebdc99b40f96f9b6289647e87d2

Please test.

I assume that this patch solved the problem. Thanks for reporting!

Hi Neal,

Thanks for the patch, works great on the couple of keys I tried it on.
Unfortunately I'm unsure how to build OpenPGP keys with deliberately wrongly
ordered packets, so my tests are probably not exhaustive :-( But looking at
your code (from an outsider's perspective), I can't see how revocation
certificates etc would be handled differently from certificate signatures.

I found two issues though:

+ ndataa = pubkey_get_nsig (a->pubkey_algo);
+ ndatab = pubkey_get_nsig (a->pubkey_algo);

I guess it should be "b->pubkey_algo" on the second line.

Also, since the "check" command of the GnuPG prompt can modify the keyblock, it
should set "modify" accordingly:

-8<----------------------------------------------------------------------------------->8-
diff --git a/g10/keyedit.c b/g10/keyedit.c
index d7c2a4b..ede350a 100644

• a/g10/keyedit.c

+++ b/g10/keyedit.c
@@ -2190,8 +2190,9 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t
locusr,

         break;

       case cmdCHECK:

• check_all_keysigs (keyblock, count_selected_uids (keyblock),
• !strcmp (arg_string, "selfsig"));

+ if (check_all_keysigs (keyblock, count_selected_uids (keyblock),
+ !strcmp (arg_string, "selfsig")))
+ modified = 1;

         break;

       case

cmdSIGN:-8<----------------------------------------------------------------------------------->8-

I understand that by default only selfsigs are reordered for performance
reasons. May I suggest to also consider the key to sign with (for instance
specified with "--local-user")? This can be useful, otherwise in order to avoid
potential duplicates signers might have to type "check" before signing a key.

Also (repeating what we discussed about on IRC so it gets indexed on the web :-)
Due to the append-only nature of keyservers, an uploaded badly ordered key
can't be fixed on the keyserver. As a consequence, with the current algorithm
each refresh would undo fixing the packets' order and removing the duplicates.
Ideally keys would be reordered upon import, and the merge algorithm would avoid
duplicate (for instance it could assume the local copy to be properly ordered,
and not add a packet to the local copy if said packet was found elsewhere on the
keyblock).

For what it's worth, with the following trivial patch the decryption works:

diff --git a/sm/decrypt.c b/sm/decrypt.c
index a560272..aa6e874 100644

• a/sm/decrypt.c

+++ b/sm/decrypt.c
@@ -74,9 +74,9 @@ prepare_decryption (ctrl_t ctrl, const char *hexkeygrip, const
char *desc,

    log_printhex ("pkcs1 encoded session key:", seskey, seskeylen);

  n=0;

• if (seskeylen == 24)

+ if (seskeylen == 24 || seskeylen == 16)

{

• /* Smells like a 3-des key. This might happen because a SC has

+ /* Smells like a 3-des or AES key. This might happen because a SC has

          already done the unpacking. */
     }
   else

I am not sure this is a good solution, though, it is probably better to somehow
pass along the information whether the padding is already stripped or not.

Kind regards,

Lorenz

I've tested it with pubring now too and it works.
Justus mentioned in jabber that he noticed some more errors after this patch in
the scheme tests. I've not tried them.

It should indeed be identical on all platforms.
iirc, the orginal request for that feature was to make allow the default.