Page MenuHome GnuPG

when sending large keyrings to server, should send in many small pieces
Closed, ResolvedPublic

Description

Release: Debian 1.2.1-2

Environment

Debian Release: testing/unstable
Architecture: i386
Kernel: Linux stonewall 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Versions of packages gnupg depends on:
ii devfsd 1.3.25-12 Daemon for the device filesystem
ii libc6 2.3.1-14 GNU C Library: Shared libraries an
ii libldap2 2.0.27-4 OpenLDAP libraries (without TLS su
ii makedev 2.3.1-62 Creates device files in /dev.
ii zlib1g 1:1.1.4-10 compression library - runtime

Description

When I send my entire keyring to a keyserver, gpg allocates all the
memory needed and then sends it. While this is excellent for small
keyrings, for a large keyring (mine is 28M), it is inefficient,
especially because for larger and larger chunks, allocating memory gets
slower and slower. I propose that gpg send large keyrings in small
chunks to avoid this memory allocation problem. In addition, this will
avoid any problems that the server might have with limits on http parsing
or with limits on mail size (postfix does not seem to like 28M messages,
and pksd uses mail to add keys).

The final few lines are enclosed:

gpg: DBG: increasing temp iobuf from 41312256 to 41320448
gpg: DBG: increasing temp iobuf from 41320448 to 41328640
gpg: DBG: increasing temp iobuf from 41328640 to 41336832
gpg: DBG: increasing temp iobuf from 41336832 to 41345024
gpg: DBG: increasing temp iobuf from 41345024 to 41353216
gpg: success sending to `castro' (status=200)
bmc@stonewall:~%

Please note the outrageous amount of memory used (approximately 41.3M).

Fix

This is a feature to help the poor keyservers :-)
We won't change this in 1.2.

Release Note

Fixed in 1.3.90 and earlier.

Event Timeline

werner added a subscriber: werner.

Should we make sending large amounts of keys cheap?

The code has changed and does not anymore takeup too much core.