lock-never usage

[Patrick Higgins]

I'm writing an application which will use fixed keys and trustdb.  It's
essentially client/server--each client will have the server key in it's
keyring (fully trusted) for signature verification and encryption, and
it's own keys for decryption and signing.  As these are essentially
read-only operations (I don't know the internals of GPG--are the key
databases modified by these operations?) I assume it would be safe to use
lock-never even though multiple processes might access the databases at
once.  The main reason I want to use lock-never is because all my
filesystems are mounted read-only.  I've had to create a read-write
ramdisk just for GPG 1.0.1 usage, which didn't have the lock-never option.  
Is this safe?

I'll probably want to use locking on the server, as I'll need to import
client keys peridiocally.  However, I've already run into some problems
with this during testing of 1.0.1.  Specifically, I was serializing GPG
requests (something that won't happen in production) and found that on the
9,557th trial I received this locking error:

gpg: failed to create temporary file
`/tmp/gpg/transzap/.#lk0x80cb030.phiggins.13311': File exists
gpg: fatal: /tmp/gpg/transzap/trustdb.gpg: can't create lock

The contents of my GNUPGHOME directory show some lingering lockfiles, even
though there are no running gpg processes:

[phiggins@phiggins]$ ls -a $GNUPGHOME
./			      ../	   secring.gpg
.#lk0x80cb030.phiggins.11828  options	   trustdb.gpg
.#lk0x80cb030.phiggins.13311  pubring.gpg

The failed lock attempt error message is the output of the last gpg
process to run on the system, so it looks like there are some problems
with lock-file cleanup in 1.0.1.  Have these been fixed in 1.0.2?  I
didn't notice anything in the ChangeLog, but then again, the ChangeLog
doesn't mention the new lock-never option...

I've also been using expect to generate keys unattended.  I see there's a
new --batch command to 1.0.2, but is not well tested and only appropriate
for special applications.  Is it at least better than using expect with
the old --gen-key?


-Patrick