Gpgverify assumes wrong default gnupg setup (with patch)

[Russ Allbery]

Toon van der Pas <toon at hout.vanvergehaald.nl> writes:

> I think so too. The INSTALL text describes the indended behaviour, but
> the code doesn't implement it the way it is described.  The INSTALL text
> says:

>     "INN expects the public key ring to either be in the default
>     location for a PGP public key ring for the news user (generally
>     ~news/.gnupg for GnuPG and ~news/.pgp for old PGP implementations),
>     or in pathetc/pgp (/usr/local/news/etc/pgp by default).  The latter
>     is the recommended path."

> So according to the INSTALL text /usr/local/news/etc/pgp is the
> preferred location, but the default pgp/gnupg keyring location should
> work out-of-the-box too.  The comment in the gpgverify script agrees
> with this, but the accompanying code doesn't.  It simply doesn't work
> with the keyring at the default location.

I understand that gpgverify has a problem here (and we'll fix that), but
you were claiming that pgpverify had the same problem, and so far as I can
tell, it doesn't.  Was I just misunderstanding?

> It doesn't fall back to the default keyring location when there
> is no keyring available at the location /usr/local/news/etc/pgp.

That's not what the man page says.  :)  The man page says that it falls
back to the default keyring location when the *directory* doesn't exist.

>> if (! $keyring && $inn::newsetc) {
>>   $keyring = $inn::newsetc . '/pgp' if -d $inn::newsetc . '/pgp';
>> }

>> Why does this not work for you?

> Well, that should now be obvious, given my explanation above.
> It doesn't fall back to ~/.pgp and/or ~/.gnupg for the keyring location.

That's exactly what the code above does.  It leaves $keyring unset if that
directory doesn't exist, which will cause PGP and GnuPG to use their
default keyring paths.

Are we just talking past each other somehow?  You're saying that the
pgpverify man page is wrong, but the code implements exactly what's stated
in the man page.

I'd be happy to fix bugs here, and I can go make gpgverify match
pgpverify's behavior, but so far I can't see what's wrong with the current
pgpverify code.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.