A new Idea which I'll have to test:
Register an event handler for each folder in which a decrypted item is read. "Mailitem->parent" In this event handler listen to the beforeitemmove event. In that event then close the mail / discard the decrypted contents.

Thanks a lot!

Will be fixed with the next release. With the next release kleopatra will only set "allow-version-check" once except if the user explicitly selects "help -> check for updates".

Right. The only way to disable it is if an update notification pops up. If you then unselect "Show this notification for future updates" it is disabled. And you only get to that dialog if there is an update check.

Ahh there we go... I just did a --recv-keys to update from the keyserver and that picked up the extended expiration date.

The problem here is that we we did not sync the pubring with the secring in old version (2.1 removed the secring concept also due to that syncing problem). Now if we migrate (or plainly import a secring.gpg), gpg does not see any updated self-signatures and this is the reason why outdated self-signatures are used.

I implemented it in master and if you agree I will backport it to stable. This is the new output:

Am 21.06.2018 um 10:31 schrieb aheinecke (Andre Heinecke):

aheinecke added a comment.

Beware: Beta-7 was bad timing, yesterday I was in the middle of
implementing T3999 https://dev.gnupg.org/T3999 and broke the
internal keycache. If you use "Empfängerschlüssel automatisch
auflösen" please switch back to a different GpgOL Version. I might
upload a new Beta soon but for now I've removed Beta-7. Automatic
resolution will not work with that version and can lead to crashes.

*TASK DETAIL*
https://dev.gnupg.org/T4037

*EMAIL PREFERENCES*
https://dev.gnupg.org/settings/panel/emailpreferences/

*To: *aheinecke

*Cc: *aheinecke, JJworx, Rafixmod, ccharabaruk, Mak, gp_ast

This is an automated email from the GnuPG development hub. If you have
registered in the past at https://bugs.gnupg.org/ your account was
migrated automatically. You can visit https://dev.gnupg.org/ to set a
new password and update your email preferences.

Beware: Beta-7 was bad timing, yesterday I was in the middle of implementing T3999 and broke the internal keycache. If you use "Empfängerschlüssel automatisch auflösen" please switch back to a different GpgOL Version. I might upload a new Beta soon but for now I've removed Beta-7. Automatic resolution will not work with that version and can lead to crashes.

Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.

Thank you for your feedback.

Thank you for pointing this out.

Following patch fixes the issue.

We should include the man page then in texi format into tools.texi

Yes, that did the trick for me!

Nice, then my commit should fix the issue here.

Yes, definitely the real reason is in the inline editor.

I can't confirm the regression yet. For me (albeit with Outlook 2016) preselecting sign / encrypt based on the options works for reply and forward. But only as long as the Mail is opened in a dedicated window.

It's manually written one in Debian:
https://salsa.debian.org/debian/gnupg2/blob/debian/master/debian/gpg-check-pattern.1

Thank you for your fast fix!
2.2.1-beta2 works as expected!

Applied to 2.2 branch.

For the problem in the last comment, it was fixed in T2928: stop fetching PTR records entirely.
For the original issue, it looks that EINVAL is returned by the system call of connect(2).
That's quite strange, but, it was possible for IPv6.

Hi Werner,
I have performed some experiments on the issue I have and the following are the results:

As expected it was a very clear bug. We assign a NULL pointer to a string and then use that string.

Thank you for the report and the logs! A minor note: For future reports please leave the priority on "Needs Triage" we use this as a marker for issues no developer has looked at previously.

Fixed in repo (master and 1.8 branch).

Thanks for your report.
You are right.
Simply getting the information for "rng-type" through gcry_rndjent_get_version will hang.

Investigated the "why not with glibc" question this morning, appears that the test triggering the hanging behavior (version) happens to not be linked with -pthread and so locking calls do nothing. Manually adding -pthread causes it to hang with glibc as well.

See also: https://github.com/NixOS/nixpkgs/pull/42150

Thanks for forwarding.

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