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.

ingo may have tested on linux where we never actually used gpgtar.

No. I only noticed a difference of the behavior between gpgtar on the cli and Kleo. Ingo said the behavior in Kleo has always been the same, gpgtar an Kleo differ in that. Case was therefore closed for me.

Left is the old behavior after "save all" right is the new behavior after "save all"

In T6336#166815, @werner wrote:

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

I consider the entire idea of receiving a passphrase and data on the same channel to be a bad for security and robust coding. The whole thing is a historical oddity which we kept for the sake of mutt(1)'s legacy way of invoking pgp. Thus I won't consider 3) the best option.

To summarize, here is the situation:

• Ideally, it would be good to modify GnuPG and Emacs EasyPG to implement status handling and input handling in better way.

Ah, I see https://dev.gnupg.org/rG2f872fa68c6576724b9dabee9fb0844266f55d0d applies cleanly. I guess can go with that, although would prefer it if on the 2.4 branch.

Is there a commit we could backport downstream to 2.4.x? We've had quite a few reports of this.

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:

With my fixes I now get this:

Actually two bugs. Easy to test on Unix with a small (e.g. 10MiB partition).

Of course, those are different controllers. :-)

btw. this does not work on the decrypting side because kleopatra there apparently does not provide a size hint. So it goes:

As I already had my testsetup open I recompiled with your change and I tested manually cancelling and letting it run into the disk full error. In both cases the temporary file was deleted and the job was cancelled :)

Seems to be gnupg 2.4. ec 112 is ERROR_DISK_FULL.

The processes should now be killed properly.

Oh my, so I have not really tested this for nearly three months and had my head in the send when reviewing it. I really need to apologize for that. The performance improvement is _not_ what I hoped for if it is even there.

Please note that my test was not on an USB Device. I will keep this issue with your analysis and reopen a different one with my error and details on how to reproduce that one. Pretty sure it was disk full.

I don't think this is a regression or something we can do anything about. Note that we see the same thing also on the command line. Actually I have seen the very same thing pretty often with USB devices. Thus lowering priority.

Just as a background. This issue and others basically ended a project where dan and me worked on with a customer (you know who) to make Kontact from KDE 4 usable for them back in the day. The calendar was just too unreliable and this was one of the causes we identified. This does not mean that it will fix the unreliableness that we see with our calendars at work, but it is an issue that should be fixed.

We have seen this problem in the QA this week and could identify that this was a ERROR_FILE_INVALID (ec=1006,"The volume for a file has been externally altered so that the opened file is no longer valid"). We also noticed disk errors in the event logger but did not recorded them. The USB stick was not unplugged but merely used with VirtualBox.