Could be the installation to H. In the last 2.5 years we fixed many bugs that
could have caused this. We should test this with current versions and close if
not reproducible.

The first version of dirmngr that worked on any Windows reasonably well is
1.0.2. Versions before that had a multitude of issues, so I am closing this
report. If there are particular problems with current dirmngrs on 64 bit Vista,
please report them with the appropriate level of details.

Meanwhile we have greatly improved gnupg on w32. See www.gpg4win.org. Thus it
makes no sense to care about this old bug anymore. If the problem still
persists with Gpg4win 1.9.9, please re-open this bug.

We did quite some work on the Widnows stuff and the forthcoming 2.0.10 should
fix a couple of problems. There is a weel known problem with card chnage
detection on all platforms. We are still working on that one. As that is also
tracked by other reports (probably several), I close this one.

We are anyway going for GnuPG-2 on Windows. With the gpg-agent framework, there
is no more need for application specific passphrase entries. Thus I close this
bug and wait until it gets a new life in Pinentry ;-).

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.