Re: Parallel decrypts fail in 2.1.19

[Michael Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> Can you please check which version of libgcrypt the agent is linked to?

$ otool -L $(type -P gpg-agent)
/usr/local/bin/gpg-agent:
/usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib (compatibility
version 22.0.0, current version 22.6.0)
/usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib
(compatibility version 23.0.0, current version 23.0.0)
/usr/local/opt/libassuan/lib/libassuan.0.dylib (compatibility
version 8.0.0, current version 8.3.0)
/usr/local/opt/npth/lib/libnpth.0.dylib (compatibility version
1.0.0, current version 1.5.0)
/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility
version 10.0.0, current version 10.5.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1348.28.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0,
current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1238.0.0)

> Are you building GnuPG yourself?

I first encountered the problem with the Homebrew binpkg. I also
rebuilt libgcrypt and gnupg using brew install --build-from-source.
The behavior has been consistent.

On Mon, Mar 27, 2017 at 7:10 AM Justus Winter <jus...@g10code.com> wrote:
>
> Michael Smith <micha...@syapse.com> writes:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >> Libgcrypt has the fix for the secure memory.  Thus the above should not
> >> happen unless you have set an ulimit.  Are you sure that the running
> >> gpg-agent is up-to-date?
> >>
> >>gpg-connect-agent 'getinfo version' /bye
> >
> > $ gpg-connect-agent 'getinfo version' /bye
> > D 2.1.19
> > OK
> >
> > I am on a MacBook Pro and haven't changed any defaults related to
> > ulimits, but I'll take a look.
> >
> >> We need to have a test case to replicate and valgrind the problem.
> >
> > How can I help further to create a test case?
>
> Can you please check which version of libgcrypt the agent is linked to?
> E.g. by using 'otool':
>
> $ otool -L repos/gnupg/obj/agent/gpg-agent
> repos/gnupg/obj/agent/gpg-agent:
> /Users/justus/local/lib/libgcrypt.20.dylib (compatibility version 
> 22.0.0, current version 22.3.0)
> /Users/justus/local/lib/libgpg-error.0.dylib (compatibility version 
> 21.0.0, current version 21.0.0)
> /Users/justus/local/lib/libassuan.0.dylib (compatibility version 
> 8.0.0, current version 8.3.0)
> /Users/justus/pkg/lib/libnpth.0.dylib (compatibility version 1.0.0, 
> current version 1.5.0)
> /Users/justus/pkg/lib/libiconv.2.dylib (compatibility version 8.0.0, 
> current version 8.1.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
> version 1238.0.0)
>
> Are you building GnuPG yourself?
>
> Justus
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEFENfcrF4GOcIc0u0oCVjgPWyEDgFAljZDWMACgkQoCVjgPWy
EDh3yA/+IPvavITIZUkQ1nYEUTy7FcaCgD7AhOavj38iLE7anqr83I0PhbO1roCt
nCbyMnQGhqXqRGPm3lyHbi3qCOgDS4OfMQfzeMXMH51HIs0uQVPlOj2BQ3bS5qrw
8IXOAlTA8ZnsB7HrM+bSMKm3/o8dqo24tU2YJAJHu4sDczmNb7wIZ7Yh4TnrJjMe
PMYiDHytlAjVvbuVsH+P1pmxLUnN6h7Udnsp8Gkq1KLu9e7Xqlit0fOGo3+yTRIK
sc7GXCfEt3OFdkFI5R6xt+++qFuMgGrupTV54MAEL+lNBr1UFrdUBWmANz91lP83
LHYRE0nHuextdnI0fD2dy4+S+ToaFSG2elom/CwonfFRds5FI9aExDGUE0MfzmJ6
AFcgduHRtn6UVfbVKKki2MIDEaVlweL33kaUaPACo5RIFt3vo7MnFCuMhe01/Oci
aApWrikrWIrBfU6GqUCvKxmRkdhWZxFLXxzzHtZ6D9LdvQD3+1fhtEgKwD0waNQm
7Pc3vxdektXbq6xtwK2N/ScvpRFhu57hMuO3GDPyi5NPnGapLC+eshPA2B+C2X22
qHWnilXuS0rp3nUdzB/2RgT20wvF8WDe8Edt3RQmh1CKmofeFCM32Kr0cFOPkl+R
wL8w5hCFaqu5fA9aKOukenAWYpvlBcig7UJU2woyfeN+10gGHnU=
=Z0rQ
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Parallel decrypts fail in 2.1.19

