Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Peter Gutmann]

Chris Polley <chris.polley@ieee.org> writes:

>>I don't know how good the generated entropy is. This question goes to=20
>>the cygwin list. How generated? How good?
>
>It uses the MS-supplied CryptGenRandom call to generate the random bytes.

The CAPI generator is, um, of variable quality.  I cover one version in
http://www.cryptoapps.com/~peter/06_random.pdf.  Note that the code appears to
have changed over time, and is now considerably improved (the details will be
in the updated version of the above paper).  I don't know in which versions of
Windows the improved versions appeared, or what the specific improvements over
time may have been.

(Basically, you're relying on the company which brought you ActiveX, Outlook,
 Word macros, IIS, etc etc, to provide secure randomness.  It's sort of odd
 that you don't trust their Posix stuff (which is a matter of taste), but do
 trust their randomness (which is a critical security issue) :-).

Peter.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Lapo Luchini]

>
>
>The CAPI generator is, um, of variable quality.  I cover one version in
>http://www.cryptoapps.com/~peter/06_random.pdf.  Note that the code appears to
>have changed over time, and is now considerably improved (the details will be
>in the updated version of the above paper).  I don't know in which versions of
>Windows the improved versions appeared, or what the specific improvements over
>time may have been.
>
You can of course submit a patch to use our own prng, seeding it also 
with CAPI data, of course ]=)

-- 
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Corinna Vinschen]

On Thu, Jun 06, 2002 at 08:34:30PM +1200, Peter Gutmann wrote:
> Chris Polley <chris.polley@ieee.org> writes:
> 
> >>I don't know how good the generated entropy is. This question goes to=20
> >>the cygwin list. How generated? How good?
> >
> >It uses the MS-supplied CryptGenRandom call to generate the random bytes.
> 
> The CAPI generator is, um, of variable quality.  I cover one version in
> http://www.cryptoapps.com/~peter/06_random.pdf.  Note that the code appears to
> have changed over time, and is now considerably improved (the details will be
> in the updated version of the above paper).  I don't know in which versions of
> Windows the improved versions appeared, or what the specific improvements over
> time may have been.
> 
> (Basically, you're relying on the company which brought you ActiveX, Outlook,
>  Word macros, IIS, etc etc, to provide secure randomness.  It's sort of odd
>  that you don't trust their Posix stuff (which is a matter of taste), but do
>  trust their randomness (which is a critical security issue) :-).

Typically I don't take that "Microsoft is evil" stuff serious but
the above sentence contains an error.  It's not that we don't trust
the Microsoft POSIX stuff but it's not that useable nor complete.

The original reason to create Cygwin was to have a framework in which
gcc and friends will work and which doesn't create licensing trouble
for Cygnus.  Every further improvement and extension to Cygwin is
just driven by the will of volunteers.

When I created the /dev/random and /dev/urandom stuff, I decided that
the /dev/random is best implemented by using the OS capabilities and
I still stand to that decision.  The /dev/urandom is implemented the
same way but allows falling back to a simple pseudo random number
generator which isn't possible for /dev/random.

By and large I don't see any need to change /dev/random just to support
peoples paranoia.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[quetschke]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Hi!

> > I am not into personal attacks, please view this as constructive critism,
> > but I find your line of reasoning to be highly fallacious.  The whole
> > point of the cygwin project is to "free" Windows users from the
> > restrictions and non-posix compliance of their OS.  It allows them to have
> > a choice in how they run their software and how it behaves.  We aren't
> 
> I see your point and will step back. 
Thank you very much, it's no fun maintaining a fork.
> 
> What we should do then is to change the half-existing Cygwin support
> to support Cygwin really in a Unix way and not a mixed
> w32/cygwin support.  The goal is to let it work in the best way
> with mutt ans similar programs. 
Hmm, most of the work was removing the "support" for Cygwin, because
it is more POSIX/UNIX like than most people think.

> We can't do this for 1.2.0 but it should be a goal for 1.2.1.
I will post details/patches in a follow-up to the gnupg-dev mailing list,
here on the cygwin mailing list is already to much traffic.
 
