@aheinecke What additional information do you need ?

You need to handle them in a correct way. Just checking with gpg is
not enough because you don't know what has been signed. You need to
look at the signed data which gpg gives you by using the --output
option. And there you see only the signed data and not the extra
"aaa" you added after having signed the plaintext. It is not
different from adding stuff before the -----BEGIN PGP SIGNED ... line.

In T6272#165067, @werner wrote:

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Thanks. There should also be SPDX indentifiers everywhere.

Fixed, to be released with Gpg4win 4.0.5.

On the command line using:
gpg -o output.txt --decrypt "yourfile.asc"

There must be something special with the message. Can you save the message to a file and use the command line to decrypt it? Is there anything special with it? Is it maybe a binary and not text? Although I tried decrypting random bytes with the notepad and it worked for me. Is the message very large? Anything unusual? Or does it even happen for you when you encrypt a short text to yourself and then decrypt it again?

fixed

Fixed

We develop many versions of pinentry, but not the one for macOS. Therefore, we cannot help you. Please contact the developers of pinentry-mac (https://github.com/GPGTools/pinentry) or the homebrew maintainer of pinentry-mac (https://formulae.brew.sh/formula/pinentry-mac).

I've got a similar patch, but I'm not sure it's any better -- I'm adding EcDSA support for cards (via gnupg-pkcs11-scd) and with this patch I can sign subkeys and data.

Note the relationship to T4195, T4826, and T4766

Sadly, it doesn't work for me. But thank you.

I managed to find a way to minimize the data (less than the one on Oct 25).
And it somehow works for me.

So what should I do now? Should I report it to OpenSSH team?

We won't do that. FWIW: We started to work on a 64 bit WIndows version of GnuPG.

Fixed for master but not yet tested.

There is a utility named kbxutil which can be sued to dump the pubring.kbx file without any post-processing by gpg. I would check whether there are any other keys after the VideoLAN key. iirc, kbxutil ist not commonly installed; you may need to build the software yourself or copy the pubring.kbx to Linux and check it here.

I think there is a mixup here. I believe that you are experiencing https://dev.gnupg.org/T6192 (From 2019) which is a fairly recent regression and was discovered by our internal QA in September. As we did not get reports about this we only gave it low priority.

The first report? In history, i know, on older versions, this issue was also exist and reportet.

@gniibe: Thanks for looking into it.

I tested on the machine with:

Surely not. We just take the key from those certificates. Note that ssh-add merely imports a key permanently into gpg-agent's key store.

In order to remove the SHA-1 algorithm in Arch Linux package keyring, I need to resign one of my sub keys but the backsig (0x19) remain in SHA-1 as reported here.
I didn't find any solution with gnupg to update it since this bug report was opened in 2020. Do you plan to address this in a near future?

I don't have common.conf but I do have pubring.kbx. I meant I plan to remove that key from my keyring because it's like a decade old and expired, but I figured maybe it was somehow related to this bug since it's the last key shown, so I've left it in.

Are you using the keyboxd ? ("use-keyboxd" in common.conf) or is this using the default pubring.kbx.

Oh yes, the usual import statistics should be shown here.

Are you sure you are using SSH user certificates for SSH authentication? I have trouble with SSH certificate authentication instead of public-key authentication.

The latter. Detecting mail addresses with regexp is anyway a kludge and we have more stringent code to detect mail addresses in a user-id.

I am using this many years now without any problems. Also my collegues and many other folks I know. Thus the question is how your system differs from commonly used systems.

I have tried the stable version (2.3.8). Sadly, it doesn't work. 'agent refused operation' again. And I think it may have nothing to do with OpenSSH certificates because NIST256&384&512 keys do work in this situation.

@werner i'm not sure i understand what "easy to enclose them in angle brackets just for comparison" means.

We do not support OpenSSH certificates but ignore such requests. However, the keys from the certificates will be imported correctly. You should use the stable version of GnuPG (2.3.8) and not the LTS version 2.,2.

This is the first report we have on such a problem despite of hundred thousands of users. "Triage" means that we need to look at a report to check its priority.

@werner , why set to "needs triage"? At this moment plugin must be disabled if customer read crypted SMIME E-Mails. So it is critical. disable checkbox "SMIME" will not work correct. Enable "SMIME" will only encrypt as Text, but some E-Mails have HTML.
We have this issue on all systems (Windows 10 and Windows 11)

I tend to close this as a duplicate.

We already detect mail addresses for different purposes and thus it will be easy to enclose them in angle brackets just for comparision.. Almost all trust signatures out there are created by gpg and used to restrict the mail domain. No need for different regexp. See also the comments in the code related to the history.

Applied also in 2.2 branch.

Ah, sorry, I did my own changes before looking T6244#164317

Pushed the changes to 2.2 and master.

Thank you for your report. The issue is handling of static linking in GnuPG.

Renamed bug due it being incorrect to assume this was a bug with libgpg-error. Turns out that a simple patch to g10/Makefile.am in GnuPG 2.2.40 LTS source fixes the linking error. Patch that fixed build for me is attached, which basically puts -lws2_32 in the correct location for builds with the new libgpg-error 1.46 version.

It will be hard to fix this. GnuPG supports exactly one class of regular expressions: something bracketed between "<[^>]+[@.]" and ">$" . Even if the next release of gpg supports more regular expressions, gpg will have to wait years before it can start emitting different regular expressions for scoped tsigs by default.

I recommend, when making a User ID with only an e-mail address, to populate the User IDs by wrapping it in an angle bracket, rather than just leaving the raw e-mail address. It's not just the regexp matcher -- there are other pieces of OpenPGP software that won't recognize a raw e-mail address in a user ID as an e-mail address. It also makes it easy to distinguish such a User ID from a User ID that is not at all an e-mail address.

Thank you for your report. IIUC, your log is the build log of GnuPG 2.2, so, I put the tag "gnupg (gpg22)".

This also affects 2.2.40. Will the fix be backported there? Thanks.

It seems to me there are two separate concerns here:

Thank you, confirmed. Pushing the fix.

You need to assign a drive letter.

is there any news for gnupgp 4.0.4 release with gnupg 2.3.8?

My suggestion is to clearly state that there is a direct Key Signature with an expiration date. Another feature would be to add a separate command to modify Direct Key Signatures. However, the latter has the problem that it help with proliferation of such signatures and other OpenPGP implementation will run into other problems. Thus for the whole ecosystem such an option is might not be a good idea.

Thanks for looking into this!

Direct key signatures are rarely used. IIRC, we implemented that the same way PGP did it.

Fixed in 1.6.1.

Fixed in 1.6.1.