GnuPG 1.1.90 released

[David Champion]

* On 2002.07.02, in <20020702231940.GF4624 at akamai.com>,
*	"David Shaw" <dshaw at jabberwocky.com> wrote:
> 
> --module-path scares me a little as it can be abused in certain cases
> on multiuser systems.  For example, say someone sets their module-path
> to include a world-writable directory.  All an attacker would need to
> do is to drop a bogus "idea" or other module in there to subvert the
> system.

Two things strike me:
1. It's not really gpg's problem. I can set LD_LIBRARY_PATH=/tmp, too.
1b. Even if it is gpg's problem, precedent allows for --expert to
permit it. :)

2. It would still affect only the user who does dumb things with his
--module-path, not the whole system. The administrator/installer could
set
	module-path /tmp
in options.skel, or something, but I'm not sure how far you want to go
protecting against that kind of mistake. They could leave the bin
directory world-writable, too.


> There is a similar problem with the photo viewers and keyserver
> helpers, but these programs are already assumed to be untrusted and/or
> potentially hostile (and if someone has a subverted $PATH, then the
> attacker could just replace gpg itself).

Basically, I don't really see what the difference is among these three
trust categories (module path, photo viewer, keyserver helper). All are
susceptible in the same ways, it seems. I don't see that one is more
vulnerable than another.

And anyway, I think it's more likely that someone would set $PATH awry
in his .shellrc than that he would unwittingly set module-path in his
.gnupg/options, if we can use that as a baseline to measure other risks
against.

-- 
 -D.			Fresh fruit enriches everyone.  Takes the thirst
 ENSA, NSIT		out of everyday time.  A pure whiff of oxygen,
 University of Chicago	painting over a monochrome world in primary colors.
 dgc at uchicago.edu	We all know that.  It's why everyone loves fruit.