I just tried the newest beta and I can confirm that sending Office attachments does work for me with this version.

Added gpgol and gpg4win project tags as this is important for these projects.

I was unable to figure out what the difference is between the handling of Office files and other files and why it comes to this error.

Thanks for the report.

I can reproduce the issue and give it high priority. This is a curious problem of Outlook triggered by the improved send code in Gpg4win 3.1.3.

Here's the debug log file.

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.