Move back to the backlog and trigger re-evalutation of priority (which was high).

And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

I agree that the "future" won't come, ever. (for libgcrypt)

works

works

It does not work as described for subkeys with later expiry dates if the primary key has already expired:

I doubt that we will ever be able to use the flexible array thingy. The old pattern has been used for nearly 50 years and replacing it will just introduce bugs.
Do you use offsetof for that reason?

I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.

I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.

Thanks, we will take care of this.

Let's fix this in Libgcrypt (ignore setting of the handler)

This is related to T6511

Another approach would be having "non-hash" algo for gcry_md_open.

Before adding FIPS support flag and tests, we need to modify implementation:

• Adding PCT check for EdDSA
• Adding support of gcry_pk_hash_sign/verify API for EdDSA

Thanks. I think that it was the oldest one: FSF used to be there in Cambridge, then moved to Tremont St. in Boston, and now it's in Franklin St.

FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched:

In the past this was done by --set-filename in libkleopatrarc-win32.desktop. But I am happy if we close this and focus on T6530.

I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.

Which only works if gpgtar actually knows the input file name (which it will once T6530: GPGME / QGpgME Extend Archivejobs to accept input / output from a filename is done and used).

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());

Well staying at 0 is imo worse then knight rider because that looks "stuck" and knight rider looks "working".

Well the progress is by file and type of import (OpenPGP, S/MIME, groups). Is importing a 38 MB keyring really a use case that is worth changing perfectly working behavior? People, rightfully, hate knight rider progress because it gives no indication at all when it's finished.

So we basically let gpgtar pick the folder name again.

Yes. I think for now we should ifdef the directory change to Linux, must be done in GPGME I think. I know its ugly to have it differently on both plattforms but while extracting in a subfolder might be more uncomfortable our users are used to this and this resolves the issue until we have better options with KIO.

I wasn't aware of this behavior (on Windows), i.e. the behavior change wasn't intended.

Ok

There is already an additional handleExternalCMSImports which does

// For external CMS Imports we have to manually do a keylist
// with validation to get the intermediate and root ca imported
// automatically if trusted-certs and extra-certs are used.

Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.