> Okay?
Sure!

>   Werner
Bis bald

    Volker

-- 
PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Nicholas Wourms]

--- Werner Koch <wk@gnupg.org> wrote:
> I see your point and will step back. 
> 
> What we should do then is to change the half-existing Cygwin
> support
> to support Cygwin really in a Unix way and not a mixed
> w32/cygwin support.  The goal is to let it work in the best way
> with mutt ans similar programs. 
> 
> We can't do this for 1.2.0 but it should be a goal for 1.2.1.
> 
> Okay?

Sounds quite reasonable to me :).  Thank you!

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Werner Koch]

On Wed, 5 Jun 2002 07:06:41 -0700 (PDT), Nicholas Wourms said:

> I am not into personal attacks, please view this as constructive critism,
> but I find your line of reasoning to be highly fallacious.  The whole
> point of the cygwin project is to "free" Windows users from the
> restrictions and non-posix compliance of their OS.  It allows them to have
> a choice in how they run their software and how it behaves.  We aren't

I see your point and will step back. 

What we should do then is to change the half-existing Cygwin support
to support Cygwin really in a Unix way and not a mixed
w32/cygwin support.  The goal is to let it work in the best way
with mutt ans similar programs. 

We can't do this for 1.2.0 but it should be a goal for 1.2.1.

Okay?

  Werner


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Chris Polley]

Hi, Volker:

On Wed, 05 Jun 2002 15:26:37 +0200, you wrote:

>I don't know how good the generated entropy is. This question goes to 
>the cygwin list. How generated? How good?

/dev/random (and /dev/urandom) is implemented in
/winsup/cygwin/fhandler_random.cc in the source code for the cygwin1
dll. (CVS version 1.18 is the current release, available at
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_random.cc?cvsroot=src
[for the gnupg-devel readers wishing to review the code]

It uses the MS-supplied CryptGenRandom call to generate the random
bytes.  According to MSDN
(http://msdn.microsoft.com/library/en-us/security/security/cryptgenrandom.asp),
this function takes a seed value supplied by the program (cygwin1.dll
passes on the contents of the read buffer) and adds it to "both the
stored seed and various system data and user data such as the process
ID and thread ID, the system clock, the system time, the system
counter, memory status, free disk clusters, the hashed user
environment block. This result is SHA-1 hashed, and the output is used
to seed an RC4 stream, which is then used as the random stream and
used to update the stored seed."

CryptGenRandom is available in NT/2k/XP/95(OSR2)/98/ME (in 95,
requires IE 3.02)

If the function isn't available for some reason, reads from
/dev/random fail (although reads from /dev/urandom will fall back to a
prng)

It seems that the windows dll attempts to check its signature before
allowing use, although I didn't see any details of that feature (other
than the error codes for bad sig, unable to verify sig, etc.)

I guess the advantage of rndw32 is that it is completely open source
(I'm assuming that the source to the winseed DLL is available... BTW,
why is the winseed DLL not dist in the gpg tarball?)

Warm Regards,
Chris

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Christopher Faylor]

On Wed, Jun 05, 2002 at 03:26:37PM +0200, Volker Quetschke wrote:
>>>cases with __CYGWIN__ for the file handling to use its own (standard
>>>posix) file handling.  Cygwin does have a /dev/random, therefore I
>>>changed from rndw32 to rndlinux.
>>
>>This seems to be a new feature - did you review the architecture of
>>this device?
>
>I got the hint from the cygwin list and I tried to use it with the
>build of gnupg.  There were two include files missing for rndunix but
>it compiled with rndlinux.  And a cygwin build gpg works with rndlinux.

/dev/random isn't a new feature.  It was introduced more than two years ago.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Nicholas Wourms]

