I fixed a bug in nPth: rPTH4fae99976c31: Fix busy_wait_for.
During this debug, I also found a bug and fixed in libassuan: rA62f3123d3877: Use gpgrt_free to release memory allocated by gpgrt_asprintf.
Also, I fixed two related bug in GnuPG:
rGc03e0eb01dc4: agent: Fix error from do_encryption.
rG996544626ea4: agent: Fix memory leaks.

Yes.

Reading that PDF I guess we need the same functionality in gpgsm too, right?

In T3059#98047, @werner wrote:

DSA is signature-only but VS-NfD is only about encryption. Thus signatures are out of scope.

DSA is signature-only but VS-NfD is only about encryption. Thus signatures are out of scope. Even key management is out of scope. OTOH, certain algorithms are simply not allowed. This means we can't use SHA-1 except for specified and approved usages (in our case OpenPGP fingerprints).

Yes. mark them as non-compliant.

In T3059#98040, @aheinecke wrote:

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

Sounds exactly right to me.

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

In T3059#98015, @werner wrote:

g10/misc.c:gnupg_pk_is_compliant is my take on puble key algorithms.

See kerckhoffs:~wk/ST-Gpg4VSNfD-v0.6.pdf - eventually this will be published but right now we don't have clearance from the BSI to do that.

g10/misc.c:gnupg_pk_is_compliant is my take on puble key algorithms. For cipher algorithm, we will only allow AES* and digest SHA-2-*. Other details are in a document we have in an project internal wiki - I'll send you a copy.

Ok, good to know. However, I still need more information about what it means to comply with CO_DE_VS. Any pointers?

I thought about this but in the end it is unlikely that we will see request for other protection profiles. Thus I did spend a single bit on the German thing. Further, it is quite possible that a message matches several profiles and than bit fields come really handy. For the very limited circle of users a dedicated sub system for such things would be overkill.

The GPGME API uses field names like 'is_de_vs', but isn't that short-sighted because we hardcode names of compliance modes into the API? Also, 'vs' seems to match both 'VERSCHLUSSSACHE – VERTRAULICH' and 'VERSCHLUSSSACHE – NUR FÜR DEN DIENSTGEBRAUCH'.

I need more information about what it means to comply with CO_DE_VS. Any pointers?

Yes, if it supports --card-edit it would help a lot.

Dirmngr uses its own resolver for these reasons:

debian stretch's 2.1.18 also suffers from this (debian bug tracker). As there is only 13 days left for fixing issues in stretch, swift action is needed.

@gniibe , I'm not setting the max-passphrase-option. Currently, my gpg-agent.conf looks like this:

@landro , Do you have any key which might require passphrase update for its expiration?
I mean, do you have an gpg-agent option of "max_passphrase_days" set (default is not set).

(Since I was writing by phone, the sentence was terse. Sorry. This time, by PC.)

Fixed as of 525f2c482abb6bc2002eb878b03558fb43e6b004.

What do you mean by connection error, @gniibe? I hope the user is not impacted by what you are suggesting.

For smartcard, yes. The feature for ssh with smartcard has been available more than ten years. I recently apply the approach to gpg frontend.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

@werner, can you please quickly outline how you imagine this to be fixed? Our jabber discussion is gone from my memory, and my client does not keep logs for MUCs for some reason.

Just noticed one more thing - I'm not trying to use a smartcard at this time (I plan on moving to yubikeys in future though) - why is "new connection to SCdaemon established" all over the logs?

So I'm using pinentry-mac in my gpg-agent.conf:

