Because we decided that 5 minutes are reasonable value timeout value for an
intermittently slow CRL server. I can't see the actually problem with it: The
proxy should not delay or buffer the request at all. CRLs are picked up
automagically an you don't have control over what CRL server is used - if there
is a slow one and the timeout is too short you will never ever be able to use a
certificate bound to that CRL server. Better to wait than to be sorry - these
are the usual tradeoffs you have to make while defining a timeout. Note
thatthere are a couple of other timeouts in a TCP network, which you can't
control either.

What is the reason that the "last resort timeout" cannot be configured
to be faster? (Meaning below 5 minutes?)

Well you can configure it: That last resort timeout is 5 minutes plus the
configured timeout.

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.

The current svn trunk features a user provided trust anchors. Thus if a CRL
could not be validated just because the trust anchor is not available in
trusted-certs/, dirmnngr will casche the CRL anyway and ask back whether the
user trusts the trust anchor. The latest GnuPG implements the counterparts
which uses the /.gnupg/trustlist.txt to answer this.

I can't see a bug here. By design CRLs are only loaded once in a while and
valid as long as specified in the CRL. There is no need to re-check the CRL.
If you do not want such a behaviour you need to use OCSP and not CRLs. In fact
that is one of the reasons why the German Qualified Signatures require the use
of OCSP.

Hi Werner,

Fixed in dirmngr svn revision 300.

Thanks!

Thanks. I see what I can do to get de-armoring implemented in dirmngr. Should
definitely go into Debian's Lenny.

Hi Werner,

Libksba does only take binary data; thus it is indeed a dirmngr problem.

Sorry, this patch is wrong. yat2m needs to be build for the build platform and
thus you can't use CFLAGS because that macro is for the target platform.
Frankly, I don't see a need to add any flags for an yat2m build, because this is
a one off program only required to convert texinfo to man format during dirmngr
build.

Fixed in SVN. I can't see a regression here, through.
Here is the short fix:

It used to work in earlier versions and this issue
now block rollout to production customers, thus a warrenty kks
and "urgent" because of the blocking effect.

There won't be a 64 bit version in the foreseeable future.

No more complaints ;-)

Fixed in SVN

Marcus, this is about the missing HTTP redirection feature we recently talked about.

I encountered this too and actually started to fix it. However
some more important work delayed it. I hope that I get to it again
next week.