Search This Blog

Tuesday 30 April 2019

Scripted GPG on a Windows Server

I recently rebuild an old scheduling server that was running some GPG decryption processes via Powershell.  These processes required the private key passphrase to be passed to the gpg decrypt process - I know this isn't a good idea, this post just explains how I did it if you want to go down the same crazy route I was forced to.

On the old server, we were using GPG 1.something.  When I setup the new servers, I installed GPG4WIN, which installed GnuPG for me.  I hadn't realised, but the GPG version it had installed was GPG2.something.

My powershell was doing this:

 $startProcParams = @{   
      'FilePath' = $gpgexe   
      'ArgumentList' = "-v --batch --yes --passphrase $gpgpassword -o $outfile -d $($gpgfile.FullName)"  
      'RedirectStandardError' = "$logfile-err"  
      'RedirectStandardOutput'= "$logfile-out"  
      'Wait' = $true  
      'NoNewWindow' = $true  
      'UseNewEnvironment' = $false  
 }  
 $proc = Start-Process @startProcParams  

On the surface things looked ok but when the script ran, GPG popped up a UI dialog requesting the passphrase (pinentry.exe as it turned out).  Apparently, GPG v2.something no longer accepts the --passphrase parameter.

The solution I eventually found was to pipe the passphrase into gpg.exe

 echo mYpAsSpHrAsE| & 'C:\Program Files (x86)\GnuPG\bin\gpg.exe' --passphrase-fd 0 --pinentry-mode=loopback --batch --yes -d "$($gpgfile.FullName)" > $decryptedOutFile  
note the space after "echo", but NOT before the pipe.

I don't really understand why yet, but this causes an error when you try on use the -o flag.  Removing this caused GPG to send the plaintext content to stdout however, so I simply used a pipe on the end to send it to a file.

Other downsides are that I can no longer capture the stdout and stderr neatly into the same log file as the rest of the process.

No comments:

Post a Comment