Hello Werner,

Hmm. Now, even with a fresh session, dirmngr, GNUPGHOME not set, etc. it seems to work. It correctly uses the config file and the keyserver, and the logs show the Home and Config variables are set and communicated correctly.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.

I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.

Thanks for your report.

Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.

Closing with Info Needed.

hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround

There was a similar Problem in the past reported on our mailing list:

PS I forgot to say why movement to cmake will be the best way.

I totally disagree.

Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README

Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?

Hi
FYI here is what I did to resolve:
running gpg.exe and gpg-agent.exe as Administrator and XP mode....
gp-agent:
set service Priority to REALTIME
Disabled Windows UAC virtualization.

OK, I identify the problem.

But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.

Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.

For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.

@dkg, I changed the title and adjusted the description to more accurately describe the situation.

@skeeto can you edit the summary/title of this ticket to better reflect what you think the underlying issue is?

Those changes make the script work for me, specifically passing the input as an argument and not through standard input. Digging more, it looks like the underlying issue is related to using pinentry-tty (my case) or pinentry-curses when passing the OpenPGP input via standard input. This causes pinentry to give up before prompting. For pinentry-tty it fails with "ERR 83886340 Invalid IPC response" and pinentty-curses fails with "ERR 83918950 Inappropriate ioctl for device".

Thanks aheinecke and dkg.
I havent been able to replicate the fault using the command line (using the exact same command and options that our program is calling)
however our R&D dept have,
The next time it fails and we can replicate it we will try the --homedir fix and see if thats it.
Its the same user in the program and command prompt so we dont think its a certificate issue.

I'm also not sure how to classify this issue. I'm giving it low priority for now as we do not have the info to determine if this is a program error.

Thanks for clarification.
However, CCID_CMD_TIMEOUT should be then based on BWT value reported by the card/reader, as bulk_in() function will still timeout if BWT is longer than 5 seconds.

Thanks for pointing me in the right direction. I was confused by the hard-coded timeout value and got it all wrong.

I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).

In general, if it requires more time, a reader can reply with time extension.

What's Trustica Cryptoucan?
In general, if it requires more time, a reader can reply with time extension.

All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.

Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.

I disabled the dependency rules for the figures (it's only enabled for maintainers).

Which SSH client are you using?

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

Hello again - can I ask about the status? Or should I consider this as a no-fix? Anything I can assist with?

As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?

But sadly I can't see any problem with the mail. Looking at the source of the mail it has the image as one attachment. That attachment is displayed. There are no other attachments part of the mail and so other clients also only show that one attachment.

I have sended the email...

Without more reports and without the info needed to analyze this further I'm lowering the priority.

Closing this as invalid until the info requested in the last comment is provided.

I've tested it with Gpg4win-3.1.7, too and it works for me so something must be special.

this error comes to me when I try to decrypt a message and I get this message

For what I use, please refer: https://tracker.debian.org/pkg/gcc-9

Which one version gcc 9 you've been using?
May I see gcc -v ?

@gniibe already wrote: “With gcc-9 in Debian experimental, everything goes well.”

BTW: fedora corp provides already free access to build envs with gcc 9 which can be easily integrated with CIs.

What you mean " it is not reproducible for u"?
Did you try to use gcc 9 and you had no problems compiling gnupg or you don't have access to build env with gcc 9?
Try to google to "gcc 9 pragma" and you will find several discussions and patches done by people fixing similar issues.

well, Firefox DE on OSX gives same error Unhandled Exception ("HTTPFutureHTTPResponseStatus")

Hi there,

I would have thought this is a logical usage for gpg cards - seems this is harder to achieve as I thought.

I think Bash 5.0 is in sid, not testing yet. Are you sure it's related to Bash 5.0? Is there any possibility your upgrading some other software causing this?

That's exactly the point: I do want one common encryption key between the two cards: So I can distinguish between the two, but en-/decrypt with both.
One is on the GnuPG SmartCard, the other on a YubiKey - output --card-status (some things xxx'ed out) :

Please show us your output of gpg --card-status for each card, and tell us the reason why you think "the pgp db seems screwed up".

For my test, six distinct keys (three subkeys for each smartcard) works fine.
IIUC, you try to use same decryption key by two smartcards. Currently, it is not supported.

Is it an issue when you share an decryption key E among two smartcards?
I think that when there are six distinct keys (three subkeys for one smartcard each), it works fine.
I'll try to make reproducible test case.

FWIW, the canonical way to make sure that gpg-agent has been started is to run

You're very welcome. In my instance, this is "resolved" - I now get the prompt I realised I needed so to me this bug could be considered closed or wontfix, but I'll leave you to do with it as you please.

Basically, you are right. In addition, gpg-agent asks scdaemon about list of card/token.

OK - so if an entry is not required in sshcontrol for a smart-card key - is the private key stub sufficiently detailed enough for the agent to realise that it can ask for that card to be inserted for an ssh connection?

sshcontrol entry is required for non-smartcard keys, but not for keys on smartcard. This is intentional. For gpg-agent and current format, it is only the information for gpg-agent to know if a key is for SSH or not.

Also - going back to sshcontrol - with an ssh key added to the agent with ssh-add, an entry in sshcontrol is required - but not for a key on a smartcard. Is that intentional, or just a byproduct of the smartcard diversion that happens?

Oh, wow - yes, adding to sshcontrol brings up the prompt - I do however need to stop the agent from being restarted on insertion for it to subsequently ask for the unlock.

I see your point. You are right. For SSH access, it just fails without asking insertion. It's not Windows specific.
I checked the change of history of gpg-agent, but I cannot find prompting insertion was supported.
So, I don't thin this is a regression.

Yes, it's running. I have a scheduled task that spawns a vbscript to ensure that gpg-agent is started on login, and restarts it on insertion of a card (specifically for two reasons: windows ssh clients don't typically start agents automatically, and windows can cause gpg-agent to get a but upset after a card is removed and re-inserted. Edit: although, I think that latter reason might be resolved now... I haven't investigated deeply. more info here and here).

Thanks for your information.
Hum, you are using gpg-agent for SSH access.

When no card is inserted, usage of an ssh client simply fails to request insertion of the card for the stub keys present in ~/.gnupg/.

It seems it's Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1796563

Please let us know the version of GnuPG, the output of gpg --card-status when inserted, and how gpg is not working well, etc.