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.

Note: recent versions of pinentry-gtk-2 are using native widgets. If you are
using that program and not the latest version of pinentry, then please try that
first.

There is no version 2.0.22 of pinentry (the most recent version is 0.9.7). Can
you please figure out what version of pinentry you are using and which pinentry
program (there are five: pinentry-gnome3, pinentry-gtk-2, pinentry-qt,
pinentry-curses and pinentry-tty). Thanks!

gpg doesn't normally directly ask for a password. Instead, operations that
require a password are typically handled by gpg-agent, which is a small server
that is started on demand. (Normally, there is only a single gpg-agent per
user.) When gpg-agent needs a password, it invokes a pinentry program. The
default pinentry can be determined using `gpgconf --list-config'. This can be
overridden using the pinentry-program configuration option in gpg-agent.conf.
(If you change that file, you'll need to restart gpg-agent using something like
`gpgconf --reload gpg-agent'.)

There are several different pinentry programs: pinentry-gtk-2, pinentry-qt,
pinentry-curses and pinentry-tty. (pinentry is typically an alias that is
configured by the system's package manager.) Even if you use pinentry-gtk-2, it
will normally fall back the curses backend if there is no X display.

The issue you might be having is that pinentry might be showing up on a
different display / console.

So, I think this might just be a configuration problem. Nevertheless, I
encourage you to investigate some more and try to figure out what is going on
and report back here. Thanks!

on vacation, will test when I am home.

This should be fixed in acac103. (I was able to exactly reproduce your problem
and the patch fixed it for me.) If you are able to test and it works for you,
please report back here.

Thanks!

Note, tests work together with patch from T2253

Attached patch for gpg-preset-passphrase. eval_redirect code copied from
libassuna and modifies.
Second patch creates socked redirection for tests if neccesary

From looking at the strace in T2229 (t8m on Feb 02 2016, 10:32 AM / Roundup) it seems that the client died after
having seen the first PROGRESS line. The client in this case is
gpg-preset-passphrase which is an old hack and not a proper Assuan
client. It received the 'S PROGRESS' line but does not expect it and
returns an error.

We should re-implement that tool in terms of gpg-connect-agent and for
the test scripts use gpg-connect-agent directly. Justus is currently
reworking the test suite anyway.

Patch looks good, thanks!

Sorry, here it is.

D347: 767_0001-g10-Make-sure-to-have-the-directory-for-trustdb-v3.patch

I think you attached the original patch once again by mistake...

D348: 766_0001-g10-Make-sure-to-have-the-directory-for-trustdb-v3.patch

This would be final version.
If !create, we can let it return earlier.

You are right to have the check against CREATE.
I'll include that check.

I found the following comment above g10/keyedit.c' fix_key_signature_order
function, which is responsible for printing the "moving a key signature to the
correct place" lines upon --edit-key.

  /*
   * There are some keys out (due to a bug in gnupg), where the sequence
   * of the packets is wrong.  This function fixes that.
   * Returns: true if the keyblock has been fixed.
   *        
   * Note:  This function does not work if there is more than one user ID.
   */

When was the mentioned bug introduced and fixed? git blame tells me the comment
predates Thu Jun 5 07:14:21 2003 +0000, date when cvs2svn created branch
'GNUPG-1-9-BRANCH' (commit 72503314). But Lucas' key was generated much later,
on 2009-07-01.

Of the 100 keys with lowest MSD http://pgp.cs.uu.nl/doc/top_1000.html, 27 have
badly ordered packets; 26 of these have multiple UIDs; and only 20 of the 120
uids with a creation date have been generated before 2009-07-01.

Is there a technical reason which "This function does not work if there is more
than one user ID"? (I guess gpg could try to verify the sig against each
UID/UAT to find out which one it binds to.) Or is Luca's key (among many
others) broken from a WoT perspective due to the multiple UIDs?

D349: 765_0001-g10-Make-sure-to-have-the-directory-for-trustdb-v2.patch

Thanks for the patch, but it still needs a small change. You don't want to
create the directory or the lock file if the user specified --no-auto-check-trustdb.

How about this patch?

Please try attached patch.
While I understand it's a regression (and it's urgent for you), I downgrade the
priority.
It will be soon in the repo.

D350: 764_0001-g10-Make-sure-to-have-the-directory-for-trustdb.patch

Thank you for the report. Confirmed. It was my mistake, I didn't test the code
path with no homedir.