So I noticed your log contains lot's of "starting a new PIN Entry", I assume you are using some kind of password manager integration, so that you don't need to enter it each time (sorry, I'm not familiar with how pinentry works on macOS).

Ok. To reproduce, I believe the key is to establish lots of connections (in my rig around 20) to (possibly different) ssh server(s) (possibly by going through a bastion) within a short timeframe.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

Too bad. I installed both libgcrypt and gnupg using homebrew, and apparently there is no way to make homebrew include debug info. I guess I could build from source and include debug info - where can I find instructions on doing that?

Hm, it did not give us the location in the source unfortunately, only
the offset from the top of the function, which the original stack trace
already contains. Maybe the library does not contain debug information.
Depending on how you installed that software, there may be a way to
install the debug symbols too. That would make bug reports much more
helpful. Thanks anyway, maybe the log will help us trace the problem.

No reaction in Months, I'm closing this task. Feel free to reopen it with more information.

The test framework changed considerably, and the reporter is not responding with details. I don't believe this is applicable anymore. I'm closing this task. Feel free to reopen with more information.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

In https://dev.gnupg.org/T3027#97654, @justus wrote:
> Hi @landro, thanks for the stack trace.  Could you please try to resolve this frame
>
>   4   libgcrypt.20.dylib            	0x000000010d8b14d2 openpgp_s2k + 594

Here it is. @justus

$ atos -o /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib -arch x86_64 -l 0x10d896000 0x000000010d8b14d2
openpgp_s2k (in libgcrypt.20.dylib) + 594

@landro Thanks a lot. I think that we see some failures in the log, and there might be another bug in the failure path.

In T3027#97654, @justus wrote:

Hi @landro, thanks for the stack trace. Could you please try to resolve this frame

4   libgcrypt.20.dylib            	0x000000010d8b14d2 openpgp_s2k + 594

to a source code location? I believe it can be done this way:

$ atos -o /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib -arch x86_64 -l 0x10d896000 0x000000010d8b14d2

I tried to reproduce this issue locally but failed.

Here is the output of the log file

In T1983: gpg2 prefers missing secret key to available key on card, I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.

I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.

In the crash log of 2017-05-22, I can't find any race or violation of shared object. It looks like some malloc related error.
Does gpg-agent emit error message(s)?

Hi @landro, thanks for the stack trace. Could you please try to resolve this frame

Just retested this with 2.1.21 - unfortunately gpg-agent is still crashing. Se new attached crash log.

Updated patch

Indeed and that is a standard feature of 2.1. It is even by default enabled. See --extra-socket in the the gpg-agent man page.

In T1646#81392, @werner wrote:

However, with 2.1 it is possible to implement a more elegant solution:
You run gpg on the server and gpg-agent on the client. gpg-agent
takes care of the secret key operations while gpg does the bulk data
and public key stuff. To implement that the gpg<->gpg-agent IPC needs
to be changed from local sockets to TCP over some encrypted tunnel. I
have not checked whether ssh is already able to proxy a local socket -
but if it can do so, you have an instant solution.

Sorry, my fix was not good. Re-opening.

Reviewed and committed in 2.1.21. Phabricator only support closing a revision by the author.
So, I've taken control of this revision to close.
Thanks.

Can confirm here too. Applying that on top of 2.1.21 works perfectly.

Yes that fixes it!

I put another bug in 2.1.21. Please try: rGa8dd96826f84: g10: Suppress error for card availability check.

Unsure whether to bump this or report it as a fresh bug, but the testing-scdaemon-inside-a-sandbox-on-macos issue has returned in GnuPG 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

The OpenPGP test suite is now run once with keyboxes and once with keyrings, so backend-specific bug like this will be caught in the future.

Automatic creation of socket directories creates cleanup trouble for projects previously relying on the agent-shutdown if $GNUPGHOME is removed: https://notmuchmail.org/pipermail/notmuch/2017/024550.html

In T3080#96970, @bmhatfield wrote:

I found a workaround that may benefit folks who previously upgraded and are now only using GnuPG 2.1+ - upgrade your keyring to keybox format: https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox

In T3080#96945, @languitar wrote:

Any plans when this change will be pushed into a release version so that it ends up in distros?

Those scripts are likely already broken if their input happens to be different than what they expect, so i don't much care about "breaking" them. That said, it sounds like you're suggesting that the default mode will just be "--decrypt" and we'll let people continue using it that way.

This seems to work just fine on our archlinux box with the nsswitch configuration above.

I found a workaround that may benefit folks who previously upgraded and are now only using GnuPG 2.1+ - upgrade your keyring to keybox format: https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox

I looked around a bit and found many places where the decryption was given as the default operation for gpg and thus requiring -d would break a lot of tutorial. Of course we could educate the user in attended mode that "-d" is now required but I fear that this will break too many scripts.

Any plans when this change will be pushed into a release version so that it ends up in distros?