azureblue has asked for the wisdom of the Perl Monks concerning the following question:

I'm using Crypt::GPG in a script that takes text and files submitted via a web form and generates an encrypted email. If I run the script in a shell, the following statement works and returns encrypted data. But when called as a CGI, it returns 'undef'. 
$gpg->encrypt("Some plain text", $recipientID);

[download]
I've set the path to the gpg binary, and specified all the options required to ensure the encryption requires no user input (--always-trust --no-permission-warning --home /path/to/keys) and verified this in a shell.

I've tried setting some environment variables (TERM=dumb, SHELL=/bin/sh and LANG=C) early on in my script on the recommendation of a colleague, but it made no difference.

The script has been in active use for a couple of years on a now obsolete RedHat distro, and is being migrated to a current machine so the modules have all seen some updates. I'd rather not make any big changes to my script that are going to require changes at the recipient.

Replies are listed 'Best First'.
Re: Module works when run in a shell, but not when run as a CGI
by bart (Canon) on Jul 20, 2007 at 10:45 UTC
    Check $ENV{PATH} in both cases. It could be that the GPG binary isn't found, when run as a CGI.

    update Corion tells me to tell you to check the permissions for the binary/paths etc. too. After all, you're running it as a different user. Also, check if the environment isn't chrooted.

    Can you, for example, run `gpg --version`?

[reply]
[d/l]
      The path to the binary is explicitly set by one of the module options, so it's definitely finding the binary. However, there are differences between $PATH in a shell and $ENV{'PATH'} in the CGI, so I'll investigate that further.

      Update: Setting the path to be exactly the same made no difference.

      Update2: I do get the expected output from `/usr/bin/gpg --version`, which means I'm not being chrooted.

[reply]
Re: Module works when run in a shell, but not when run as a CGI
by atemon (Chaplain) on Jul 20, 2007 at 11:48 UTC

    Hi,

    Make sure that Apache/httpd has permissions to the directory/files where gpg key is imported (keyrings). When you import keys to keyring, you can specify the directory where the keyring file(s) need to reside.

    Cheers!

    --VC

    There are three sides to any argument.....
    your side, my side and the right side.

[reply]
      Now we're onto something. The permissions look OK to me, but: 
      print `/usr/bin/gpg --home /path/to/keys --list-keys`;

      [download]
      ...doesn't produce any output. I need to check more carefully. Thanks for the suggestion.
[reply]
[d/l]

        Hi,

        It looks like you are passing the wrong "path/to/key" or imported keys to wrong path. One important thing is, apache won't access the directories outside the document-root directly by default. In such case, you can try giving symbolic link under document root to the "path/to/key"

        --VC

        There are three sides to any argument.....
        your side, my side and the right side.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom