Thanks for your answer. So i think we must wait for the Update and downgrade to 3.1.2.

Da wir eine internationale Software sind bevorzugen wir in diesem Tracker Englisch. Ich hoffe das ist ok.

Thanks for the report. I was not aware of this but Indeed the fix should be easy. I think I already know the cause ;-)

Thanks for the clarification.

Which is the correct way to handle this. We merely gave the MDC packet a standard packet structure so to help with debugging. Decryption needs to defer the 22 bytes to be able to detect the MDC packet.

Perhaps, the missing length information in compressed data packet is confusing. The length can be determined by the assumption of existence of 22-byte MDC packet.

Here is my understanding.

I'm looking at my personal Inbox on both computers.
I received the encrypted mails, before I connected computer B with my Account
And yes, I'm using an exchange connection.

Thanks for the details. I tried to reproduce it but again for me it works. Still I give this high priority as this can be a blocker in deploying GpgOL and we should fix it for the next release.

I have additionally the problem, that signed and encrypted S/MIMI messages are handled by GPGOL even if S/MIME support is disabled.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released. This issue can be closed. Hurray!

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Closing.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released

By grabbing I guess you mean that the cursor / keyboard input is automatically focused on the input field? I also noticed that this sometimes does not work well.

I can see MDC packet of 22-byte (which starts by 0xd3 0x14, and then 20-byte SHA-1 hash), when SEIP data packet is decrypted.
I don't see your situation.
How about with no compression (-z 0)? I mean, compression is not applied to MDC packet.

https://www.gpg4win.org/version3.1.3.html < beta28 has the fix. If nothing untoward happens this will be the final version to be released tomorrow.

I can't reproduce it. I don't get the Properties have changed dialog.

We have debug output now to show which commands are running.

I've tried again with different Versions to rerproduce this issue and I can't reproduce it.

I did not find any differences regarding junk mail. So I believe that this is fixed with T3459

There is no way for us to fix. It is a shell issue.

@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?

--verify-files is mostly useful for scripting and and not for manual checking. With scripting etc you always need to use --status-fd and with that you get:

I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.

Hooray!

We are actually in the final release preparation and just waiting for GnuPG 2.2.10. If everything goes well it will be released this week. If not, next week.

Sweet, thank you! Any estimate on when that might come out?

yes

excellent - will this be includedin gpg4win 3.1.3?

Thanks. I can work with that. It is indeed clearly visible what the "Sent on behalf of" address is. So it makes sense to check that, too.

Sent two messages to the test mailinglist. Please let me know if you need / want more.

Will be in 2.2.10

Yes that would work for me and the pgp key is the right one. Thanks!

Actually, I can add you to a test mailinglist and send you a signed message tomorrow, would that work?

Ok! If outlook shows it we should verify it.

Hi Andre!

This was actually reported against 2.0.31 which reached EOL 8 months ago.

Without KEYLIST_MODE_WKD I also can't implement the desired behavior in a MUA using GnuPG.

Why the restriction to keyorg wkd ?

Done. To be released with 2.2.10.

T4026 is a bit related. I'm suprised that the signature check for mailman mails works at all for you ;-)

Thanks for the input. GpgOL should check against what outlook shows as the "From" Address. In your case: What does Outlook show? Is it "info@example.org" or "puppets-bounces" ?

No response so closing as invalid.

Thank you for the clarification. For now, I'll modify our implementation to use shorter length representation and close this bug as Invalid.
However, I'm still not convinced that using hard-coded arguments is the right way to handle requests. I'll do some more testing and if I discover a legitimate use-case that requires long APDUs, I'll reopen the issue.

I'm not sure if it's exactly the same case, but:

This entry was created based on the conversation at #gnupg channel.
I can't reproduce keep hanging.
I confirmed that pinentry vanished (perhaps, because of timeout).

gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.

We are moving to use the yat2m from gpgrt (libgpg-error); thus the additional tag.

Hi,
Can I ask if there is any update on the issue that I face?

Thanks for your answer

Ok
Thanks for your answer

I'm not sure that I understand your Problem. It might be helpful if you could provide screenshots of your problem so that we can better understand it.

We are not a CA and do not provide certificates.

There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.

Thanks for the information.

In our implementation, DO 0x6E contains:

I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?