[Michael Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> Libgcrypt has the fix for the secure memory.  Thus the above should not
> happen unless you have set an ulimit.  Are you sure that the running
> gpg-agent is up-to-date?
>
>gpg-connect-agent 'getinfo version' /bye

$ gpg-connect-agent 'getinfo version' /bye
D 2.1.19
OK

I am on a MacBook Pro and haven't changed any defaults related to
ulimits, but I'll take a look.

> We need to have a test case to replicate and valgrind the problem.

How can I help further to create a test case?

Thanks,
Michael

On Thu, Mar 23, 2017 at 1:29 PM, Werner Koch  wrote:
> On Thu, 23 Mar 2017 02:32, micha...@syapse.com said:
>
>> 2017-03-22 21:25:14 gpg-agent[3624] DBG: rsa_decrypt  res: [out of core]
>> 2017-03-22 21:25:14 gpg-agent[3624] O j: ... this is a bug
>> (sexp.c:1433:do_vsexp_sscan)
>
> The bug diagnostic is a side-effect of the out of core error.  I'll fix
> that for libgcrypt 1.8 but it is not a problem.
>
>> $ gpg --version
>> gpg (GnuPG) 2.1.19
>> libgcrypt 1.7.6
>
> Libgcrypt has the fix for the secure memory.  Thus the above should not
> happen unless you have set an ulimit.  Are you sure that the running
> gpg-agent is up-to-date?
>
>gpg-connect-agent 'getinfo version' /bye
>
> shows this.  However, gpg did not show a warning so I expect this is
> all fine.
>
> We need to have a test case to replicate and valgrind the problem.
>
>
> Salam-Shalom,
>
>Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEFENfcrF4GOcIc0u0oCVjgPWyEDgFAljUPUcACgkQoCVjgPWy
EDgEpA//R6qjcX7cSu9oRgSSGqRsROeNU7qeNie/JC2gKbUG1tXvnpYTjnoKKxXH
nElnd0laLTgWFZB4f2a8XtmFA0Ofca/rmmgQ/uVfCAdxcpsmFmRnQMBVnteXIxzy
SHhR2+980JU6gSG/gfdJ1ezVYDvU3MlM0MVb/EzMsjeA6MeKCGpg5Anc21ymO4mo
iWjp0sBC8f3aOn9zJBSmqmejqPKcyhlYl6khM3w5Q6pYFCF1B2b3VtO2F+qxrSWS
cVePVz+HVREkvPeOfi5tbN6ENaWWLQUhm5aGZl/Jsg+GJ6mD1TyOv3ZZSqVvZgjh
m11xPAFyHvvphk2ILa1X0TmTnSXUD9JZnX5RhLcUW4x/JICCidghjb+RKXyb7bNK
naaGjI47kCqBP38HZZpydOdBlnsQ60M/14/s9QUi2lkrhYtkrSzoB7vKLRoKIMwc
KJlzl29TKXbGbH8p3hikpFfJuAggUIZekALTlLcQfAXCBlLxwRf0zKehke8T8xIJ
Cc/j7V9parH3x7R4jbkd5uPyoGjpD2ivJJ3pnBTgbaH0CuWbhErDiFN9jIfUaqJc
BIC5A3qRDcbVJodzuQE1sVqeAstJaWv0E+FBrTGRrd6b7xppiRK5kpRGEb2VrhD3
I8JaYS1EesqCHLN9rRKWVT1eYJA7Pfg738qAi4KoYdPGxADc4Mw=
=kTy8
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Parallel decrypts fail in 2.1.19

[Michael Smith]

We use gpg extensively, particularly as a part of salt-ssh. Lately,
salt-ssh runs against multiple instances have begun to fail in
rendering gpg-encrypted data. Looking into it, I learned that running
one gpg -d at a time works without any problem, but several runs in
parallel fail.

1. I create a file encrypted to myself. (I'm the default recipient.)
$ gpg -qeo junk <<< junk
2. I can decrypt the file if it's in a single run.
$ gpg -qd junk
junk
3. I cannot decrypt the junk with 10 runs in parallel. (Pinentry opens
during this run.)
$ yes junk | head -n10 | xargs -n1 -P10 gpg -qd
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
gpg: decryption failed: No secret key
4. gpg-agent is no longer running

So...

I threw these options into ~/.gnupg/gpg-agent.log:
debug-pinentry
debug-level guru
log-file /tmp/agent.log
debug 1024
verbose

And tried the above again. This bit caught my eye:

2017-03-22 21:25:13 gpg-agent[3624] Warning: using insecure memory!
56ab56...
2017-03-22 21:25:14 gpg-agent[3624] DBG: rsa_decrypt  res: [out of core]
2017-03-22 21:25:14 gpg-agent[3624] O j: ... this is a bug
(sexp.c:1433:do_vsexp_sscan)

I searched for that output online and came across this message:
https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032489.html

The description there matches my experience, but that particular
double free seems to have been resolved already in 2.1.18, so I guess
I'm seeing a new bug. Has anyone come across this?

$ gpg --version
gpg (GnuPG) 2.1.19
libgcrypt 1.7.6

- Michael A. Smith

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users