>  > There are two main reason why Cygwin is not supported and why the
>  > existing support may be dropped in the future:
>  >
>  > 1. There are conflicts between passed file descriptors.  Cygwin and
>  >    Windows use different semantics for that and GnuPG has already a
>  >    mapping between the external file descriptors and those used with
>  >    the CRT.  Now knowing what version of GnuPG is running on a
Windows
>  >    box is a bad thing for other applications.  Adding extra code to
>  >    check for this is too complicated and thus error prone.
>  >
>  > 2. Having a native Windows binary is a clear advantage for
maintenance
>  >    and support.
>  >
>  > What we will support is cross compiling using a gcc running under
>  > Cygwin to a native windows application.

Werner,

I am not into personal attacks, please view this as constructive critism,
but I find your line of reasoning to be highly fallacious.  The whole
point of the cygwin project is to "free" Windows users from the
restrictions and non-posix compliance of their OS.  It allows them to have
a choice in how they run their software and how it behaves.  We aren't
just a few people using cygwin on the side, rather, we are a force to be
reckoned with.  You can't just ignore us and say "There's a native windows
binary, that'll have to do".  It can be extremely complicated for cygwin
apps to interact with Windows natives, due to path conversion issues
amongst other things, and in most cases makes it impossible to do.  We
have found this to nearly be the case with GnuPGP, as there was much
difficulty getting the windows native to work with the cygwin mutt, IIRC
it still wouldn't work properly half the time.  I know it may complicate
the code somewhat, but the whole idea of PGP is to bring PKI to the
masses, regardless of platform.  With the demise of NAI's PGP Line, GnuPGP
is staged to become the future of PKI.  Furthermore, we have an individual
who has stepped forward to assist in maintaining the cygwin version and
working in cooperation with you to make sure necessary fixes get added to
the codebase.  I've seen much more complex projects, with existing windows
natives, step forward and provide cygwin native support.  I beg you to
reconsidier your rationale and think of the many cygwin users who might
want/need this functionality under Cygwin.  It's not that I don't find
your reasoning compelling, it's just that it sounds like the reasoning of
a commercial entity, such as NAI, supporting only the platforms which are
easiest to maintain and most widely used.  Thank you for you hard work in
providing such an excellent package, and it is my hope that you will
continue long into the future, regardless of your decision :).  Thanks for
your time and consideration on this matter.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Volker Quetschke]

Hi, I forgot two things:

> Ok, but first things first, at the moment gnupg 1.0.7 / current cvs 
> version don't build OOB.

I mean both, the release gnupg 1.0.7 and the new version from cvs don't 
build.

