I'm seeing this as resolved. It's a design decision by the pinentry-gtk maintainer. pinentry-qt is the default pinentry for windows and there pasting works, as you have confirmed.

We did not have more reports about this so I'm resolving it here.

Two more reports in the Gpg4win forums. Still can't reproduce it. I've asked for debug output.

I'm closing this as duplicate of T3459

Has long been in testing. I think it is improved now and CRL's also work.

The change was released with Gpg4win-3.1.2

Forgot to comment. Yes what is in the video is also what I thought.

Fix is released in Gpg4win-3.1.2

Fix is released in Gpg4win-3.1.2

And 2.2 branch.

Fixed in master.

It's in 2.2.4 and 1.4.23.
Closing.

I'll fix for the non-FQDN case.

I think that I identified the issue. This is the libdns (dirmngr/dns.c) problem when hostname is not FQDN.
If you change it to FQDN, you can see that it tries to search adding the domain name.

Fixed in master.

It is indirectly reported at the upstream: https://github.com/wahern/dns/issues/19

I've made the parsing less strict in LibTMCG: https://github.com/HeikoStamer/libtmcg/commit/be7963b33cf8bace9d031074521acc4e89930d33

thanks, that works for me. I look forward to seeing the patches :)

See T4012 for a patch to build with an older libgpg-error.

Although "certificate" is used for OpenPGP revocations, it is technically a signature.

can you let me know what you're planning so i can plan my work on enigmail?

thus far every packet type has been a three-letter string, right? I'm looking at "Field 1" in doc/DETAILS. adding a 4-letter packet type seems like it could be trouble if someone has done the dumb thing of assuming the field is fixed-length.

What about another record type for standalone revocations, something line "rev0" or "revx"? This would solve the problem on how to distinguish merged revocation signatures (ie with a preceding "pub") from standalone revocations.

can i get a confirmation that the options you're considering for --with-colons --show-keys when confronted with a revocation certificate will be either:

@tinkerwolf This is weird... I've reinstalled my PC from scratch with an initial account set as local, and was able to set up GPG4Win perfectly fine for the first time on my PC (as I did in the VM). So, set up a VM with an initial account set up from an online account. GPG4Win started up fine... I am now really confused!! Somewhere within the getting set up with an online account, something has to be happening that interferes with dirmngr..
Will investigate further.

@RAmbidge are you able to further test this by using a VM with a MS account? I don't have the means right now, or I'd do it myself.

By "dummy pub line" I think you're proposing output that looks something like this instead of just the rev: line.:

As long as we don't check the signature we don't need the pubkey. That would make it actually easier becuase we have only one case and not 3 or more (bad signature, no pubkey, etc).

That actually makes sense, because it works fine on my laptop, where it's been a local account from the start, but it's broken on my desktop where it was originally a MS account, but is now local.

Fixed with https://commits.kde.org/libkleo/79f0cb79817e44b4eab864c573740c1501e796bd

Revocation certificates consist of *only* the revocation packet, right? Claiming that the revocation cert contains more than the revocation packet (when it doesn't) seems more troubling from an API perspective than just telling people to expect a single rev: line if they are looking at a revocation certificate.

thanks for looking into this so quickly. where is your patch? i don't see it on the master branch yet.

That will be a bit of work. We can't list a standalone key yet because the the key listing code expects a public or secret key as first packet. Further it would be advisable to insert a dummy "pub" key record before the "rev" record because the advise as always been to use "pub" or "sec" as start of a key keyblock.

ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.

Thanks for reporting and your patch. However, I used a different way to solve this bug.

see e051c279216ecd4ec9a48e13ccc695f5ab667b2a

I note that --import-options show-only --import has the same effect as --show-keys -- that is, the revocation cert is imported. so the error is in the import-options code itself. I'll push a fix-T4017 branch shortly with a proposed correction.

Yes, closing.

I'm having the same issue. I read somewhere that it's likely caused by using an online Windows account to login with. So I converted to local log in. Issue persists. As a test, I've just set up a VM with a local account set up at install, and GPG4Win works perfectly fine. So I'm guessing that there may be an issue which stays in the files system caused by online account users. I'm not a programmer and have no idea how or where to look to see what's causing it and how to fix it though.

So we had two releases with the fist. Can we set this bug to resolved?

fwiw, i agree that if there's any security vulnerability here, it is in the verification side, not the creation side.

Unfortunately 2.2.8 does not build with older libgpg-error versions. Commit rG18274db32b5dea7fe8db67043a787578c975de4d should fix this.

2.2.8. with a fix has been released. Announcement

Yep. ?

[Better use the gnupg tag. Specific versions end up on the workboard and there may only be one.]

@dkg can you please take this up with Debian and other distros? See the commit for a brief description.

Fixed in 1.4, 2.2 and master. New releases will be done soon. Note that there is no need for a new gpg4win release because GPGME is not affected.

Okay. Thanks for looking into this.

In the meantime, I upgraded my Fedora installation so I won't be able to reproduce in the same circumstances. I suggest we close the issue for now. I will reopen if I manage to reproduce.

I tried this with the current 2.2 branch and master and was not able to replicate it. The stubs are all deleted as expected. I also checked the commit log since 2.2.6 and didn't found anything which indicated that such a bug was fixed.

See rG26bce2f01d2029ea2b8a8dbbe36118e3c83c5cba for a description of the problem and its fix.
Thanks for reporting.

Hi Werner,
The issue is the following:
I have 2 certificates in the trusted-certificates folder that is searched by gpgsm (C:\ProgramData\Gnu\etc\gnupg\trusted-certs) which I want to trust. When dirmngr starts, it reads the Windows trusted certifcate store (certlm.msc for both system and user - I don't know the path / location of the windows certificates folder outside certlm) and builds the list of certificates to use. Once this list is read and if any duplicates are found in the trusted-certificate folder, it ignores them - they are already present.

Thanks. I added all standard names to that list.

I do not fully understand your problem. Can you please explain it with an example and also state the full file names of the mentioned folders?

Better?

Here is a sequence of operations/commands that permits to setup or update KDF-DO and align PIN codes accordingly:

Please add

Please dee the commit for a description of this fix.

I don't think this is an error in Debian. Debian Squeeze is packed with libgpg-error 1.26 in the latest stable release [1].
According to the list of changes, gpgrt.h is addes as an alias for gpg-error.h in 1.27 [2].
I think a quick (and correct) fix is to increase the NEED_GPG_ERROR_VERSION in configure.ac to at least 1.27 [3], so the build will fail nicely in the configure-step with a correct error.

Yeah, that's not good enough. You also need to check if literals_seen is 0 before BEGIN_DECRYPTION to catch the case where the plaintext packet comes before the encrypted packet. See https://github.com/das-labor/neopg/commit/30623bcd436a35125f21fe6f29272a5fa7212d3f

Thanks. Yes, I think that's it. Here's a video just in case.

Ok You could notice it because if the year changes there was no "blue" selected date in the current page.

Had a bit trouble reproducing it. It worked for me.

I've noticed during testing that GpgOL would not send valid PGP/Inline signed only messages and also failed to verify such messages itself when special characters were in the mix.

Thanks for your report, but as JJworx already said this is sadly one of the known issues to which we don't yet have a good idea how to fix it. In T3459 there is an animation what is meant by "unselecting" the mails.

In addition GnuPG master and 2.2.8 now always create MDC messages (except with option --rfc2440) and always fail for messages without an MDC. For old algorithms a hint is printed:

gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
     likely that this message is legitimate.  This is because back
     then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!