I'm working with someone in a different division, that we FTP an encrypted file to. They process the file, then place an encrypted exception report on the FTP server for us to pick up and use. The encrypt part on my side (outbound) works fine. The issue is on their side when they try to encrypt the file back to us. They are running PGP on a Unix box (don't know what flavor). I'm running GnuPG on a Windows server. Their PGP public key works correctly when I encrypt. When they try to encrypt with my public key, they have an issue. The script file runs fine if it's ran manually. If it's fired by a chron, it gives them:
"It is NOT certain that the key belongs to the person named in the user ID. If you "really" know what you are doing, you may answer the next question with yes."

from her e-mail, they’ve tried various things:

I have tried the following:
deleting and replacing the key
trying the userid on the key in a variety of ways - as delivered (jdiaz@azdes.gov), as the 8-byte value (AB96877A), with the first two characters of the userid capitalized, with the first portion of the userid all caps, and with the entire userid all caps.
using the sub-key as the userid
using 'lsign' when I signed the key instead of 'sign'
using 'fully trusted' instead of 'ultimately trusted'

Is there a way to automate the 'yes' response?
Anyone have any better ideas?

That is probably your problem right there rather than encryption/decryption. It is quite common for commands that run at command line to run fine but fail when run by cron. This has to do with the environment used. When a script is run from command line the script "inherits" the environment which was set when the user logged in. Cron jobs on the other hand only have minimal environments and don't inherit much because no user ever logged in.

You COULD (but shouldn't) do something like making the cron job call a script that does something like:
The user would be the one you successfully ran it as from command line - the "-" would make it invoke that user's environment before running the pgp script.

The reason I say you shouldn't is because often there are things in /etc/profile, /etc/bashrc, $HOME/.profile, $HOME/.bashrc etc... that deal with terminal or display neither of which will exist for a cron job started in background. You end up with ugly messages in your logs though it would usually still work.

A BETTER way to do it is to determine which environment variables are needed by the script and include them in the script. The most common one that causes problems is PATH (type echo $PATH to see what is set to at command line). Often in a script you'll type something like:

ls -l | grep 2006 | awk '{print $NF}'

The problem with above command line is it assumes knowledge of where to find the ls, grep and awk commands. If the directories that contain these are in PATH then it does have that knowledge so would work from command line. However, cron's minimal environment won't have a major PATH set so may not find all (or any) of the commands. So in your script you can do something like:
PATH=/bin
ls -l | grep 2006 | awk '{print $NF}'

Since all 3 of the commands are IN /bin it will find them. Obviously if you had commands elsewhere (e.g. /usr/sbin) you'd want to add that to your path as well. e.g.
PATH=/bin:/usr/sbin

Another way to do it create a variable for each command then use the variables within the script. e.g.:

LS=/bin/ls
GREP=/bin/grep
AWK=/bin/awk
$LS -l | $GREP 2006 | $AWK '{print $NF}'

Your message seems to indicate the decrypt or encrypt command is being called successfully but it may be an earlier command in the file failed or that the command relies on some other variable setting (e.g. user's $HOME) that isn't set because it was called from cron.

Have the user type "echo $0" to verify shell they are in. Above applies to Bourne/Korn based shells such as sh, bash and ksh but settings would need to be different for things such as csh.

The script in question is calling PGP to encrypt a file using a public key generated by GnuPG. When the script is manually ran, there is no 'are you sure?' stop. When the script is ran as a scheduled item, it stops to ask a question. Is there a way to force a 'yes' as part of the script?

So you're basically ignoring what I gave you as the most likely culprit?

No, I'm not ignorning what you posted. On a good day, I can spell Unix. As a Windows(VB.Net, C#.Net) / COBOL programmer your reply made no sense to me at all. I've passed the information along to the person that's having the issue. When I read your post, I felt that I hadn't correctly stated what the intent of the script was. My bad.

I focused on what I thought was a key (pun intended) part of your post but perhaps I misread it so let me restate what I thought I saw you say:

The script runs fine from command line but has a problem when run in cron.

If it runs fine from command line then the script and its contents are not a problem per se.

However, if this same script does NOT work in cron then obviously there is a difference between the way it runs in the command line and the way it runs in cron. My post was trying to explain why those differences would exist.

Amplifying that: It is not unusual to get errors that lead you to believe the issue is one thing (e.g. a problem with the encryption command) when in fact it may be that an earlier issue (e.g. a variable you tried to declare using another command) failed so when it got to the encryption command it wasn't executing what you thought it was.

P.S. Speaking of spelling - you misspelled "cron" in your original post. It is not "chron" (though it probably should be by rights).

P.P.S. The intent of my original post was not to insult - given that I don't know you, I have no way to know how much explanation you would need.

P.P.P.S. You might consider getting yourself a Linux box to play with to test things out for yourself. UNIX/Linux really is quite a different animal than DOS/Windows. Many of its tools have no analog in Windows.

The problem occurs, because when you run a script from the command line, it automatically gets environment variables. When the same script is run from cron no env. variables are sourced.
Normally the variables are placed in .profile file in the home directory. You may want to source this .profile file in your script. Put
. ~/.profile
somewhere near the top of the script, like so...

--------------------
#! /bin/<shell>
. ~/.profile
rest of the script.
--------------------

Second option is instead of sourcing the entire .profile you may explicitly define the env. variables used by your encryption/decryption program.

This is what I have to do on my script to decrypt my encrypt file from my vendor with cron job.

/bin/echo passphrase | /usr/bin/gpg --no-tty --batch --passphrase-fd 0 --quiet --output /decrypt_filename --decrypt encrypt_filename

They (teh people who are encrypting file for you using your publick key )need to create secret key and private key and sign your public key. This way the signature will be stored as a seprate file and your key will be marked as signed abd gnupg will not keep asking for its authenticity on command prompt.

good luck
Krishan Gopal (PHP Dev)

milepearl, we value your time and energy, and encourage you to spend it helping members with current issues. I'm closing this zombie thread so that it may rest in peace. Please don't make a habit of necroposting.