Works for me! :-)

Not sending the user id packet, is just a bad idea because that user id exists and from my understanding they are sending the self-signatures anyway. They should not try to argue with the GDPR here, that is privacy theater. The key itself is a personal data and due to technical reasons this data is required. What they can do is to accept only user ids which carry just only mail address and no comments or name. posteo.de for example requires this for years and the WKD drafts has a feature to support this.

Just want to weigh in here to say this would be incredibly useful given the shift to the new keyserver model. See T4604 for more context.

I cannot do that because all listed above packages are my own products.
Fedora is not execution test suites in more than 90% of all packages so they are not aware of most of the issues exposed by test suites.
Please focus on possible causes of above tests.
I'm opened on any suggestions to make additional diagnostics.

Thanks. You may want to ask on the mailing list gnupg-users to see whether someone else has had problems building on rawhide. Right now we do not have the time for individual support and thus I unfortunately need to prioritize this bug report down.

[tkloczko@barrel SPECS]$ uname -a
Linux barrel 5.1.5-300.fc30.x86_64 #1 SMP Sat May 25 18:00:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[tkloczko@barrel SPECS]$ rpm -q libassuan-devel libcurl-devel libgcrypt-devel libgpg-error-devel libksba-devel libusb-devel npth-devel openldap-devel pcsc-lite-libs gnutls-devel sqlite-devel
libassuan-devel-2.5.3-2.1.fc31.x86_64
libcurl-devel-7.65.1-2.fc31.x86_64
libgcrypt-devel-1.8.4-4.1.fc31.x86_64
libgpg-error-devel-1.36-2.fc31.x86_64
libksba-devel-1.3.5-10.1.fc31.x86_64
libusb-devel-0.1.5-14.fc30.x86_64
npth-devel-1.6-3.fc31.x86_64
openldap-devel-2.4.47-2.2.fc31.x86_64
pcsc-lite-libs-1.8.25-2.1.fc31.x86_64
gnutls-devel-3.6.8-2.fc31.x86_64
sqlite-devel-3.28.0-2.fc31.x86_64

Still about half of the packages are from Fedora rawhide but rest are mine.
Just checked and the test suite fails exactly the same way even started without palatalisation.

Please share with us the OS used, the versions of the libtaries used and other configuration information.
Also please run again using "make check" without any extra options.

Ping?

Werner: I'm assigning this to you. Because the underlying reason is a missing status from gpg. I think we should add that for 2.3 as any new status line tends to break things.

sorry to keep pinging this, but given the ongoing flooding attacks (e.g. T4591) and how SKS and similar keyservers are unable to safely transmit flooded certificates, i think this kind of fix is urgent if we expect gpg to be able to retrieve revocations safely. What's the status here?

For the record in my original message I asked about adding self-signatures.

I'm unlikely to put a windows-specific patch into the debian source, as
i have no good way of testing it, and it wouldn't affect any binary that
we ship.

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

@dkg, for your patch, it can be improved for Windows by using its event mechanism. You can see gnupg/scd/scdaemon.c.

Hm, T4521 suggests that the two different cases should not be treated differently. If you think that they *should* cause distinct behavior, please do mention it over there!

There are two different cases: (1) By SIGTERM and (2) By KILLAGENT. It's true that the agent stops accepting on the listening socket for (1), but it's not the case for (2).
This particular problem is for the case (2).

@gniibe, thanks for the diagnosis! I agree that restarting or shutting down the backends should be done in the reverse order as a simple workaround.

Correct solution is to implement KILLAGENT synchronously, but it's somehow harder to implement.
Easier workaround is modifying gpgconf like:

I found a race condition between KILLAGENT command and accepting another request.
Here is a patch to replicate the race condition :

Hello,
when can we fix it?

we now have a DCO from @Valodim

@werner, My usual approach for private branches is to prefix with dkg/, but (a) playfair rejects branch names with a /, and (b) i'm not the author of these patches, and i didn't want to claim credit that doesn't belong to me.

Please use a private branch as usual. There has been no agreement or a discussion over this change nor do we have a DCO from him.

I've pushed @Valodim's proposed patches to the fix-4393 branch in our git repo. they look good to me, and i think they should be merged to master.

Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.

Nope

Here are the patches without any new commands:

@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?

In case I not already mentioned it: There won't be any new commands to delete a key. Of course you are free to change GnuPG as you like but I won't apply them here.

Fixed in master. Closing.

Fixed in master (to be 2.3).

While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).
Closing.

I added the section in tools.texi. Closing.

FYI, pEp annoyance was addressed and handled here: https://bugs.debian.org/891882
By this patch: https://sources.debian.org/src/enigmail/2:2.0.11+ds1-1/debian/patches/0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch/

Thank you for your response.

For GnuPG, the error is: you don't have run-able libntbtls.so in your environment (because of your wrong configuration, perhaps) but you have it to link.
For GPGME, the error is: your linked libgpg-error.so.0 and the one which runs are different (because of your wrong configuration, perhaps).

I also experienced this issue while testing my --delete-secret-key patches. Passing --pinentry-program /usr/bin/pinentry-tty to the gpg-agent worked around it.

I wrote a patch in a topic branch: rG108c22c9c50a: g10,agent: Support CONFIRM for --delete-key.
I think that gpg-agent side,

• agent/call-pinentry.c: This part is good
• agent/command.c: I wonder if use of status for passing the information of prompt is good or not

Perhaps, we need an improvement in

• g10/call-agent.c: how to ask user, by cpr_* function with no keyword is good?
• Currently, only using DESC
• Only applying to DELETE_KEY command
• Can be applied also to:
  • PKSIGN
  • PKDECRYPT

@werner Thank you for resolving this issue.

See the man page on how to delete subkeys or just the primary secret key with --delete-key.

No sorry, we won't do that for the regular source. However, the full source for the binary installer is xz compressed. That is because we are legally required to publish the source but in reality the source ist not used and weel, to build you have lots of other requirements with xz being the simplest one.

There is also a confusing case: a subkey expiration date is set, but the associated primary key is expired.
Pushing a fix in master.

Actually I have a different approach to fix this bug(let). Please give me a few days.

@werner Thanks for merging the --dry-run patch in 110a4550179f !

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.

Thanks Gniibe San for explanation.

At the time the verification is done some output has already been written to the file 'signed'. When checking whether the deprecated abbreviated format

I can't see any bug here so I will close this bug now.

@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).

Hi Werner,

Please use one of the mailing lists to solve your problem. 2.3 is a development version, so I wonder from where you got this version of GnuPG.

Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.

Feature supported in master.

Will give you more detailed info about your certificate. For even more details use --dump-chain instead of --list-chain.

rG5b22d2c4008 tested good under Asan.

Thanks for your report.

We update condig.{guess,sub} only when needed. In the past we had cases with regressions on some rare platforms.

I'm going to bring newest m4/iconv.m4 from original (gettext), which apparently fixed file descriptor leaks.