[Gpg4win-devel] Roadblocks for Gpg4win 2.1beta1

Werner Koch wk at gnupg.org
Fri Jul 23 08:12:41 CEST 2010


On Thu, 22 Jul 2010 09:28, bernhard at intevation.de said:

> Most painful right now:
> gpg4win-2.1.0-svn1484 + kleo 2.1.0-svn1142590 cannot import S/MIME 
> certificates for this reason. Werner aims to look at this within the next 
> weeks so we can say about how much effort it will be to fix this problem.

Well, I did this yesterday and fortunately found the problem.  It has
been fixed and thus we should not do worse than 2.0.3.

> standing defect with file handles on windows. It took us a while to get to 
> this point and we need to resolve this before we really can make progress
> with the development again.

This bug still persists but we have it under control at most places.  It
is basically a maintenance nightmare: You never know whether you have a
system handle, a libc file descriptor, a socket or (under CE an RVID).
It is not always possible to deduce the type of handle so we more or
less do an educated guess.  The clean solution is to drop all direct
usage of handles and and replace them by an object we fully control and
carries meta information (like the type of handle).  This is quite some
work and thus for now we may need to resort to our ad-hoc solutions.

Another general problem on Windows is that you may either select to
inherit all handles or none when calling CreateProcess.  This is due to
the missing fork/exec concept which would allow for this.  To avoid this
we need to use a wrapper process; like we already do in gpgme.  AFAICS
this currently affects the gpg-agent/scdaemon communication - a solution
without an annoying wrapper is already in my head and will be
implemented in the next few weeks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gpg4win-devel mailing list