No more complaints ;-)

We will stick to Caudium, so there is no way to fix it.

Fixed in SVN.

Actually this is not urgent, but a feature request.

Fixed for trustlist_next as well.

Daiki Ueno confirms this fix but asks whether this is also needed for
trustlist_next.

Well, the release is 0.9.91. It is inlcuded in gpg4win 1.0.7.

Fixed in SVN (-r4281 for 1.4). Also applied fix to libgcrypt.
It should now be possible to pass the cache variable on the command line.

Thinking again about it I figured that most options are already available. The
--enable-agent-only is just a shortcut for --disable-gpg --disable-gpgsm
--disable-scdaemon. I have added new options --disable-tools and --disable-doc
to make them also configurable.

Fixed in SVN

I can still reproduce the bug with 1.4.2.2 and SVN of today. After 1013 files,
I get file open errors.

This is by design. In general a standard location is the best
solution. However for testing etc a way to override it is usefule.
Thus we still support gpgProgram to locate the gpg binary.

Not a bug and no reason to change it.

There are several reasons for such an error. Please take
this problem to a mailing list, either gnupg-users@gnupg.org
or gpg4win-devel@wald.intevation.de.

spam

This is on purpose. It is easy to add faulty signatures,
displaying them would lead to a bunch of messages without
any meaning. GnupG does not use bad signatures. See also
the new clean options

From: Klaus Ethgen <Klaus@Ethgen.de>
To: bug-any@bugs.gnupg.org
Cc: gnupg-hackers@gnupg.org, gnats-admin@trithemius.gnupg.org, wk@gnupg.org
Subject: Re: gnupg/527
Date: Mon, 12 Sep 2005 14:10:59 +0200

Patch sent to Debian BTS.

No bug, not explanation.

sha1sum is part of the GNU coreutils and I am pretty sure
that it is available on *BSD too. Maybe not by default.
sha1sum is similar to md5sum but uses the SHA-1 hash
algorithm. MD5 is to be considered broken for many purposes
and thus we don't use it anymore. BTW:
ftp://ftp.gnupg.org/gcrypt/binary/sha1sum.c is a simple buf
sufficient implementation.

We did quite some changes in this area since 1.4.0. I a
ssume the problem is solved. Please feel free to re-open
this bug if it persists with 1.4.2rc2. Thanks.

has been fixed in 1.4.2rc1. Note, that a similar problem
will happen when using gpg-agent and scdaemon from CVS. I
will fix that for 1.9.17.

Several people confirmed that this fixed the problem.

Requested information not received - closing.

Finally found that bit.

From: Neil W Rickert <rickert@cs.niu.edu>
To: bug-any@bugs.gnupg.org
Cc: gnupg-hackers@gnupg.org, gnats-admin@trithemius.gnupg.org
Subject: Re: gnupg/392
Date: Wed, 04 May 2005 06:56:10 -0500

Is this still a problem for you with 1.4.1?

Fixed

taken

That is correct. The orginal implementation in gnupg 1.9
used a daemon so there was no need for caching the PIN - be
a card does it itself. gnupg 1.4.1 had had no code to cache
a PIN; i.e. it didn't provide a cache ID.

Ping

No feedback received. If this problem still persists with
1.4.1, please open a new bug.

From: Will Partain <will.partain@verilab.com>
To: gnupg-hackers@gnupg.org, gnats-admin@trithemius.gnupg.org, wk@gnupg.org
Cc:
Subject: Re: gnupg/394
Date: Wed, 09 Mar 2005 10:31:34 +0000

Sorry, I have no idea what you are talking about. Please
give URLs, versions numbers and releated info so that we may
replicate the problem.

Dany, can you confim that it has been fixed in 1.4.1rc2?

No feedback, still. We are going to close this one in a few
weeks as the 1.2. series is not continued.

What is the CPU-Vendor-OS string (e.g. sparc-sun-SunOS)?
The configure output tells you what symlinks have been created - how have they been set?

Please send us more information, we can't do
nything about it without your support. Thanks.

1.4.1rc2 fixes this

Fixed in 1.4.1rc2 and earlier

no more feedback. Closed.

David, may we close this bug?