This is a long standing problem. Usually GPG is used by other utilities and
they exepct utf-8. Thus we would habe to detect the plain use of the console
and then dosomething about it.

No response to my last message. It seems to be an IPC bug and not related to
GPG given that other GUIs don't have these problems.

Fixed in dirmngr and also in GnuPG trunk. Patch for gpg4win created.

ping, it's important for gpg4win.

No info received - assuming everything is fine now.

I have not tried with differnt volumes, but the current gpg4win release works
fine with regards to admin and normal user. Harry, can you please test if this
is still an issue, or if you have moved on from Windows 2000, I will just close
the report.

No time to look into this. Hints on how to fix this are of course welcomes

And why you won't fix it?

[In may previous message I meant "gpg does not _wait_ for the end ..."]

I noticed that the status of this issue was changed to resolved and was
wondering if that meant that it will work in a future version of gnupg or if
it means that nothing will/can be done for the Windows version, i.e. a disk
write will be required each time, and the issue is just closed?

According to the manual and also by a quick look at the code of
g_file_get_contents(), which is called before g_utf8_validate, it should never
return TRUE and store NULL at content. Thus I can't figure the real reason for
this by only looking at the code. Needs more debugging.

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.