Three questions on trustdb.gpg

[George Sinclair]

Hello,

I'm running GPG ver 1.0.4 (fully patched) on Solaris 2.5.1. My
question has to do with permissions on trustdb.gpg and encrypting
files. If I change the permissions on said file from 644 (-rw-r--r--)
to say 444 (-r--r--r--), and then I try to encrypt a file as:

      gpg --encrypt -r user filename

I receive the following error:

      gpg: fatal: /export/home/user/.gnupg/trustdb.gpg: can't open:
Permission denied secmem usage: 1920/2944 bytes in 5/9 blocks of pool 3296/16384

Likewise, I receive the same error if I attempt to decrypt a
previously encrypted file, unless 'trustdb.gpg' has write mode set
for the owner.

However, if I reset the permissions to allow owner write access, the
encryption works like a champ.

1. Why is write access required on 'trustdb.gpg' in order to encrypt
or decrypt a file? I would have thought only read access would be
necessary? The error message seems misleading as it ostensibly
suggests a problem reading it, not writing? Moreover, there's no
difference between 'trustdb.gpg' before and after the
encryption and no time stamp change, only a time last accessed
change). Therefore, it seems that GPG is certainly not writing to this
file. 

2. Why does signing or verifying a signature not complain about
'trustdb.gpg' not being writable? You'd think if encrypting something
required write access then signing something would too - okay, maybe
the first time, but not after.

3. I had my heart set on having ~/.gnupg, excepting the 'random_seed' file,
placed on read-only media for extra protection. This assumes, of
course, that I'm not going to be making any changes to the secret or
public key rings. It would appear, however, that both 'random_seed'
and 'trustdb.gpg' will now BOTH need to be on spinning disk with user write
access. Is there any way around this?

Thanks.

- George | gsinclair@nodc.noaa.gov