Python, CGI and PGP

[Jim Dennis]

In article <3c9fbf57 at peer1.news.newnet.co.uk>, Phil Edwards wrote:

> I'm trying to get a CGI app working that is supposed to be able to produce 
> PGP signed messages. The command line equivalent of what I'm trying to do 
> in the CGI script would be:

> /usr/local/bin/pgp -z mypassphrase -sta -f < /tmp/sometext.txt > 
> /tmp/sometext.pgp 2>/dev/null

> This works fine both at the CLI and in a bash script, and produces a text 
> file with the '-----BEGIN PGP SIGNED MESSAGE-----' stuff at the top and the 
> PGP signature stuff at the bottom.

> My recent attempts at getting this to work in the CGI script have been to 
> simply run the same command as above, but using either command.getoutput or 
> os.system from within Python. Doing this, I get the PGP signature block 
> that I would normally expect to see at the end of the message, but nothing 
> else. I suspect that the problem is down to the different execution 
> environment which PGP sees when it's being run within my CGI script, but 
> I've not been able to find anything in the PGP docs that has helped.

> I've done some research into this on the 'net, but I haven't been able to 
> find any recent references to PGP usage within Python. Some guys were 
> prototyping a PGP interface for Python 1.2 back in 1995, but there doesn't 
> seem to have been any further work done since then. Is there currently a 
> PGP module available anywhere? If not, can anybody point me in the 
> direction of a site that is using PGP and Python?

> FYI, my version of Python is 2.1, and my PGP version is 2.6.3 (don't ask - 
> just don't, that's all...you'll just start me thinking about it all over 
> again, and I'll probably start to hyperventilate...)

> Phil Edwards

 How are you feeding "sometext.txt" into the process in your CGI
 script?  Why now show us the actual fragment of code that you're
 attempting to use?

 When it comes to environmental issues (in programming) it's generally
 pretty easy to replace a target program with a wrapper script like
 so:

 	mv $ORIGINAL_BINARY $ORGINAL_BINARY.wrapped
	cat > $ORIGINAL_BINARY <<WRAPPER_SCRIPT
	#!/bin/sh
	printenv > /tmp/$(basename $0).$$
	. /some/where/$(basename $0).env
	exec $0.wrapped "$@"
	WRAPPER_SCRIPT
	chmod +x $ORIGINAL_BINARY

 ... this shell code is relatively terse (as well as concise) so 
 I'll highlight some of it's finer points in english.

 Rename the original binary (pgp in your case) to add a ".wrapped"
 extension (or whatever).  Put a new shell script in its place.
 The shell script will print the environment in which it is running
 into a temporary file (in this case a file named after the original
 binary with a PID (process ID number) as its extension).  Then the
 script will "source" (read-in and execute, as in the shell's equivalent
 of #include) another script from "/some/where/", that will have an
 environment that you've capture from a manual CLI execution, and 
 reformatted slightly as appropriate.  Be sure to add "export" commands
 to each of the shell variables that you have listed in ...
 whatever.env).  Finally you're wrapper script can exec the original
 (wrapped) binary with the original argument list.  Note that "$@"
 is a magic psuedo-variable in descendents of the Bourne shell
 (including bash, ksh and zsh) that will include all of the positional
 argument in such a way that the original argument separation (usually
 done with quoting and \ escaping) will be preserved). It must be 
 spelled exactly as shown (double-quote, dollar sign, at sign,
 double-quote) in order to have these properties.  Note also that the
 $(...) command substitution syntax might not be recognized by some 
 ancient versions of the Bourne shell; Heck! the "$@" might not work
 in some very old versions of sh --- though they both work in ash, which
 is about the most minimal modern Bourne shell).

 It should be obvious that you can do other almost arbitrary debugging
 work in this script.  For example you could cat your input to a 
 temp file (from a CGI POST) and end your script with an exec that
 would redirect from that input file; or you could have your script
 do a "while ! [ -f "/tmp/pauseflag.$$" ]; do sleep 1; done
 to allow you to set up an strace (Linux system call tracer) to watch
 it (with the -p PID option).  (Basically it would allow you to have
 the program "pause" until you could attach a trace utility to it; 
 then you'd touch the flag file and see what it was doing afterwards).
 Alternatively you might exec an strace -o .... program

 If you are reasonably persistent and a little clever you should be able
 to track down any problem that could be in your process environment
 using these techniques.  Other factors, especially permissions issues,
 can be harder to isolate and resolve; but these troubleshooting
 technique can still help with many of those.  As hinted, I find that
 strace and ltrace can be particularly informative under a Linux 
 environment.  Of course you can also find quite a bit of help in your
 system logging facilities (syslog) and your web server's logs.  With
 Apache it's also possible run a single, non-forking, instance of your
 web server process (httpd) using the -X option.  Using that with 
 strace's -f (follow) it's possible to examine how your CGI script is
 getting spawned by the web daemon.  This could also reveal some things
 that might not be evident from your wrapper script (though those are
 unlikely to interfere with your target's operations).