Crash due to a NULL pointer dereference.
Not a Windows specific bug.
Fixed in svn 4935.

Fixed in svn

Right, it was fixed in 1.4.8. The regression is due to the update to a newer
gettext version which still suffers from the same problem David worked around in
1.4.8. I don't have a simple workaround unless you can use the autotools to
create a new configure script.

I think the easiest fix is to use /bin/pwd at both places.

Not a bug - sorry. bash returns a different value for pwd on my system than
does sh/ksh. This is because I have a symlink in my path.

It requires a POSIX shell and as far as I can see there is no dependency on a
non-standard feature. In particualr the check:

Yeah, I should rework this. What I am using for years is a simple:

D78: 205_gpg-agent-info-doc.patch

To further explain the problem:

1. Note that we need to include all other libs here as well because
2. some compilers don't care about inline functions and insert
3. references to symbols used in unused inline functions.

This has already been fixed on 2009-01-22 in the SVN for keyserver/.

Fixed in SVN revision 4928 in both branches. Thanks.

Confirmed also for current SVN.

Here is an example OpenPGP certificate with only the certify flag set, if you
want to test with it.

::sigh:: OK, this was my software that's wrapping gpg. It was getting several
[GNUPG:] KEYEXPIRED responses and reporting the error before noticing that the
encryption actually succeeded. On other keys this wasn't a problem... but in
this cause the behavior is consistent (--always-trust was in fact on).

It's worth noting that --always-trust enables this to work... however,
--always-trust isn't required on other keys that don't seem to be built like this.

Duh, this is already implemented:

The build is broken. We had a report on the mailing list from SuSE and they
figured that the SuSE Toolchain is broken. Thus you need to update your OS - I
am not sure whether this is available. Please check the gnupg-users or
gnupg-devel mailing lists for further info.

*checks*/encrypt.test.logs, I suppose?

What is the content of tests/encrypt.test.log ?

Support for a couple of strings and their German translation has been added in
svn revision 4919.

gpgsm 2.0.10-0kk1

Thank you for the information, with it I will be able to alter behaviour on the
fly (via system variable) but anyway, it would be really great gpg could pass
an argument -- I think it is a bit more elegant way to control the behaviour.

We can't do that because gpg2 requires gpg-agent (not to a 100% right now but
eventually there will be no way without gpg-agent). Pinentry is a property of
gpg-agent and you can control which pinentry to use by using a symlink or
gpg-agent's option --pinentry-program.

This only occurs in Windows, not in Linux.

I'm sorry, I believe that you wanted me to do this on the other end; when
encrypting. I can sucessfully use -d on the created output file, but it seems
*to me* that the funtionality allowing to paste to a windows command line
program(GnuPG), in the windows command line, especially when I am able to do
the same thing in GnuPG when not using a symmetric cipher, should be expected.

That was all done from the command line in Windows XP, exactly as shown.
Adding the output line defeats the purpose for me, but it still does the same
thing even if I add the output line; no output file is produced and I get the
same message.

I have no problems decrypting this message, thus it must be a c+pproblem on your
site. Use the option
--output FILE
to direct the ciphertext to a file so it does not get in the way while entering
the passphrase.

When using GnuPG 1.4.9 for Windows(official build), I cannot paste an
encrypted message that was created using a symmetric cipher and decrypt. I
receive a bad key messages as shown in the example below which uses the
password "test".

I wonder how you created this problem. BEGIN_SIGNING is emitted after the agent
has been connected. The agent is also automatically started if not running; I
simulated a non-existing agent, using "--agent-program /bin/true":

In principle, this can happen on Un*x systems, too. There is no guarantee about
the filesystem encoding. Glib has special interfaces for filename conversion
(G_FILENAME_ENCODING) to deal with this.

Closing this report, as nothing happened in half a year with regards to the
finnish translation.

Can't be done for 2.0.10. Will be considered later.

This has been discussed in the past but I might reconsider. Won't happen for
2.0.10, though.

Can't replicate that anymore with the current version.

Done in 4888. For scdaemon this is a half second and for gpg-agent every third
second.

No, that is not correct. --batch just means that the program is not run
interactivly. Whether stdin is connected to a tty or a pipe does not matter.
All proper Unix tools behave this way. If you call a program which takes input
from stdin, it is always a very good idea to connect stdin to /dev/null.

See the previous comments. This is not a bug.

Applied. svn rev 4887.