GnuPG 1.1.90 released

David Shaw dshaw at
Wed Jul 3 16:40:02 CEST 2002

On Wed, Jul 03, 2002 at 02:17:53PM +0100, Ian Jackson wrote:
> David Shaw writes ("Re: GnuPG 1.1.90 released"):
> > The photo viewers and keyserver helpers run in a separate process, and
> > inherit nothing except stdin/stdout from the GnuPG process.  The
> > interface was intentionally written to make sure that there was
> > nothing that a executed program could do to GnuPG that the user could
> > not do on the command line.
> The helpers can ptrace the gnupg process (if gnupg is not set-id) or
> the user's terminal emulator, or preempt gnupg's terminal input, or
> fake up terminal input using fancy tty ioctls, or change the user's
> configuration to run a trojanned version of gnupg, or ...
> There is no point attempting to defend against malicious code running
> with the same UN*X uid.

Right.  I said all this in my original post.  "...nothing that a
executed program could do to GnuPG that the user could not do on the
command line."  This is not news.  This was a design goal.

A malicious extension however runs within the GnuPG address
space. Forget malicious code running with the same uid - this is
malicious code running within the process!

Like I said before, this is something that users can do now.  All a
module-path does is to give them a bigger gun to shoot themselves in
the foot with.  Not necessarily a bad thing if they know what they are

My current inclination is that doing this is ok, but to add permission
and ownership checks on the enclosing directory to go along with the
existing ownership check of the extension file itself.  That can at
least catch obvious configuration mistakes.  Werner, what do you


   David Shaw  |  dshaw at  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

More information about the Gnupg-devel mailing list