In case of gcc 4.8 on Solaris, could you please try this patch (instead of configure patch) to see if it works?

It looks like somewhat complicated more. It seems that specifying _POSIX_C_SOURCE=200112L is not good on Solaris with old GCC. Perhaps, it would have no problem with newer gcc (or -std=gnu99 option).

I think this patch should be backported to STABLE-BRANCH-2-2

I can confirm that this fix repairs the problem on debian's s390x.

I've just pushed e4a158faacd67e15e87183fb48e8bd0cc70f90a8 to branch dkg/fix-T4501 as a proposed fix for this specific problem (it doesn't introduce anything in the test suite, or try to deal with any of the other %b problems).

OK, i think the reason this is happening is that agent_public_key_from_file (in agent/findkey.c) is screwing up a %b format string in gcry_sexp_build_array.

IIUC, -std=c99 won't solve this issue. It is Solaris specific C99 issue.

Ok, the difference appears to be that on these 64-bit big-endian platforms, they're returning a zero-byte string for the associated comment. When this happens, gcry_sexp_canon_len returns 0 because of GPG_ERR_SEXP_ZERO_PREFIX. The same thing happens on x86_64 platforms when confronted with such an s-expression.

It looks to me like gcry_sexp_canon_len is returning 0 on these platforms from within a backtrace like this:

This is known and by design, basically it is a legacy X feature. For Wayland, the window manager determines if a window should be blocking, no grab or grab, not anything applications themselves have control over. This came up many times when I was first making the interfaces. You can reference these two comments, but there are many more in between them.

Validity values are also displayed for all user IDs.
[…]

show-uid-validity
       Display  the  calculated  validity of user IDs during key
       listings.  Defaults to yes.

[…]

Trust values are used to indicate ownertrust and validity of  keys  and
user IDs.  They are displayed with letters or strings:

[…]

revoked
       For validity only: the key or the user ID has been revoked.

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, everything works fine on s390x. so the failure appears to be due to the (comment), just like in T4490.

fwiw, i've just tried loading the same keyfile that the s390x (64-bit big-endian) implementation choked on into a running gpg-agent on an amd64 machine (64-bit little-endian) and gpg --full-generate-key succeeded with that same key on amd64.

"valid user-id" means a user id which is properly bound to the key; that is the self-signature checks out.

I keep this open to track the mentioned change for gnupg 2.2

How a digest algorithim is selected for a key signature

No, personal-digest-preferences are not used to select a digest algorithm for key signatures. The only way to use a different digest-algorithm than select by gpg is by using --cert-digest-algo. But take care, you can easily cut into your fingers when using such override options.

It is because you don't have ${prefix}/bin in your PATH.
Please build having /var/tmp/bin in your PATH.

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

I also did a base64 < "$GNUPGHOME/private-keys-v1.d/".key at the end of a different run of that script, and it produced this output, if you'd like to inspect the actual S-expression stored:

I ran the example script from T4490 on an s390x machine, and got the following output:

This might be related to T4490, since it's the same sort of key generation process.

It looks like Solaris only needs CFLAGS+=-std=c99. It was added for all programs and libraries listed at https://www.gnupg.org/download/index.html.

It appears this issue was first identified and triaged in 2016: T2879
The subkey deletion feature also showed up in other issues since then:

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

Diffs downloaded from the revisions don't include commit messages for some reason. Here are all the commits I submitted for review as patch files with messages:

@werner could you review the patches posted here by @matheusmoreira ? This looks concretely useful, and i would like to have this fixed.

Merged. Thanks again for your work on this.

Thanks for the explanation. That addresses my concerns.

I agree that this is a minor API shift, but i *don't* think it's a security problem, because i was particularly careful to maintain the invariant that decrypt(verify=True) will only ever return valid signatures.

Thanks for the prompt action here. Some build environments (e.g. distro builds) might ask for additional compiler warnings in the user-supplied CFLAGS, but i suppose those build environments that enable the warnings deserve what they get.

That makes sense to me. So I've now moved the -Wno flags out of the maintainer mode conditional but left the parts adding warnings in the maintainer mode conditional.

