Hi Robert,
Many thanks for your email.
I will try to give you the background of the problem that led me to this
approach.
*Problem:*
I have a situation where the password-protected PGP/GPG encrypted files
need to be decrypted, processed through ETL operations and loaded in HIVE.
I had a generic Korn Shell script which executes below command.
cmd 1:
*gpg --batch --yes --quite --always-trust -o $OUTPUT_FILE --passphrase
$PASSPHRASE -d $ENCRYPTED_SOURCE_FILE*
But, this command had a risk of exposing *$PASSPHRASE* to the UNIX console
if any user executes *ps -ef* command while the code is running. This was a
huge security breach so I chose the *--passphrase-file* option to read the
decryption password from a file.
Now, all I need is to place the file, which stores the decryption password,
with strict user permissions.
Having said that, just to add a little bit of more security I was thinking
of encrypting the above mentioned file (which stores the Decryption
password) and within my shell script, decrypt it, read it and pass the
password to the "*gpg*" command.
This encryption needs to be passwordless using 7za utility otherwise we
will be stuck in a loop of storing the new password securely.
Below 7za command was used to encrypt without password.
cmd 2:
*7za a -mx=9 -mhe -t7z $ENCRYPTED_OUTPUT_FILE $SOURCE_FILE*
Now "cmd 1" has been updated to the below command, which UNIX shell script
will use to read the above file and pass on the passphrase to the gpg
decryption command.
cmd 3:
*echo `7za -x -so $FILE_WITH_DECRYPTION_PASSWORD` | gpg --batch --yes
--quite --always-trust -o $OUTPUT_FILE -d $ENCRYPTED_SOURCE_FILE *
The problem I mentioned in my original post starts from here.
The above command doesn't run and fails for "No secret Key found" issue and
runs fine if it is executed immediately after the second part of command
i.e. *gpg --batch --yes --quite --always-trust -o $OUTPUT_FILE -d
$ENCRYPTED_SOURCE_FILE*
There is a similar command as mentioned below, which runs fine.
cmd 4:
*echo `7za x -so $FILE_WITH_DECRYPTION_PASSWORD` | 7za x -o$OUTPUT_FILE
$7Z_ENCRYPTED_FILE*
Please note that in the above command (cmd 4) the source files are
encrypted with 7z utility (or compressed with password, as many people say).
The whole intention of doing all of this is just to avoid any possible
PASSWORD security breach.
I hope I was able to give you a clearer picture of the requirement.
I am even open for any new design approach, if you experts can suggest.
Please let me know in case of any queries.
-regards,
Abhisht Sharma
On Tue, 8 Jun 2021 at 20:10, Robert J. Hansen wrote:
> Please do not send HTML to this mailing list. Many of our members
> refuse to open HTML emails from unknown parties, so when you send HTML
> email to this list you're limiting the number of people who can see your
> question -- and maybe be able to help you!
>
> > Step 2. Instead, I have thought of storing the passphrase in a file
> > (passphrase.dat.pgp), encrypted that file without password and passing
> > the password to do the work using below command.
>
> How exactly do you "encrypt that file without password"?
>
> At any rate, this is probably a bad idea. Often the best way to proceed
> for scripting GnuPG tasks is to remove the passphrase from the certificate.
>
> > Step 3. To my wonder, when I execute Step 1 first and then Step 2
> > (within a short span), it works, but if I directly run Step 2 ( which
> > actually will be happening as a part of solution), then it doesn't and
> > fails for "No secret key" error.
>
> This tells me that GnuPG is caching your passphrase with gpg-agent.
> When you run it the second time GnuPG sees the passphrase is in the
> cache and uses that, without ever needing to ask you for the passphrase.
>
--
With Regards,
Abhisht Sharma
+353 899875624
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
