Sorry, I fail to understand what your problem is. It seems to be a TB/Enigmail
problem. Please ask at their users list.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 7 2007
Apr 16 2007
Apr 5 2007
Mar 10 2007
Within draw-eat can only the user data change.
The program does not have an access.
Is there the possibility the paths to change?
Mar 8 2007
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.
Feb 26 2007
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.
Feb 7 2007
Jan 3 2007
Duplicate of T704
Oct 24 2006
Oct 19 2006
Oct 16 2006
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...)
Oct 11 2006
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.
Oct 4 2006
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>
Oct 2 2006
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.
Oct 1 2006
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)...
Sep 25 2006
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
Aug 14 2006
No problem. The BTS shall also be a resource for other users. Thus, reporting
problems we can't solve is a Good Thing.