Help with the --batch option...
DKaraluz at TC3HEALTH.com
Tue Nov 23 16:06:11 CET 2010
Sorry to bother you with this but we upgraded to 1.4.11 and now have a
Let me give you some background information... we have three scripts
that run during the day:
1 - Scripts to decrypt files...
2 - Script to encrypt archive files with our key (American rules about
personal information in claims)
3 - Script to encrypt and FTP outbound client files.
These scripts are started by events and with 1.2 we never saw any
problems (other than that one file that would not decrypt and made us
Since the upgrade we get a few failures a day where the encryption
process produces a zero byte output file. When I look at my logs I see:
gpg: fatal: can't read `C:/GnuPG\random_seed': No such file or directory
secmem usage: 1696/1696 bytes in 5/5 blocks of pool 1696/32768
We then try the encryption script again and it runs fine.
Now, we have tight deadlines and the manual process of rerunning files
can potentially cause us to incur in financial penalties. So, before we
roll back to 1.2 I was hoping you could shed some light into this
First of all, is the encryption process multithread able? All three
scripts could potentially be started at the same time, and I could have
two scripts encrypting different files at the same time.
Any other thoughts?
Here is the command line I executed:
c:\gnupg\gpg -r ehs --batch --yes --output
Any option I could use that would prevent this failure?
From: Werner Koch [mailto:wk at gnupg.org]
Sent: Wednesday, October 27, 2010 4:26 AM
To: Dieter Karaluz
Cc: gnupg-users at gnupg.org
Subject: Re: Help with the --batch option...
On Tue, 26 Oct 2010 22:30, DKaraluz at TC3HEALTH.com said:
> We are running GPG 1.2.0 in production. We use it to decrypt all the
That one is an 8 years old version and this 1.2 series entered end of
life status 5 years ago.
> 1 - What do I need to do with gpg 1.4.11 so that it will decrypt pgp
> files in batch mode. With hundreds of files coming in daily it is just
>From the command lines you posted 1.2. was not able to do this either.
It might be that we chnaged something related to batch processing but
that was a bug fix then.
> so I don't know what was done with 1.2.0 to make it work fine with the
> --batch option.
Either no passpharse was set for the key or the option --passphrase-fd
was used. What you can do is to remove the passphrase from the key or
use one of the options: --passphrase-fd, --passphrase-file or
> 2 - What fix was applied to 1.4.11 that solved the issue I am having
> in 1.2.0, and is there an option I could pass to GNUPG 1.2.0 that
> would correct or work around the issue?
Too many changes over the years too quickly answer this. Likey
* parse-packet.c (skip_packet, parse_gpg_control): Take care of
premature EOFs. Backport from trunk.
* parse-packet.c (parse): Remove special treatment for
new style packets. Fixes bug#931.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-users