Released on 2023-04-28 T6454
Details
Oct 10 2024
Sep 10 2024
Given that we backported it to gnupg22 we should go ahead and implement that flag. For example: if the flag is set for any root CA we will show compliance only if that flag is set for the specific root CA. This way we can introduce this feature w/o too much backward incompatibility. We could also hide the feature behind a compatibility flag. There is no reason why we should not add the de-vs trustlist flag to our vsd configuraion files, right away.
Sep 2 2024
FWIW: the encryption part of the ADSK feature has been released with
Jul 5 2024
Nov 15 2023
Nov 10 2023
Further investigation showed that this was due to a bogus key creating during I wrote the code.
Oct 25 2023
Oct 24 2023
While trying to replicate your findings I might have found a but in the import code which rejected one of the keys (using gnupg 2.2). I'll take care of this.
Oct 19 2023
yes, fixed
I think this was fixed with the fix for https://dev.gnupg.org/T6534
Oct 5 2023
@ebo: Du have the Ted Tester key (i.e. the ADSK key) also in you keyring?
Sep 22 2023
Encryption to the ADSK seems to work but I'm not sure if everything is displayed as expected.
Sep 21 2023
works in 22, too (tested with VS-Desktop-3.2.0.0-beta214)
Sep 7 2023
This has been well tested during development and is thus ready for a release.
Aug 25 2023
Jul 26 2023
From my side this can be closed. In Kleopatra we can maybe check for some more MIME types and then use GPGME_ENCRYPT_NO_COMPRESS but that is unreleated.
Jul 24 2023
Jun 12 2023
I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.
Yeah no progress for files larger then 32 bit o.O... But this used to work 😭
On 64 bit linux this works btw. so I think it comes down to the difference between 32 bit off_t and 64 bit off_t
Yeah, its the ugly off_t again. I am just testing how this works with single files above that threshold we worked quite a bit on this back in the days https://dev.gnupg.org/T2368
Yeah, probably a Windows/MinGW 32-bit problem. GpgME::Data does
off_t size = seek(0, SEEK_END); seek(0, SEEK_SET); std::string sizestr = std::to_string(size); // Ignore errors as this is optional gpgme_data_set_flag(d->data, "size-hint", sizestr.c_str());
Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.
Jun 9 2023
Mh, let me check where the size hint should come from and why it might be missing in my windows test. That is indeed strange then.
For me this does work also when decrypting:
btw. this does not work on the decrypting side because kleopatra there apparently does not provide a size hint. So it goes:
May 25 2023
May 17 2023
For me it works if I fully cancel (i.e. close the Window at the first prompt):
May 16 2023
May 9 2023
Apr 28 2023
Apr 27 2023
works with Gpg4win-4.1.1-beta295
Apr 26 2023
Apr 21 2023
I checked the upstream. For the reported issue, upstream version raises an error with REG_ERR_UNMATCHED_BRACKET.
That behavior is better (as we don't have particular reason to maintain different behavior from upstream version).
Also, I found another change from upstream for end of word check.