'pubring.kbx' growing
Bernhard Voelker
mail at bernhard-voelker.de
Fri Jun 14 23:20:05 CEST 2024
Hi Werner,
On 6/14/24 17:28, Werner Koch wrote:
> Hi!
> only some quick notes: The pubring.kbx will indeed grow unless you
> delete keys and newer keys fit into that file space.
It's not "newer keys". It's the same key again and again.
And new keys don't "fit into that file space" as you say:
simply 'gpg --import' + 'gpg --delete-key' in a loop.
> However, after
> about 3 hours a compress run is done and the deleted file spaces are
> removed. The entire file won't shrink because the unused spaces is
> marked for re-assignment.
That does not appear to happen. The file is just growing.
> You should not use 2.2 - that is our LTS version which is pretty old.
Agreed (in theory), still, there's not much choice on LTS versions of
company-level distributions.
> Better update to 2.4 and use that.
Confirmed: the problem still exists with the KBX format on 2.4.5, as mentioned.
> With this version you can use the
> keyboxd to handle large numbers of keys much more efficient by employing
> a database daemon. See the section on the keyboxd in the README.
I also confirm that the problem does not exist with 'keyboxd';
as 'keyboxd' is using an sqlite DB, the problem is easily avoided there.
GPG 2.2 went away from the 'pubring.gpg' file format to the keybox format,
but the KBX format doesn't behave the same as it's direct predecessor;
therefore, I tend to say this is a regression.
BTW: is the 'keyboxd' reliably already available in 2.2?
> Sorry, I have not the time to look at you detailed description.
Sorry, I didn't look too much into the implementation of the KBX format,
but - as long as there's no general design issue with it - I guess this
should be fixable quite easy. Please re-consider checking this, and
I'll be gratefully forwarding the fix to the SUSE folks.
> Shalom-Salam,
> Werner
Thanks & have a nice day,
Berny
More information about the Gnupg-devel
mailing list