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.

Okay, so I can backport this to 2.0 ?

I tried the patch and the problem hasn't shown up for me after an hour of
continuously running the test suite, so it looks fixed! Thanks for the fast
turnaround on this tricky problem.

It has been there since the 21.1 release. The relevant commits are:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b021ef186f6062705a29ae8e3840ad32db451811
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=719349f6d0e464d4f71963b87f6bfa08ac630aa7

By "all zero", I mean that a limb can be with bits of all zeros, so that e =
ep[i] can be zero.

D359: 783_mpi-pow-normalize-expo.diff

Thank you very much. It is reproducible for me, too. I located the issue.
I think that it is reproducible for any libgcrypt (even < 1.5.3).
With the patch attached, problem seems to be gone.
Problem is that the DH exchange introduced in the commit fc4a969a in libssh2,
the EXPO argument is coming without normalization, so, count_leading_zeros
results undefined value on IA-32.
In libssh2, it's random bytes, so, it can be all 0.

A couple more point: openssh must be installed on the system so the test suite
will work. Also, the problem seems to have started in commit fc4a969a in libssh2.

This recipe generally causes a hang within no more than 5 minutes of running
through the test suite on my system. libcrypt is assumed to be installed in the
normal location, or set PKG_CONFIG_PATH appropriately. Run "src/curl --version"
to make sure it says libssh2/1.7.0_DEV to prove it's picked up the right libssh2
and "ldd src/.libs/lt-curl" to make sure it's using gcrypt.

git clone https://github.com/libssh2/libssh2.git
cd libssh2
./buildconf
./configure --prefix=/tmp/install --with-libgcrypt
make -j6 && make install
cd ..
curl -O https://curl.haxx.se/download/curl-7.47.1.tar.lzma
tar xaf curl-7.47.1.tar.lzma
cd curl-7.47.1
PKG_CONFIG_PATH=/tmp/install/lib/pkgconfig ./configure --enable-debug
--without-ssl --with-libssh2
make -j6
while true; do make -j6 test TEST_Q='-a -p -n SFTP SCP'; done

Hi,

I've looked at the code and everything seems finde there. Config file is read
and if the entry is set the installation section is unselected.

To verify it works:
I've uninstalled gpg4win on a testsystem (Win 10 32 bit but that should really
have no influence at all)

• Verified that GpgOL was unregistered and did not show up in outlook
• Closed outlook
• Installed Gpg4win from the command line: C:\Users\aheinecke>C:\Users\aheinecke\Downloads\gpg4win-2.3.0.exe /S

/C=C:\Users\aheinecke\Desktop\gpg4win.ini

The Gpg4win.ini was minimal and only contained one line:
inst_gpgol=false

-> Confirmed that GpgOL.dll is not installed in the installation direcotry.
-> Confirmed that GpgOL does not show up in Outlook.

Then I've downloaded the gpg4win.ini you've uploaded here and tried again with
that. Still everything works as expected. No GpgOL is installed and it does not
show up in Outlook. Then I've changed inst_gpgex to false in your ini and tried
again and confirmed that GpgEX is also not installed. (Just to verify that
really that file is used.)

Is there something special with the Path where you have the gpg4win.ini ? E.g.
Is it on a Network directory? (This might fail with windows UAC) or does the
Path contain spaces?

Regards,
Andre

@ueno: This is reasonable. Thanks for the explanation. Do you happen to know
approximately what version started to enable these protections?

Tested this with keybox and it appears to be working. When running a keylist
while importing the import holds for a bit and continues after the keylist.
Not tested this with keyring yet.

xyzspeedy wrote to me that the behaviour is reproducable with
Windows 7, 8.1 and 10 (each time pro x64)

If it is difficult for you to minimize your test case, as long as it is
reproducible, please let us have your test case. We'll try to figure out the bug.

D315: 782_0001-doc-Make-Emacs-frontend-description-more-accurate.patch

Thanks for writing this up, Neal. However, I found the claim a bit
inaccurate by now. I am attaching a proposed fix for this.

Emacs keeps all key presses buffered.
(You can see the recent key presses by typing @code{C-h l}
(@code{view-lossage}) in emacs.)

This is not the case with the common `read-passwd' function, which
clears the log on every key press. See:
http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/subr.el#n2126

Because of this concern, Emacs doesn't
enable this by default (the user has to run @code{(pinentry-start)},
e.g., from his or her @code{.emacs} file, explicitly).

This is no longer true. Emacs checks the allow-emacs-pinentry option
of gpg-agent, and start it if desired.

Further, Emacs is a huge program,
which doesn't provide any process isolation to speak of. As such,
having it handle the passphrase adds a huge chunk of code to the
user's trusted computing base.

Yes. However, all official packages on elpa.gnu.org are digitally
signed and supposed to work courteously. Users can still use unsigned
or 3rd party packages, but I think it is similar to the situation
where distribution packages are used.

In conclusion, I would say the Emacs pinentry provides the same level
of security as the current pinentry-gtk2 (as long as the
implementation is sane). My only concern was that Emacs `read-passwd'
is implemented in Elisp and thus cannot use secure memory. However,
it is also true for pinentry-gtk2, which uses the default GtkEntry
now.

Thanks! I'm mark this as resolved.

I've pushed a slightly different version of this patch (2d1d795). Please test
not only that --edit-key detects duplicates and reorders out of place
signatures, but also that revocation certifications, self-sigs, etc. are
correctly checked. Thanks!

Andre,
let us fix this for 2.3.1.

