Your message dated Tue, 10 Jun 2008 02:48:26 +0200
with message-id <[EMAIL PROTECTED]>
and subject line gnupg: fully exportable armored homedir is completely
impossible now!
has caused the Debian Bug report #310805,
regarding gnupg: fully exportable armored homedir is completely impossible now!
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
310805: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310805
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
I'm going to close your report. Upstream has clearly rejected your
request.
Please feel free to comment on this decision and/or reopen your report
if necessary.
Regards, Daniel
--- End Message ---