> You can use the following build instructions to build gpg as a native 
> windows application. (without cygwin1.dll)
> 
> export CC="gcc -mno-cygwin"
> export RANLIB="ranlib"
> 
> ./scripts/autogen.sh
> ./configure --host=i686-pc-mingw32 --target=i686-pc-mingw32
> echo "all:" > po/Makefile
> make
> 
> ( The po/Makefile is not generated without AM_GNU_GETTEXT set, therefor 
> you have to generate your own.
> And you need to change the
> #ifdef __CYGWIN32__
> # include <winioctl.h>
> #endif
> 
> to just
> 
> #include <winioctl.h>
> (I don't now if you need winioctl.h for a pure mingwin build)

You also need AC_CHECK_FUNC( strcasecmp ... ) in Configure.ac, this is 
possibly already corrected in cvs.

Bye

     Volker


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Patches for gnupg 1.0.7 / cygwin 1.3.10

[Volker Quetschke]

Hi Werner,

 > > cases with __CYGWIN__ for the file handling to use its own (standard
 > > posix) file handling. Cygwin does have a /dev/random, therefore I
 > > changed from rndw32 to rndlinux.
 >
 > This seems to be a new feature - did you review the architecture of
 > this device?
I got the hint from the cygwin list and I tried to use it with the build 
of gnupg. There were two include files missing for rndunix but it 
compiled with rndlinux. And a cygwin build gpg works with rndlinux.

I don't know how good the generated entropy is. This question goes to 
the cygwin list. How generated? How good?

 > > Please review the patch and implement if possible. It mainly removes
 > > special cases for cygwin.
 >
 > There are two main reason why Cygwin is not supported and why the
 > existing support may be dropped in the future:
 >
 > 1. There are conflicts between passed file descriptors.  Cygwin and
 >    Windows use different semantics for that and GnuPG has already a
 >    mapping between the external file descriptors and those used with
 >    the CRT.  Now knowing what version of GnuPG is running on a Windows
 >    box is a bad thing for other applications.  Adding extra code to
 >    check for this is too complicated and thus error prone.
 >
 > 2. Having a native Windows binary is a clear advantage for maintenance
 >    and support.
 >
 > What we will support is cross compiling using a gcc running under
 > Cygwin to a native windows application.

Ok, but first things first, at the moment gnupg 1.0.7 / current cvs 
version don't build OOB. Ok, if you start the make several times it 
finishes after all. This was due to the fact that the Configure.ac in:
---
try_gettext=yes
case "${target}" in
     *-*-mingw32*|*-*-cygwin*)
         # special stuff for Windoze NT
         ac_cv_have_dev_random=no
[few lines deleted]
         AC_DEFINE(USE_SIMPLE_GETTEXT,1,
                   [because the Unix gettext has too much overhead on
                    MingW32 systems and these systems lack Posix functions,
                    we use a simplified version of gettext])
         try_gettext="no"
         ;;
---
set try_gettext="no". Therefore AM_GNU_GETTEXT doesn't get called, and 
so $(RANLIB) isn't set. Solution: Cygwin can use the full gettext, so 
remove the *-*-cygwin* from this case and create the same case for 
*-*-cygwin* without AC_DEFINE(USE_SIMPLE_GETTEXT,1 and try_gettext="no".

That is all to make the cygwin target compile OOB without changing 
anything to the gpg file handling. Full windows path compatible, as you 
said:
 > What we will support is cross compiling using a gcc running under
 > Cygwin to a native windows application.

It would also be nice if you incorporate the fix for the dynamic module 
handling, it is a known feature that automake can't always guess right 
if there is a .exe missing:
 > -         DYNAMIC_CIPHER_MODS="$DYNAMIC_CIPHER_MODS $name"
 > +         DYNAMIC_CIPHER_MODS="$DYNAMIC_CIPHER_MODS $name\$(EXEEXT)"
 > +			# The $(EXEEXT) is needed to help automake

I can send you a patch for this if you don't like the rest.

Now I would like to come back to your second point.
 > 2. Having a native Windows binary is a clear advantage for maintenance
 >    and support.

Yes, but you don't build native windows binaries just with the cygwin 
build. If you build something under cygwin this uses the cygwin1.dll, 
this is not a good solution for native windows tools.

You can use the following build instructions to build gpg as a native 
windows application. (without cygwin1.dll)

export CC="gcc -mno-cygwin"
export RANLIB="ranlib"

./scripts/autogen.sh
./configure --host=i686-pc-mingw32 --target=i686-pc-mingw32
echo "all:" > po/Makefile
make

( The po/Makefile is not generated without AM_GNU_GETTEXT set, therefor 
you have to generate your own.
And you need to change the
#ifdef __CYGWIN32__
# include <winioctl.h>
#endif

to just

#include <winioctl.h>
(I don't now if you need winioctl.h for a pure mingwin build)

because this is needed. This leads me to the main point: __CYGWIN__ is 
not defined at the moment, we are: __MINGW32__.
Even using a cygwin environement to create a native windows executable 
doesn't need any __CYGWIN__ preprocessor directives.

If you use just cygwin, then you want to have a POSIX environement, like 
my mutt, or Xfree86, or even KDE 2.2.2 .
All these programs don't like windows pathes.

If you do not want to support cygwin you can start to remove every 
__CYGWIN__.

Why not start with my previously posted patch? ;-) OK, maybe I should 
have a look at the rndlinux code, but it works at least.

I think it is very convenient to have a native cygwin gpg and it doesn't 
  interfere with a native windows build.

Bis bald

      Volker


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/