D363: 781_gnupg_test_with_portable_shell_commands.patch

D362: 780_gnupg_do_not_run_gpgtar_test_when_not_built.patch

Yes, that patch fixed the problem for me.

Note that we need a 64 bit Libgcrypt for a 64 bit GpgOL. Thus checking that
rndw32.c works proberly on 64 bit Windows will soon be important.

I can't show you math proof at hand, but I'm confident enough J can't be negative.
This implementation of mpi_powm was introduced in October 2013.

libgcrypt 1.5.3 was the one with old implementation.

D361: 779_npth_broken_sem_init.patch

The code that's failing is single threaded and passes valgrind, address sanitizer
and undefined sanitizer tests. I can't think of how the stack could be corrupted
from outside the routine, except perhaps that a signal handler is involved. If
you're confident that j could never be negative in the normal case, then I'll try
tracking down how that could happen.

Thank you for your experiment.
I suspect other cause(s). In the code itself, there is no possibility J can be
negative. However, it could be possible, in practice, when the stack is
corrupted because of wrong allocation of memory or by other threads.

The branch neal/issue2236 contains an initial fix. It does two things:

• It identifies duplicate signatures (based on their message digest) and removes

duplicates.

• Instead of blindly moving signatures around, this systematically tests each

signature against its alleged component (= primary key / subkey / user id) and
if it is bad, it tries the other components in the key block and moves it if
appropriate. (If it doesn't belong to any components, then the sig is just left
where it is and GnuPG will ignore it).

I've tested this with a few keys and it seems to work well. Lucas' key just has
a lot of duplicate signatures.

Starting program: /home/us/neal/work/gpg/build/gnupg/g10/gpg2 --check-key
0x06EAA066E397832F
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: WARNING: unsafe permissions on homedir '/tmp/luca'
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Ignored 852 duplicate signatures (total: 2079).
gpg: public key E397832F: timestamp: 2009-07-01 14:44:59 (1246459499)
gpg: user id: Luca Capello <luca@pca.it>
gpg: sig: class: 0x10, issuer: 109E6244, timestamp: 2013-02-05 02:24:16
(1360031056), digest: eb c3
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2009-07-01 14:44:59
(1246459499), digest: 93 7a
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2009-07-01 14:58:17
(1246460297), digest: 53 4f
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2010-10-10 21:44:51
(1286747091), digest: be d5
gpg: Good signature over last major component!
gpg: user id: Luca Capello <gismo@debian.org>
gpg: sig: class: 0x10, issuer: 109E6244, timestamp: 2013-02-05 02:24:16
(1360031056), digest: 4e 92
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2009-07-01 14:57:12
(1246460232), digest: 9c 3d
gpg: Good signature over last major component!
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2010-10-10 21:52:18
(1286747538), digest: 54 c1
gpg: Good signature over last major component!
gpg: user id: Luca Capello <luca.capello@infomaniak.ch>
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2016-01-24 14:44:42
(1453646682), digest: 79 a4
gpg: Good signature over last major component!
gpg: user id: Luca Capello <luca.capello@infomaniak.com>
gpg: sig: class: 0x13, issuer: E397832F, timestamp: 2016-01-29 22:49:59
(1454107799), digest: 43 19
gpg: Good signature over last major component!
gpg: subkey 2BB95F4B: timestamp: 2009-07-01 14:55:55 (1246460155)
gpg: sig: class: 0x18, issuer: E397832F, timestamp: 2009-07-01 14:55:55
(1246460155), digest: 4b d9
gpg: Good signature over last major component!
gpg: subkey 3BE9F36D: timestamp: 2009-07-01 15:09:03 (1246460943)
gpg: sig: class: 0x18, issuer: E397832F, timestamp: 2009-07-01 15:09:03
(1246460943), digest: c2 f9
gpg: Good signature over last major component!
gpg: Couldn't check 1216 signatures due to missing issuer keys.

Interestingly, your key contains a bad signature (the hash has been corrupted).

The reason that I haven't pushed this to master is that I need to work our how
the output should look. Also, this functionality will probably only be
available via the --edit-key menu. This patch includes an argument --check-key,
which will probably be removed.

If you have an opportunity to test this, I'd appreciate it.

I tried doing exactly that, but it didn't reproduce the problem. I assumed that
either the internal representation of the input values set up in my test program
with gcry_mpi_scan() and gcry_mpi_set_ui() subtly differed from the ones
encountered in production, or there was some code path that uses an uninitialized
variable, but I don't know if either theory could be the case.

When you get negative value for J on entry of the for loop, you can examine four
arguments to _gcry_mpi_powm. And then, you can write standalone program to
emulate it. Debugger or printf.

In what condition can J can be initialized < 0?
Do you have some idea?

Thanks for debugging this. An alternative for your patch would be to use
es_fileno_unlocked but your idea is also fine.

I reported this to the libsecret maintainers, but it turns out that it was our
bug. Stef kindly replied a patch, which I've now applied (2f5bfa0). Looking
again at dkg's original message, he doesn't suggest that the problem is with
libsecret, but in fact correctly identified pinentry at the culprit.

Thanks for writing the report - that is better than having your report ticked
only in my mail folder.

see attached, this is a part of gpg, enter password, I need to be able
to paste into that field. Nobody seems to know how to fix this!

I'm not using pinetry, it is part of the pgp software. just trying to
get to the bottom of this. I am a user, not a programmer. Pinetry just
makes the popup that's asking for the password. I attached a screenshot
of it.

Given how trivial the fix is, I applied that.