The thing is that that I accidentally added the -Wno-* flags only in maintainer-mode as they were -Wmore-strict-warning-flags. One reason for using more strict warnings in maintainer mode is to allow building with older gcc versions without having to test for the availability of the warning flags.

Thanks for the report. This is annoying me, too when doing release builds.

I'm for merging this as I understand the rationale. In Kleo / GpgOL I also only need one valid signature.

I've just published a branch dkg/fix-T4276 (with commit 4100794e305ba22241ea5a4f7b42bb5189fbd948) which i think resolves this issue.

@JW-D Sorry but that is a Wontfix. We had a similar task: T4115

On think should be mentioned. Both accounts are IMAP, but the Posteo account has one particular feature. All inbound traffic from their server to my client (receiving e-mails) is encrypted with my own public S/MIME certificate (they call it "Eingangsverschlüsselung") so all non-encrypted e-mail will be treated between Posteo server and my client as S/MIME end-to -end encrypted e-mails. This is not the case with the t-online account (there it is just TLS encrypted). However, I believe a PGP signature verification should happen after S/MIME decryption on the client.

Ah! I see it now. I've looked at the screenshots again and noticed that Enigmail writes for the posteo message. "Part of the messaage is signed" and shows it as encrypted, while for t-online it is the full message that is signed and not encrypted.

This account is IMAP, nothing special, I´ll send a screenshot from the add-ins by e-mail.

Well, I deinstalled gpg 3.1.7 and reinstalled it. For some reason my two gnupg smart cards work fine, but my two Yubikeys cannot be detected anymore (no such device). But in the last weeks, they were deteced, only the switching between Yubikey and Smart Card made some trouble. That they cannot be recognized is new and makes real trouble. If you think it would maybe helpful, I can submit a scdaemon.log file by e-mail.

According to the log GpgOL is not notified by Outlook that a mail is read. So it does nothing.

The debug file will be sent by e-mail to you immediately. THANKS

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.

yes I got the screenshot but they sadly did not tell me much. I don't have a good idea right now why it does not work for that one account.

Revision D482 adds an extra confirmation prompt before deleting the secret primary key.
Revision D483 adds portuguese translation for the primary key deletion confirmation message.

I have sended the email...

Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.

@werner Here are the patches:

If you have a patch please send it either by mail to gnupg-devel or attach it here. Thanks.

Please explain in more detail what the problem with Cygwin is.

In T4457#124752, @matheusmoreira wrote:

I thought about building a list of keys targeted for deletion so gpg can then ask the user to confirm the deletion of each key individually.

So long I change between smart cards, I can do it multiple times. If a Yubikey is recognized and a smart card follows next it will not work. Most recently I face also problems to detect the Yubikey (Message: no such device), but Smart Cards still working fine.

Did you get the screenshots from Thunderbird (works fine in both accounts) and Outlook (failure in one account)? If not, please provide e-mail address.

Since 2.1 the standard use of gpg-agent is to have it started on demand by the components which require it. The use of
"gpg-agent --daemon /bin/sh " should be used for debugging only.

With the last release we improved the handling of sent mails, again.

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

I've applied your patch with an additional comment to our master branch. Thanks!

@dkg, thanks for the feedback. I read [doc/HACKING](https://www.gnupg.org/faq/HACKING.html) and revised the commit message so that it contains ChangeLog entries and a marker line before my description. I compared my new message to prior log entries and they seem to match now. Is this appropriate? If so, I will revise my other commits in the same manner.

Thanks for this work, @matheusmoreira ! I personally think a reusable function in common/ would be preferable, but it's probably up to @werner to decide what's best here.

@dkg Sure! I thought I was supposed to email the patches to the development mailing list. [I've uploaded my delete-secret-subkey branch to GitHub.](https://github.com/matheusmoreira/gnupg/tree/delete-secret-subkey) You can see a comparison here. I'll describe my changes.

With the new keytreeview since 45f27eb3940617a8daff9b218b066ac482b9515d this is resolved.

This was fixed with c591cb20edfe70de29d343a6ce13c4b710bdeba6

This was fixed.