(In reply to Jon from comment #3)
Current: RNP, the upstream library processing PGP keys, is working on enabling key errors to not block import of good keys.
Currently, however, it's not working and this is an attempt to improve the experience temporarily to unblock testing other elements.
Actually, there will be different fixes to make this work. We'll have a separate fixes that will make that work shortly. We'll use a lenient approach on importing (ignore bad keys, remove bad sigs).
The intention of this fix here is: Don't allow people to kill their system by exhausting resources.
The release intention is that the actual process will step through a keyring of any size, skip (and log/flag?) failed keys while continuing through and importing the rest, and by doing this in a one-at-a-time manner, also limit memory use?
Please distinguish between the import mechanism that we offer in product, and the migration tool.
We intend to have a migration tool (managed by Patrick B) that can directly to GnuPG. If you talk directly to GnuPG, then you can control how many keys you export and import at once. I believe Patrick intends to do it one by one. If yes, then memory resources won't be an issue.
The code here isn't about the migration tool. Rather, it's about the scenario that some blob of data has been prepared by someone manually, and tries to import it.
Right now, due to developer constraints I want to have it like this:
- only offer large import as part of the migration tool (which will use the old way of talking to gnupg - using the executable)
- restrict import of data blobs to a size that won't cause us to run into resource exhaustion (with the current implementation to process everything at once)
- at a later time, we can try implement a better mechanism for importing large blobs of data; that will require the ability to split a big key block into the individual pieces, potentially by using future RNP APIs
(I'll note that this loop import process should probably by available for importing any keyring, and not only available from the enigmail migration process, though that's definitely the most important place for the release/transiton)
I agree that ideally we should have this ability eventually, but that's one of many TODOs, and as you say, we might postpone this a bit.