The fix is in 1.4.8.

You have a trailing space in the file, i.e.

Looks like gpgkeys_curl.exe is being run instead of gpgkeys_hkp.exe. I'm pretty
sure this fixed it:

There won't be a 64 bit version in the foreseeable future.

Sorry, I fail to understand what your problem is. It seems to be a TB/Enigmail
problem. Please ask at their users list.

Within draw-eat can only the user data change.
The program does not have an access.
Is there the possibility the paths to change?

To delete and provide I can.
GnuPG does not have however like it seems rights.
The error message remains even if I pubring.bak provides by hand.

That is very likely a matter on how the passphrase has been created. It is
known that WinPT at some point changed how it encoded passphrases.

Duplicate of T704

It seems to be a charset problem. I installed WinPT 1.0.0-pre0 and modified the
passphrase replacing international characters with correspondig characters of
the 7 bit character codes: e.g. replacing ä by a. Using these characters only
decryption works with the very same keyrings.
Hence I'd suggest to
a) display the default characterset along with --version option
b) provide an option to display the charcter set being used
c) clarify the scope of the character set (reading stdin, file, passphrase, etc...)

Using Virtual PC I installed a fresh Windows XP Professional version including
SP2 and gpg4win 1.0.6. I can only confirm the behaviour mentioned before:

• Encryption of clipboard (WinPT) works fine
• Decryption of clipboard (WinPT) fails
• Decryption with gpg (1.4.5 gpg4win package) command line (cmd.exe) fails
• Decryption with gpg (1.4.5 gpg4win package) command line (cmd.exe) with

--passphrase-fd 0 (don't know how to get it working: neither pipe nor typing in
works)

• Decryption with gpg (1.4.5 gpg4win package) command line (CygWin) fails
• Decryption with gpg (1.4.5 gpg4win package) command line (CygWin) with

--passphrase-fd 0 option succeeds.

It seems as if I hit the same problem (see T704).
The only way I get decryption working is to run gpg in CygWin environment and
piped the passphrase to gpg.
Example:
PW='secret passphrase'
echo $PW | gpg --passphrase-fd 0 -d <encrypted file> or
cat - | gpg --passphrase-fd 0 -d <encrypted file>

We need more info. In particular how did you set the passphrase in the first
place (Using WinPT or the command line).

Need to check what's going on.

There is now an index page at http://ftp.gpg4win.org/ you may use to get any
older version.

I tried to descrypt with different versions of gpg. But all failed. The only one
working is 1.4.2.1 from the cygwin package. Then I reinstalled version 1.4.5
from gpg4win 1.0.6 package. Typing in the passphrase constantly fails, but when
the passphrase is stored in an environment variable and piped into gpg (called
with --passphrase-fd 0) then decryption works fine. My passphrase contains some
special characters of the iso88591 characterset for security reasons. But this
should not make any difference. But I suspect it's a matter of charactersets
when reading the passphrase. I suppose it's not being read from stdin (fd 0)...

I had no other idea how to narrow down the problem. Decryption used to work with
WinPT. Because it no longer worked as of version 1.0 I tried to decrypt directly
calling gpg that came along with gpg4win (which didn't work either). So I tried
to use an older version of gpg in order to proof if the keyrings are ok and working.
I had no copy of gpg version 1.4.4. As far as I remember it worked up to and
including gpg 1.4.4. Cygwin's gpg proved that the keyring's and the passphrase
are working.
Hence I concluded that it must be a problem of gpg 1.4.5

No problem. The BTS shall also be a resource for other users. Thus, reporting
problems we can't solve is a Good Thing.