Package: gnupg Version: 1.4.1-1 Severity: important
i hope this will make sense to you. please ask if it does not. this is REALLY important to some people. over the years gpg has gotten harder and harder to script properly(1), and what used to work no longer works(2). the big issue is that gpg has clearly been designed with the assumption that a homedir, such as ~/.gnupg or one specified by an option or env var, is always there to be written to or read from, and that it is never necessary to export or import an entire homedir verbatim. these assumptions seem reasonable at first, but it creates a nightmare for shell scripting. gpg should not ONLY be usable with a homedir, or if it is, it should be possible to export and import a homedir without changing it. for fully encapsulated shell scripts, we want the homedir information (public and private keys, mostly) to be in the script itself. ascii armoring is perfect for this, but there is no --export-homedir option. it appears to be impossible to export an armored homedir. so we try to fake it by using the --export, --export-secret-keys, and --export-ownertrust options. these options are not only non-orthogonally-named, but they are no longer sufficient. they used to be until version 1.4.1. there used to be all sorts of problems with getting gpg to stop complaining about trust levels, but they were possible to work around with kludges (such as updating the trust db each time a temporary homedir is created, redirecting streams to /dev/null, using --batch, --no-tty, and -q judiciously, and hoping that nothing important is being turned off). now it is completely impossible. the homedir information is actually changed upon exporting. ultimately trusted keys are no longer ultimately trusted after exporting (and gpg outputs cryptic messages like "gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u" that are hard to find explanations for in the docs). this might be good for most uses, but for shell scripting, it is a nightmare to figure out what is wrong and try to fix it. maybe we're supposed to somehow edit-key the key in batch mode. maybe export-options has a hidden option for keeping the homedir intact. dunno. but even if we somehow solve it, we fear the next release of gpg, which could change everything around and make it impossible again. you might think we're swimming against the tide by using gpg in an unintended way, but i don't think it is that unreasonable. it is a general principle of software design that things should be in a single place if possible. serialization of the homedir using uuencode and the like are unsuitable workarounds because a script should only have to depend on gpg, not gpg and a uuencoder. ascii armoring is built into gpg, but is not usable any more for exporting the information that is needed in this case. it was barely possible before, but appears impossible now. the second problem is that it is never clear when a command will try to access a homedir. for example, some users want to be able to tell what key a file is encrypted to, so it is natural to try something like gpg --list-only to do so. however, gpg tries to access the homedir even though some information does not require the homedir. its complaints cannot be turned off. this is only an example of how the .gnupg assumption by the developers affects shell scripting. thanks. i hope this made sense to you. 1. proper scripting in this case means having all necessary information in a single place -- the shell script itself. as soon as there are 2 places for things, problems can occur. this is a general principle of computer programming, of course, not just a shell scripting thing. 2. gpg has gotten extremely complicated with its trust options, and i cannot tell from the docs whether it is truly impossible or merely extremely difficult. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11--from-2.6.9-proc-config-and-menuconfig Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gnupg depends on: ii libbz2-1.0 1.0.2-6 high-quality block-sorting file co ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libldap2 2.1.30-8 OpenLDAP libraries ii libreadline5 5.0-10 GNU readline and history libraries ii libusb-0.1-4 2:0.1.10a-9 userspace USB programming library ii makedev 2.3.1-77 creates device files in /dev ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
