From mario.lists at gmail.com Fri Sep 2 18:36:17 2005 From: mario.lists at gmail.com (Mario Fuentes) Date: Fri, 2 Sep 2005 12:36:17 -0400 Subject: [Help-gnutls] Confused Message-ID: Hi, I'm very confused :( . I set the decoding callback with gnutls_transport_set_pull () but in occasions gnutls_record_recv returns a negative value, What should I do when I receive an error?, I should receive again? Pease, help! Thanks, Mario From jas at extundo.com Sat Sep 3 10:43:02 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 03 Sep 2005 10:43:02 +0200 Subject: [Help-gnutls] Re: Confused In-Reply-To: (Mario Fuentes's message of "Fri, 2 Sep 2005 12:36:17 -0400") References: Message-ID: Mario Fuentes writes: > Hi, > > I'm very confused :( . I set the decoding callback with > gnutls_transport_set_pull () but in occasions gnutls_record_recv > returns a negative value, What should I do when I receive an error?, I > should receive again? Probably, but it depends on the error returned. You can use gnutls_error_is_fatal() to tell whether the error condition is fatal. If g_e_i_f return false, you should call g_r_r again. See the complete g_r_r function documentation below. Regards, Simon -- Function: ssize_t gnutls_record_recv (gnutls_session_t SESSION, void * DATA, size_t SIZEOFDATA) SESSION: is a `gnutls_session_t' structure. DATA: the buffer that the data will be read into SIZEOFDATA: the number of requested bytes This function has the similar semantics with `recv()'. The only difference is that is accepts a GNUTLS session, and uses different error codes. In the special case that a server requests a renegotiation, the client may receive an error code of GNUTLS_E_REHANDSHAKE. This message may be simply ignored, replied with an alert containing NO_RENEGOTIATION, or replied with a new handshake, depending on the client's will. If EINTR is returned by the internal push function (the default is `code'{`recv()'}) then GNUTLS_E_INTERRUPTED will be returned. If GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN is returned, you must call this function again, with the same parameters; alternatively you could provide a NULL pointer for data, and 0 for size. cf. `code'{`gnutls_record_get_direction()'}. A server may also receive GNUTLS_E_REHANDSHAKE when a client has initiated a handshake. In that case the server can only initiate a handshake or terminate the connection. Returns the number of bytes received and zero on EOF. A negative error code is returned in case of an error. The number of bytes received might be less than `code'{count}. From jas at extundo.com Fri Sep 9 12:34:51 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 09 Sep 2005 12:34:51 +0200 Subject: [Help-gnutls] GnuTLS 1.2.7 Message-ID: We are pleased to announce the availability of GnuTLS version 1.2.7, OpenCDK version 0.5.8 and Libtasn1 0.2.17! GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. OpenCDK and Libtasn1 are libraries used by GnuTLS for OpenPGP packet parsing and ASN.1 handling. The OpenCDK and Libtasn1 libraries are included in GnuTLS, so you do not need to install them separately. Noteworthy changes since version 1.2.6: - The GNUTLS and GNUTLS-EXTRA libraries are now built with versioned symbols. - Certtool now complains when reading out-of-range X.509 serial numbers, suggested by Fran . - Certtool now uses the readline library (when available) when reading X.509 serial numbers. - Fixed build problems in getpass on uClibc and Mingw32 platforms. - Fixed compile warning regarding socklen_t on Mingw32, reported by Martin Lambers . - Fixed examples in doc/examples/, suggested by Fran . - Gnulib is now used for the core library, enabling future code cleanups. - The gnutls-cli tool now use gnutls_certificate_verify_peers2, suggested by Daniel Stenberg . - Doc fixes for gnutls_transport_set_push and gnutls_transport_set_pull. - Minilibtasn1 is now 0.2.17 (removed optional use of C99 macros). - Disable zlib support if zlib.h is not present. - A number of internal cleanups. Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: http://josefsson.org/gnutls/releases/gnutls-1.2.7.tar.bz2 (2.5MB) ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.2.7.tar.bz2 (2.5MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.2.7.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.2.7.tar.bz2.sig Here are the OpenCDK library sources and digital signature: http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.8.tar.gz (492K) http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.8.tar.gz.sig ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.8.tar.gz ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.8.tar.gz.sig Here are the Libtasn1 library sources and digital signature: http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.2.17.tar.gz (868K) http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.2.17.tar.gz.sig ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.2.17.tar.gz ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.2.17.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: 1280R/B565716F 2002-05-05 [expires: 2006-02-28] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the SHA-1 checksums: c1a583052a16521363d0dab5615bfc547f291fca gnutls-1.2.7.tar.bz2 81cd5328df91f197b7ae540912705758f79f9e81 gnutls-1.2.7.tar.bz2.sig a8a5d9d2a27acccdd8cf92d385c637f78ff0f55f opencdk-0.5.8.tar.gz ee0883ca57f06987e7481d83ea111913d282df8f opencdk-0.5.8.tar.gz.sig 29b3ad1c5db4d1d43ee32da0cdaebfe05356ea48 libtasn1-0.2.17.tar.gz 7c84c6bd8b08e9f85b02261b120bcddcde81e4b9 libtasn1-0.2.17.tar.gz.sig Enjoy, Nikos and Simon From nmav at gnutls.org Sat Sep 10 10:34:22 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Sep 2005 10:34:22 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: References: <200509060746.56114.nmav@gnutls.org> Message-ID: <200509101034.23034.nmav@gnutls.org> On Wednesday 07 September 2005 20:18, Andrew M. Bishop wrote: > The packet dumps look the same to me, the main differences are the > timestamps and the random information. Towards the end of the second > handshake the client sends a fatal error instead of a warning if the > server forked. The important (to me) differences are below. > The whole log files are compressed and attached. The problem is that in the 2nd forked session the server tries to resume the previous connection. You can check this by looking the session ID. The one the server selects the second time is the same as the client requested (resume). This is totally strange since there is no communication between the objects (lie in a different process), so the second process shoudn't even know the session ID of the first server process. It seems to work ok if you move the gnutls_session_t session declaration to after the forked process has been created (after if (pid==0)). I'm still looking at it but it really looks odd. -- Nikos Mavrogiannopoulos From nmav at gnutls.org Sat Sep 10 11:12:42 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Sep 2005 11:12:42 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: <200509101034.23034.nmav@gnutls.org> References: <200509101034.23034.nmav@gnutls.org> Message-ID: <200509101112.42825.nmav@gnutls.org> On Saturday 10 September 2005 10:34, Nikos Mavrogiannopoulos wrote: > The problem is that in the 2nd forked session the server tries to resume > the previous connection. You can check this by looking the session ID. The > one the server selects the second time is the same as the client requested > (resume). This is totally strange since there is no communication > between the objects (lie in a different process), so the second process > shoudn't even know the session ID of the first server process. > It seems to work ok if you move the gnutls_session_t session declaration to > after the forked process has been created (after if (pid==0)). I'm still > looking at it but it really looks odd. The problem seems to be libgcrypt's random generator. As far as I understand when you fork() the random generator is on the same state for every children. That's why the server produces the same session ID in the second process. I am not really sure about it, and I don't know how to overcome this, that's why I crosspost to gcrypt-devel as well. -- Nikos Mavrogiannopoulos From jas at extundo.com Sat Sep 10 18:18:24 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 10 Sep 2005 18:18:24 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: <200509101112.42825.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 10 Sep 2005 11:12:42 +0200") References: <200509101034.23034.nmav@gnutls.org> <200509101112.42825.nmav@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On Saturday 10 September 2005 10:34, Nikos Mavrogiannopoulos wrote: > >> The problem is that in the 2nd forked session the server tries to resume >> the previous connection. You can check this by looking the session ID. The >> one the server selects the second time is the same as the client requested >> (resume). This is totally strange since there is no communication >> between the objects (lie in a different process), so the second process >> shoudn't even know the session ID of the first server process. >> It seems to work ok if you move the gnutls_session_t session declaration to >> after the forked process has been created (after if (pid==0)). I'm still >> looking at it but it really looks odd. > > The problem seems to be libgcrypt's random generator. As far as I understand > when you fork() the random generator is on the same state for every children. > That's why the server produces the same session ID in the second process. > > I am not really sure about it, and I don't know how to overcome this, that's > why I crosspost to gcrypt-devel as well. One solution is that we switch to the random number handling that is implemented when --enable-nettle is given to a GnuTLS build. Then GnuTLS will read (on GNU/Linux) from /dev/urandom for pseudo-random data and nonces, and from /dev/random for random data. Alternatively, GnuTLS could use an internal PRNG, and we could add an API to seed it. How do people feel about this? My personal preference is to rely on /dev/*random for randomness. If that isn't sufficient for someone, she can always point GnuTLS to another device (or even file socket) and have full control without bogging down the gnutls library. The libgcrypt way should still be available, for people on weird platforms with an OS that doesn't collect randomness, or for people who prefer the libgcrypt approach for some reason. Thanks, SImon From nmav at gnutls.org Sat Sep 10 18:53:55 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Sep 2005 18:53:55 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: References: <200509101112.42825.nmav@gnutls.org> Message-ID: <200509101853.55987.nmav@gnutls.org> On Saturday 10 September 2005 18:18, Simon Josefsson wrote: > > The problem seems to be libgcrypt's random generator. As far as I > > understand when you fork() the random generator is on the same state for > > every children. That's why the server produces the same session ID in the > > second process. > > I am not really sure about it, and I don't know how to overcome this, > > that's why I crosspost to gcrypt-devel as well. > One solution is that we switch to the random number handling that is > implemented when --enable-nettle is given to a GnuTLS build. Then > GnuTLS will read (on GNU/Linux) from /dev/urandom for pseudo-random > data and nonces, and from /dev/random for random data. The problem with this is that a gnutls server will depleat /dev/random (we need to generate a master secret for each session), thus the server will be most of the time blocked waiting for input for /dev/random. > Alternatively, GnuTLS could use an internal PRNG, and we could add an > API to seed it. The problem with internal PRNGs is that they are not thread safe (see libgcrypt's PRNG). > My personal preference is to rely on /dev/*random for randomness. If > that isn't sufficient for someone, she can always point GnuTLS to > another device (or even file socket) and have full control without > bogging down the gnutls library. The file sockets seem like a good idea. We could still keep the libgcrypt PRNG, but it could run on a separate process (forked at global_init), and the communication would be via local sockets. I don't know how good it sounds... but it looks thread and fork safe. It also sound like a lot of work. -- Nikos Mavrogiannopoulos From nmav at gnutls.org Sat Sep 10 19:03:51 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Sep 2005 19:03:51 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: <200509101853.55987.nmav@gnutls.org> References: <200509101853.55987.nmav@gnutls.org> Message-ID: <200509101903.51439.nmav@gnutls.org> On Saturday 10 September 2005 18:53, Nikos Mavrogiannopoulos wrote: > > My personal preference is to rely on /dev/*random for randomness. If > > that isn't sufficient for someone, she can always point GnuTLS to > > another device (or even file socket) and have full control without > > bogging down the gnutls library. > The file sockets seem like a good idea. We could still keep the libgcrypt > PRNG, but it could run on a separate process (forked at global_init), and > the communication would be via local sockets. I don't know how good it > sounds... but it looks thread and fork safe. > It also sound like a lot of work. On second thought... Libgcrypt itself calls the PRNG internally, thus we cannot avoid say each thread or process having it's own PRNG. The only way to solve this is drop libgcrypt support, for some other library, or use a custom-made libgcrypt. -- Nikos Mavrogiannopoulos From jas at extundo.com Mon Sep 12 02:35:34 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 12 Sep 2005 02:35:34 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: <200509101853.55987.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 10 Sep 2005 18:53:55 +0200") References: <200509101112.42825.nmav@gnutls.org> <200509101853.55987.nmav@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On Saturday 10 September 2005 18:18, Simon Josefsson wrote: > >> > The problem seems to be libgcrypt's random generator. As far as I >> > understand when you fork() the random generator is on the same state for >> > every children. That's why the server produces the same session ID in the >> > second process. >> > I am not really sure about it, and I don't know how to overcome this, >> > that's why I crosspost to gcrypt-devel as well. >> One solution is that we switch to the random number handling that is >> implemented when --enable-nettle is given to a GnuTLS build. Then >> GnuTLS will read (on GNU/Linux) from /dev/urandom for pseudo-random >> data and nonces, and from /dev/random for random data. > > The problem with this is that a gnutls server will depleat /dev/random (we > need to generate a master secret for each session), thus the server will be > most of the time blocked waiting for input for /dev/random. I see. But isn't it worse to use master secrets based on poor random data? The kernel block the read for a reason, after all. I don't see how libgcrypt is in a better position to always give out randomness than the kernel is. Also, I think the current use of libgcrypt's randomness functions by GnuTLS for TLS master secret is equivalent to /dev/urandom, not /dev/random. And /dev/urandom never block, as far as I know. I think we should change the GnuTLS default to read from /dev/urandom for pseudo-random data like TLS master secrets. Unless there is a simple way to make libgcrypt work after fork. I'm talking about GNU/Linux here, but hopefully other systems has similar devices. m4/gc_random contain the following: # Devices with randomness. # FIXME: Are these the best defaults? case "${target}" in *-openbsd*) NAME_OF_RANDOM_DEVICE="/dev/srandom" NAME_OF_PSEUDO_RANDOM_DEVICE="/dev/prandom" NAME_OF_NONCE_DEVICE="/dev/urandom" ;; *-netbsd*) NAME_OF_RANDOM_DEVICE="/dev/srandom" NAME_OF_PSEUDO_RANDOM_DEVICE="/dev/urandom" NAME_OF_NONCE_DEVICE="/dev/urandom" ;; *-solaris* | *-irix* | *-dec-osf* ) NAME_OF_RANDOM_DEVICE="/dev/random" NAME_OF_PSEUDO_RANDOM_DEVICE="/dev/random" NAME_OF_NONCE_DEVICE="/dev/random" ;; *) NAME_OF_RANDOM_DEVICE="/dev/random" NAME_OF_PSEUDO_RANDOM_DEVICE="/dev/urandom" NAME_OF_NONCE_DEVICE="/dev/urandom" ;; esac Again, if there is a system that doesn't have these devices, it is possible to build with --enable-random-device=/var/run/my.random.fifo to make GnuTLS read randomness from somewhere else. Perhaps we could even ship with a small tool that create a fifo and uses libgcrypt to feed it with randomness. That tool should be simple to write. Of course, the libgcrypt approach should be available too, through build flags. But unless someone explains how we should fix the fork problem, I think we should make the default /dev/*random and document the libgcrypt/fork issue. What do you think? >> Alternatively, GnuTLS could use an internal PRNG, and we could add an >> API to seed it. > The problem with internal PRNGs is that they are not thread safe (see > libgcrypt's PRNG). The code could check the PID and re-seed the PRNG if it changes, every time random data is needed. I don't think this is a robust solution though. Thanks, Simon From nmav at gnutls.org Mon Sep 19 12:32:13 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Sep 2005 12:32:13 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: References: <200509101853.55987.nmav@gnutls.org> Message-ID: <200509191232.13444.nmav@gnutls.org> On Monday 12 September 2005 02:35, Simon Josefsson wrote: > >> One solution is that we switch to the random number handling that is > >> implemented when --enable-nettle is given to a GnuTLS build. Then > >> GnuTLS will read (on GNU/Linux) from /dev/urandom for pseudo-random > >> data and nonces, and from /dev/random for random data. > > The problem with this is that a gnutls server will depleat /dev/random > > (we need to generate a master secret for each session), thus the server > > will be most of the time blocked waiting for input for /dev/random. > I see. But isn't it worse to use master secrets based on poor random > data? The kernel block the read for a reason, after all. Using good PRNGs even for master secrets is acceptable, as long as the seed is long and random enough. Also blocking a TLS server, for seconds or even minutes in order for randomness from the kernel to be obtained is unacceptable by most of the sites today. > I don't see how libgcrypt is in a better position to always give out > randomness than the kernel is. Also, I think the current use of The kernel's random functions have not really been designed for being used in cryptographic libraries that require several levels of randomness --in a non blocking way. Also by using /dev/urandom (say for nonces) you also deplete the /dev/random pool. This is unacceptable. Thus the best way is to use some good PRNG sinstead of the kernel's. > libgcrypt's randomness functions by GnuTLS for TLS master secret is > equivalent to /dev/urandom, not /dev/random. And /dev/urandom never > block, as far as I know. Of course... but the uses of /dev/random are really limited. It has high quality (say) of randomness thus you may use it to generate a private key... but for session keys that might be thousants per second it is too much. > I think we should change the GnuTLS default to read from /dev/urandom > for pseudo-random data like TLS master secrets. Unless there is a > simple way to make libgcrypt work after fork. I saw that Werner made a fix for it. Haven't tested it though. > Thanks, > Simon -- Nikos Mavrogiannopoulos From smurf at smurf.noris.de Mon Sep 19 13:24:57 2005 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Mon, 19 Sep 2005 13:24:57 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem In-Reply-To: <200509191232.13444.nmav@gnutls.org> References: <200509101853.55987.nmav@gnutls.org> <200509191232.13444.nmav@gnutls.org> Message-ID: <20050919112457.GA14206@kiste.smurf.noris.de> Hi, Nikos Mavrogiannopoulos: > The kernel's random functions have not really been designed for being used > in cryptographic libraries that require several levels of randomness --in a > non blocking way. Also by using /dev/urandom (say for nonces) you also > deplete the /dev/random pool. This is unacceptable. Thus the best way is to > use some good PRNG sinstead of the kernel's. > There are other possibilities. - The kernel has a hardware RNG. - Teach /dev/urandom not to deplete the randomness pool beyond a certain level, assuming it doesn't do that already. - Add a /dev/uurandom interface to the kernel which bases its randomness on /dev/random's internal state, but doesn't itself deplete the pool. > > I think we should change the GnuTLS default to read from /dev/urandom > > for pseudo-random data like TLS master secrets. I agree. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - :terminal illness: n. 1. Syn. {raster burn}. 2. The `burn-in' condition your CRT tends to get if you don't have a screen saver. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jas at extundo.com Mon Sep 19 23:45:41 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 19 Sep 2005 23:45:41 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: <20050823201935.GA24128@cthulhu.lambers.home> (Martin Lambers's message of "Tue, 23 Aug 2005 22:19:36 +0200") References: <79ae4fa105082209277b2fbfc6@mail.gmail.com> <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> Message-ID: Martin Lambers writes: > The copyright assignment process is started. > > The patch unfortunately leaves '#include ' (line 30) in cli.c. > This line must be removed. A corrected patch is attached. Thanks, Martin. The patch is now installed. > As a test, I changed gl/getpass.h and gl/getpass.c so that it compiles > on Win32 (and always returns NULL ;) > After that, a crossbuild with the Debian mingw32 package worked fine! So > a gnulib getpass module that works for MinGW is all that is missing for > a successful Win32 build. Can you test whether: http://josefsson.org/daily/gnutls/gnutls-20050919.tar.gz build correctly for you? > I have one question, though: src/common.h defines socklen_t to int for > Win32. This is a redefinition since configure previously detected a > missing socklen_t and then defined it to be size_t in config.h. > I think the definition in src/common.h (line 11) should be removed, and > the configure script should always define socklen_t to int. The > 'NOTE' section in the Linux connect(2) man page says that it was > historically an int, and Win32 and MacOS X still use int. I am now using gnulib's socklen module. > Last, I wrote a simple getpass() version for Win32 (attached). This > works completely different from the gnulib getpass module since > - Windows has no /dev/tty concept > - Windows cannot switch terminal properties (AFAIK). > I have no idea how something like this could be properly integrated into > a gnulib module. I have incorporated it into the gnulib getpass module. Thanks! From marlam at marlam.de Wed Sep 21 20:57:38 2005 From: marlam at marlam.de (Martin Lambers) Date: Wed, 21 Sep 2005 20:57:38 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: References: <79ae4fa105082209277b2fbfc6@mail.gmail.com> <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> Message-ID: <20050921185738.GA13311@cthulhu.lambers.home> On Mon, 19. Sep 2005, 23:45:41 +0200, Simon Josefsson wrote: > Can you test whether: > > http://josefsson.org/daily/gnutls/gnutls-20050919.tar.gz > > build correctly for you? It does not, but the changes required to make it build correctly are small: The first patch removes 'char *program_name = "gnutls";' from lib/gnutls_global.c. This apparently reverts a change from 2005-08-30. I did not get the missing symbols error afterwards. When does it cause problems for you? The second patch changes the example code in doc/examples: 1. Replace bzero with memset. 2. Don't use mmap (this is the same change that was done in src/cli.c). 3. Include a different header on WIN32. 4. Use inet_ntoa instead of inet_ntop on WIN32. But maybe it would be better to disable compilation of the examples on Win32 instead of cluttering example code with #ifdefs. The changes 1 and 2 may be useful nevertheless; I can send a patch with only these changes if you wish. With these patches, the following works on a Debian machine with the mingw32 packages: $ ./configure --host=i586-mingw32msvc --prefix=/tmp/t $ make $ make install A quick test with mpop compiled against the resulting library did not show problems. Martin -------------- next part -------------- diff -uNr gnutls-1.2.8/lib/gnutls_global.c gnutls-20050919+win32_patches/lib/gnutls_global.c --- gnutls-1.2.8/lib/gnutls_global.c 2005-08-31 02:23:05.000000000 +0200 +++ gnutls-20050919+win32_patches/lib/gnutls_global.c 2005-09-21 18:37:23.991989000 +0200 @@ -39,9 +39,6 @@ ASN1_TYPE _gnutls_pkix1_asn; ASN1_TYPE _gnutls_gnutls_asn; -/* To shut up missing symbols from error module. */ -char *program_name = "gnutls"; - /** * gnutls_global_set_log_function - This function sets the logging function * @log_func: it's a log function -------------- next part -------------- diff -uNr gnutls-1.2.8/doc/examples/ex-cert-select.c gnutls-20050919+win32_patches/doc/examples/ex-cert-select.c --- gnutls-1.2.8/doc/examples/ex-cert-select.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-cert-select.c 2005-09-21 18:48:54.391989000 +0200 @@ -3,11 +3,14 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include -#include #include #include #include @@ -37,38 +40,33 @@ gnutls_x509_privkey_t key; /* Helper functions to load a certificate and key - * files into memory. They use mmap for simplicity. + * files into memory. */ -static gnutls_datum_t -mmap_file (const char *file) +static gnutls_datum load_file(const char *file) { - int fd; - gnutls_datum_t mmaped_file = { NULL, 0 }; - struct stat stat_st; + FILE *f; + gnutls_datum loaded_file = { NULL, 0 }; + long filelen; void *ptr; - fd = open (file, 0); - if (fd == -1) - return mmaped_file; - - fstat (fd, &stat_st); - - ptr = mmap (NULL, stat_st.st_size, PROT_READ, MAP_SHARED, fd, 0); - close (fd); - - if (ptr == MAP_FAILED) - return mmaped_file; - - mmaped_file.data = ptr; - mmaped_file.size = stat_st.st_size; + if (!(f = fopen(file, "r")) + || fseek(f, 0, SEEK_END) != 0 + || (filelen = ftell(f)) < 0 + || fseek(f, 0, SEEK_SET) != 0 + || !(ptr = malloc((size_t)filelen)) + || fread(ptr, 1, (size_t)filelen, f) < (size_t)filelen) + { + return loaded_file; + } - return mmaped_file; + loaded_file.data = ptr; + loaded_file.size = (unsigned int)filelen; + return loaded_file; } -static void -munmap_file (gnutls_datum_t data) +static void unload_file(gnutls_datum data) { - munmap (data.data, data.size); + free(data.data); } /* Load the certificate and the private key. @@ -79,7 +77,7 @@ int ret; gnutls_datum_t data; - data = mmap_file (CERT_FILE); + data = load_file (CERT_FILE); if (data.data == NULL) { fprintf (stderr, "*** Error loading cert file.\n"); @@ -95,9 +93,9 @@ exit (1); } - munmap_file (data); + unload_file (data); - data = mmap_file (KEY_FILE); + data = load_file (KEY_FILE); if (data.data == NULL) { fprintf (stderr, "*** Error loading key file.\n"); @@ -114,7 +112,7 @@ exit (1); } - munmap_file (data); + unload_file (data); } diff -uNr gnutls-1.2.8/doc/examples/ex-client1.c gnutls-20050919+win32_patches/doc/examples/ex-client1.c --- gnutls-1.2.8/doc/examples/ex-client1.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-client1.c 2005-09-21 18:59:29.431989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include diff -uNr gnutls-1.2.8/doc/examples/ex-client2.c gnutls-20050919+win32_patches/doc/examples/ex-client2.c --- gnutls-1.2.8/doc/examples/ex-client2.c 2005-08-13 02:23:03.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-client2.c 2005-09-21 19:00:00.451989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include diff -uNr gnutls-1.2.8/doc/examples/ex-serv1.c gnutls-20050919+win32_patches/doc/examples/ex-serv1.c --- gnutls-1.2.8/doc/examples/ex-serv1.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-serv1.c 2005-09-21 19:48:40.681989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include #include @@ -126,8 +130,12 @@ sd = accept (listen_sd, (SA *) & sa_cli, &client_len); printf ("- connection from %s, port %d\n", - inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, - sizeof (topbuf)), ntohs (sa_cli.sin_port)); +#ifdef _WIN32 + inet_ntoa(sa_cli.sin_addr), +#else + inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, sizeof (topbuf)), +#endif + ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); ret = gnutls_handshake (session); @@ -147,7 +155,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) diff -uNr gnutls-1.2.8/doc/examples/ex-serv-anon.c gnutls-20050919+win32_patches/doc/examples/ex-serv-anon.c --- gnutls-1.2.8/doc/examples/ex-serv-anon.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-serv-anon.c 2005-09-21 19:50:01.971989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include #include @@ -111,8 +115,12 @@ sd = accept (listen_sd, (SA *) & sa_cli, &client_len); printf ("- connection from %s, port %d\n", - inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, - sizeof (topbuf)), ntohs (sa_cli.sin_port)); +#ifdef _WIN32 + inet_ntoa(sa_cli.sin_addr), +#else + inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, sizeof (topbuf)), +#endif + ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); ret = gnutls_handshake (session); @@ -132,7 +140,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) diff -uNr gnutls-1.2.8/doc/examples/ex-serv-export.c gnutls-20050919+win32_patches/doc/examples/ex-serv-export.c --- gnutls-1.2.8/doc/examples/ex-serv-export.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-serv-export.c 2005-09-21 19:51:05.311989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include #include @@ -171,8 +175,12 @@ sd = accept (listen_sd, (SA *) & sa_cli, &client_len); printf ("- connection from %s, port %d\n", - inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, - sizeof (topbuf)), ntohs (sa_cli.sin_port)); +#ifdef _WIN32 + inet_ntoa(sa_cli.sin_addr), +#else + inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, sizeof (topbuf)), +#endif + ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); ret = gnutls_handshake (session); @@ -191,7 +199,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) diff -uNr gnutls-1.2.8/doc/examples/ex-serv-pgp.c gnutls-20050919+win32_patches/doc/examples/ex-serv-pgp.c --- gnutls-1.2.8/doc/examples/ex-serv-pgp.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-serv-pgp.c 2005-09-21 19:52:19.831989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include #include @@ -130,8 +134,12 @@ sd = accept (listen_sd, (SA *) & sa_cli, &client_len); printf ("- connection from %s, port %d\n", - inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, - sizeof (topbuf)), ntohs (sa_cli.sin_port)); +#ifdef _WIN32 + inet_ntoa(sa_cli.sin_addr), +#else + inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, sizeof (topbuf)), +#endif + ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); ret = gnutls_handshake (session); @@ -151,7 +159,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) diff -uNr gnutls-1.2.8/doc/examples/ex-serv-srp.c gnutls-20050919+win32_patches/doc/examples/ex-serv-srp.c --- gnutls-1.2.8/doc/examples/ex-serv-srp.c 2005-08-11 02:23:02.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/ex-serv-srp.c 2005-09-21 19:53:15.651989000 +0200 @@ -3,9 +3,13 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +#else +# include +# include +# include +#endif #include #include #include @@ -115,8 +119,12 @@ sd = accept (listen_sd, (SA *) & sa_cli, &client_len); printf ("- connection from %s, port %d\n", - inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, - sizeof (topbuf)), ntohs (sa_cli.sin_port)); +#ifdef _WIN32 + inet_ntoa(sa_cli.sin_addr), +#else + inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, sizeof (topbuf)), +#endif + ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); ret = gnutls_handshake (session); @@ -135,7 +143,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) diff -uNr gnutls-1.2.8/doc/examples/tcp.c gnutls-20050919+win32_patches/doc/examples/tcp.c --- gnutls-1.2.8/doc/examples/tcp.c 2005-08-12 12:13:40.000000000 +0200 +++ gnutls-20050919+win32_patches/doc/examples/tcp.c 2005-09-21 18:58:36.201989000 +0200 @@ -2,9 +2,14 @@ #include #include #include -#include -#include -#include +#ifdef _WIN32 +# include +# define SHUT_RDWR SD_BOTH +#else +# include +# include +# include +#endif #include #define SA struct sockaddr @@ -27,7 +32,11 @@ memset (&sa, '\0', sizeof (sa)); sa.sin_family = AF_INET; sa.sin_port = htons (atoi (PORT)); +#ifdef _WIN32 + sa.sin_addr.s_addr = inet_addr(SERVER); +#else inet_pton (AF_INET, SERVER, &sa.sin_addr); +#endif err = connect (sd, (SA *) & sa, sizeof (sa)); if (err < 0) From jas at extundo.com Wed Sep 21 22:44:57 2005 From: jas at extundo.com (Simon Josefsson) Date: Wed, 21 Sep 2005 22:44:57 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: <20050921185738.GA13311@cthulhu.lambers.home> (Martin Lambers's message of "Wed, 21 Sep 2005 20:57:38 +0200") References: <79ae4fa105082209277b2fbfc6@mail.gmail.com> <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> <20050921185738.GA13311@cthulhu.lambers.home> Message-ID: Martin Lambers writes: > On Mon, 19. Sep 2005, 23:45:41 +0200, Simon Josefsson wrote: >> Can you test whether: >> >> http://josefsson.org/daily/gnutls/gnutls-20050919.tar.gz >> >> build correctly for you? > > It does not, but the changes required to make it build correctly are > small: Thanks for testing! > The first patch removes 'char *program_name = "gnutls";' from > lib/gnutls_global.c. This apparently reverts a change from 2005-08-30. > I did not get the missing symbols error afterwards. When does it cause > problems for you? I had problems with this on uClinux too... The problem is that the error module from gnulib use program_name, but the core GnuTLS library does not use the error module. On some systems, the core library will not link because program_name is not present. The error module is only used by some code in src/. There has been discussion on solving this on the gnulib list, i.e., having two different gnulib directories, one for the library in lib/ and one for the application in src/. This would also make it possible to use GPL'd gnulib modules in src/, without causing license problems in lib/. Currently the only solution is to create a configure.ac in lib/ and build it separately. This is what I did in GNU SASL, but I don't want to do the same for GnuTLS. I think the simplest solutions is to stop using the error module in src/... I have made this change in CVS now, and applied your fix to remove setting program_name in the core library too. > The second patch changes the example code in doc/examples: > 1. Replace bzero with memset. > 2. Don't use mmap (this is the same change that was done in src/cli.c). Ok. > 3. Include a different header on WIN32. > 4. Use inet_ntoa instead of inet_ntop on WIN32. No... There should be gnulib modules to handle this silliness. There already is a inet_ntop gnulib module. There could be a gnulib module that provided sys/socket.h, netinet/in.h and arpa/inet.h on platforms that doesn't have them. For mingw32, those files could simply include winsock2.h if that is indeed the proper way to get access to POSIX functionality. > But maybe it would be better to disable compilation of the examples on > Win32 instead of cluttering example code with #ifdefs. Exactly. We should stop cluttering code with #ifdef's. We should write code that works best on the GNU platform, and use gnulib modules where the native system is failing. I'll bring up the header issue on the gnulib list. If it is solved, the examples will link to gnulib and we can also use gnulib's inet_ntop module. If it is not solved, we disable the examples on platforms that lack sys/socket.h. It would be useful to go over the #ifdef WIN32's in src/ too, and make them go away. Would you like to take a stab at it? > The changes 1 and 2 may be useful nevertheless; I can send a patch with > only these changes if you wish. Yes, please do! Only for 1 and 2. Thanks, Simon From marlam at marlam.de Thu Sep 22 23:15:02 2005 From: marlam at marlam.de (Martin Lambers) Date: Thu, 22 Sep 2005 23:15:02 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: References: <79ae4fa105082209277b2fbfc6@mail.gmail.com> <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> <20050921185738.GA13311@cthulhu.lambers.home> Message-ID: <20050922211502.GA9894@cthulhu.lambers.home> On Wed, 21. Sep 2005, 22:44:57 +0200, Simon Josefsson wrote: > > The first patch removes 'char *program_name = "gnutls";' from > > lib/gnutls_global.c. This apparently reverts a change from 2005-08-30. > > I did not get the missing symbols error afterwards. When does it cause > > problems for you? > > I had problems with this on uClinux too... The problem is that the > error module from gnulib use program_name, but the core GnuTLS library > does not use the error module. On some systems, the core library will > not link because program_name is not present. The error module is > only used by some code in src/. > > There has been discussion on solving this on the gnulib list, i.e., > having two different gnulib directories, one for the library in lib/ > and one for the application in src/. This would also make it possible > to use GPL'd gnulib modules in src/, without causing license problems > in lib/. Currently the only solution is to create a configure.ac in > lib/ and build it separately. This is what I did in GNU SASL, but I > don't want to do the same for GnuTLS. I've been following that discussion loosely, but now I realize how useful two different directories could be. > > The second patch changes the example code in doc/examples: > > 1. Replace bzero with memset. > > 2. Don't use mmap (this is the same change that was done in src/cli.c). > > Ok. I attached a patch wich contains only these changes. > > 3. Include a different header on WIN32. > > 4. Use inet_ntoa instead of inet_ntop on WIN32. > > No... There should be gnulib modules to handle this silliness. There > already is a inet_ntop gnulib module. There could be a gnulib module > that provided sys/socket.h, netinet/in.h and arpa/inet.h on platforms > that doesn't have them. For mingw32, those files could simply include > winsock2.h if that is indeed the proper way to get access to POSIX > functionality. Unfortunately, every single socket function on Win32 is incompatible with POSIX in some way (or so it seems). Sometimes it's obvious, sometimes not. Examples: - errno is never set - The "network library" must be initialized and closed with special functions - Sockets cannot just be closed with close(), they need closesocket() - shutdown() uses non-standard constants - You cannot use fcntl() on a socket. There's only a limited ioctlsocket() function. > > But maybe it would be better to disable compilation of the examples on > > Win32 instead of cluttering example code with #ifdefs. > > Exactly. We should stop cluttering code with #ifdef's. We should > write code that works best on the GNU platform, and use gnulib modules > where the native system is failing. You're right. I'll keep that in mind. However, this could mean to drop support for MinGW: I doubt that gnulib is the best way to achieve reasonable POSIX support on Win32. An unlink() replacement that delays the actual unlink operation until all file descriptors referring to the file are closed is one example: such a function is not easy to write on Win32. The same holds for using standard functions like fcntl() or even close() on sockets. Programs that are expected to work on Win32 often avoid to rely on basic standardized functionality like this. Such code does not qualify for "works best on the GNU platform" anymore. Reasonable POSIX support on Win32 is not just a collection of fixes for minor misbehaviour; it is a major task. Perhaps it would be better to leave that to an external project and only support "MinGW + plibc" (or something similar) as a target platform. BTW, the unlink() and fcntl() examples are not yet handled by plibc as far as I can tell. Martin -------------- next part -------------- Index: ex-cert-select.c =================================================================== RCS file: /cvs/gnutls/gnutls/doc/examples/ex-cert-select.c,v retrieving revision 1.5 diff -u -r1.5 ex-cert-select.c --- ex-cert-select.c 10 Aug 2005 09:09:04 -0000 1.5 +++ ex-cert-select.c 22 Sep 2005 20:05:19 -0000 @@ -7,7 +7,6 @@ #include #include #include -#include #include #include #include @@ -37,38 +36,34 @@ gnutls_x509_privkey_t key; /* Helper functions to load a certificate and key - * files into memory. They use mmap for simplicity. + * files into memory. */ -static gnutls_datum_t -mmap_file (const char *file) +static gnutls_datum +load_file (const char *file) { - int fd; - gnutls_datum_t mmaped_file = { NULL, 0 }; - struct stat stat_st; + FILE *f; + gnutls_datum loaded_file = { NULL, 0 }; + long filelen; void *ptr; - fd = open (file, 0); - if (fd == -1) - return mmaped_file; - - fstat (fd, &stat_st); - - ptr = mmap (NULL, stat_st.st_size, PROT_READ, MAP_SHARED, fd, 0); - close (fd); - - if (ptr == MAP_FAILED) - return mmaped_file; - - mmaped_file.data = ptr; - mmaped_file.size = stat_st.st_size; + if (!(f = fopen(file, "r")) + || fseek(f, 0, SEEK_END) != 0 + || (filelen = ftell(f)) < 0 + || fseek(f, 0, SEEK_SET) != 0 + || !(ptr = malloc((size_t)filelen)) + || fread(ptr, 1, (size_t)filelen, f) < (size_t)filelen) + { + return loaded_file; + } - return mmaped_file; + loaded_file.data = ptr; + loaded_file.size = (unsigned int)filelen; + return loaded_file; } -static void -munmap_file (gnutls_datum_t data) +static void unload_file(gnutls_datum data) { - munmap (data.data, data.size); + free(data.data); } /* Load the certificate and the private key. @@ -79,7 +74,7 @@ int ret; gnutls_datum_t data; - data = mmap_file (CERT_FILE); + data = load_file (CERT_FILE); if (data.data == NULL) { fprintf (stderr, "*** Error loading cert file.\n"); @@ -95,9 +90,9 @@ exit (1); } - munmap_file (data); + unload_file (data); - data = mmap_file (KEY_FILE); + data = load_file (KEY_FILE); if (data.data == NULL) { fprintf (stderr, "*** Error loading key file.\n"); @@ -114,7 +109,7 @@ exit (1); } - munmap_file (data); + unload_file (data); } Index: ex-serv-anon.c =================================================================== RCS file: /cvs/gnutls/gnutls/doc/examples/ex-serv-anon.c,v retrieving revision 1.3 diff -u -r1.3 ex-serv-anon.c --- ex-serv-anon.c 10 Aug 2005 09:09:04 -0000 1.3 +++ ex-serv-anon.c 22 Sep 2005 20:05:19 -0000 @@ -132,7 +132,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) Index: ex-serv-export.c =================================================================== RCS file: /cvs/gnutls/gnutls/doc/examples/ex-serv-export.c,v retrieving revision 1.4 diff -u -r1.4 ex-serv-export.c --- ex-serv-export.c 10 Aug 2005 09:09:04 -0000 1.4 +++ ex-serv-export.c 22 Sep 2005 20:05:20 -0000 @@ -191,7 +191,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) Index: ex-serv-pgp.c =================================================================== RCS file: /cvs/gnutls/gnutls/doc/examples/ex-serv-pgp.c,v retrieving revision 1.4 diff -u -r1.4 ex-serv-pgp.c --- ex-serv-pgp.c 10 Aug 2005 09:09:04 -0000 1.4 +++ ex-serv-pgp.c 22 Sep 2005 20:05:20 -0000 @@ -151,7 +151,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) Index: ex-serv-srp.c =================================================================== RCS file: /cvs/gnutls/gnutls/doc/examples/ex-serv-srp.c,v retrieving revision 1.4 diff -u -r1.4 ex-serv-srp.c --- ex-serv-srp.c 10 Aug 2005 09:09:04 -0000 1.4 +++ ex-serv-srp.c 22 Sep 2005 20:05:20 -0000 @@ -135,7 +135,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) Index: ex-serv1.c =================================================================== RCS file: /cvs/gnutls/gnutls/doc/examples/ex-serv1.c,v retrieving revision 1.5 diff -u -r1.5 ex-serv1.c --- ex-serv1.c 10 Aug 2005 09:09:04 -0000 1.5 +++ ex-serv1.c 22 Sep 2005 20:05:21 -0000 @@ -147,7 +147,7 @@ i = 0; for (;;) { - bzero (buffer, MAX_BUF + 1); + memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) From jas at extundo.com Fri Sep 23 00:46:27 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 23 Sep 2005 00:46:27 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: <20050922211502.GA9894@cthulhu.lambers.home> (Martin Lambers's message of "Thu, 22 Sep 2005 23:15:02 +0200") References: <79ae4fa105082209277b2fbfc6@mail.gmail.com> <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> <20050921185738.GA13311@cthulhu.lambers.home> <20050922211502.GA9894@cthulhu.lambers.home> Message-ID: Martin Lambers writes: >> > The second patch changes the example code in doc/examples: >> > 1. Replace bzero with memset. >> > 2. Don't use mmap (this is the same change that was done in src/cli.c). >> >> Ok. > > I attached a patch wich contains only these changes. Applied, many thanks! > Unfortunately, every single socket function on Win32 is incompatible > with POSIX in some way (or so it seems). Sometimes it's obvious, > sometimes not. > Examples: > - errno is never set > - The "network library" must be initialized and closed with special > functions > - Sockets cannot just be closed with close(), they need closesocket() > - shutdown() uses non-standard constants > - You cannot use fcntl() on a socket. There's only a limited > ioctlsocket() function. Ouch. So while cross-compiling to mingw32 now work without link failures, there will be subtle problems when the resulting binary is used. >> > But maybe it would be better to disable compilation of the examples on >> > Win32 instead of cluttering example code with #ifdefs. >> >> Exactly. We should stop cluttering code with #ifdef's. We should >> write code that works best on the GNU platform, and use gnulib modules >> where the native system is failing. > > You're right. I'll keep that in mind. > > However, this could mean to drop support for MinGW: I doubt that gnulib > is the best way to achieve reasonable POSIX support on Win32. > > An unlink() replacement that delays the actual unlink operation until > all file descriptors referring to the file are closed is one example: > such a function is not easy to write on Win32. The same holds for > using standard functions like fcntl() or even close() on sockets. > > Programs that are expected to work on Win32 often avoid to rely on basic > standardized functionality like this. Such code does not qualify for > "works best on the GNU platform" anymore. > > Reasonable POSIX support on Win32 is not just a collection of fixes for > minor misbehaviour; it is a major task. Perhaps it would be better to > leave that to an external project and only support "MinGW + plibc" (or > something similar) as a target platform. Yes, I think you are right. However, it isn't impossible to integrate something like plibc in gnulib, or in GnuTLS itself. Then the GnuTLS core code will be good and the resulting binaries should run properly too. I'm not sure GnuTLS need a lot from POSIX, perhaps we can even integrate the plibc functions we need in GnuTLS. Btw, have you tested to run a mingw32 built gnutls-cli on a Windows platform? It shouldn't be too hard to test it to see whether it works or almost works. Thanks, Simon From marlam at marlam.de Fri Sep 23 21:35:17 2005 From: marlam at marlam.de (Martin Lambers) Date: Fri, 23 Sep 2005 21:35:17 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: References: <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> <20050921185738.GA13311@cthulhu.lambers.home> <20050922211502.GA9894@cthulhu.lambers.home> Message-ID: <20050923193517.GA10477@cthulhu.lambers.home> On Fri, 23. Sep 2005, 00:46:27 +0200, Simon Josefsson wrote: > > Reasonable POSIX support on Win32 is not just a collection of fixes for > > minor misbehaviour; it is a major task. Perhaps it would be better to > > leave that to an external project and only support "MinGW + plibc" (or > > something similar) as a target platform. > > Yes, I think you are right. However, it isn't impossible to integrate > something like plibc in gnulib, or in GnuTLS itself. Then the GnuTLS > core code will be good and the resulting binaries should run properly > too. I'm not sure GnuTLS need a lot from POSIX, perhaps we can even > integrate the plibc functions we need in GnuTLS. Judging from some quick greps, I think at least the following is necessary to get rid of #ifdef _WIN32: - Integration of existing gnulib modules: - inet_ntop - New gnulib modules for missing headers: - - - - - New gnulib modules to make socket functions set errno, provide the missing errnos such as ECONNREFUSED, and provide a strerror() that understands these additional errnos. - select() - connect() - accept() - recv() - send() - ... - New gnulib modules to make some functions work with sockets: - close() - fcntl() which handles O_NONBLOCK for sockets - Call WSAStartup() / WSACleanup() somewhere without having them in the main code. - Non-networking issues: - getpwuid(), getuid() - signal handling: Using SIGALARM for network timeouts could be replaced by using setsockopt with SO_RCVTIMEO and SO_SNDTIMEO. But this does not work on Windows <= 2000 and on several UNIX versions including Solaris. It does work on GNU/Linux and *BSD. I'm sorry to say that I currently don't have enough spare time to be able to work on these things. > Btw, have you tested to run a mingw32 built gnutls-cli on a Windows > platform? It shouldn't be too hard to test it to see whether it works > or almost works. It does not. I tested $ gnutls-cli.exe --print-cert --port 25 --starttls some.smtp.server It hangs after printing "Simple Client Mode:". That's because select() is called and the test after the call assumes that errno is set. This results in an endless loop. Martin From jas at extundo.com Sat Sep 24 10:04:02 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 24 Sep 2005 10:04:02 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: <20050923193517.GA10477@cthulhu.lambers.home> (Martin Lambers's message of "Fri, 23 Sep 2005 21:35:17 +0200") References: <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> <20050921185738.GA13311@cthulhu.lambers.home> <20050922211502.GA9894@cthulhu.lambers.home> <20050923193517.GA10477@cthulhu.lambers.home> Message-ID: Martin Lambers writes: > On Fri, 23. Sep 2005, 00:46:27 +0200, Simon Josefsson wrote: >> > Reasonable POSIX support on Win32 is not just a collection of fixes for >> > minor misbehaviour; it is a major task. Perhaps it would be better to >> > leave that to an external project and only support "MinGW + plibc" (or >> > something similar) as a target platform. >> >> Yes, I think you are right. However, it isn't impossible to integrate >> something like plibc in gnulib, or in GnuTLS itself. Then the GnuTLS >> core code will be good and the resulting binaries should run properly >> too. I'm not sure GnuTLS need a lot from POSIX, perhaps we can even >> integrate the plibc functions we need in GnuTLS. > > Judging from some quick greps, I think at least the following is > necessary to get rid of #ifdef _WIN32: Many thanks for checking this! > - Integration of existing gnulib modules: > - inet_ntop The module is LGPL so this isn't a problem. > - New gnulib modules for missing headers: > - > - > - > - Bruno said on the gnulib list that this was doable. > - New gnulib modules to make socket functions set errno, provide > the missing errnos such as ECONNREFUSED, and provide a strerror() that > understands these additional errnos. > - select() > - connect() > - accept() > - recv() > - send() > - ... We could do this too, but it would take more time to figure out which functions need to be re-implemented. And also to write the re-implementation, I haven't looked at plibc enough to know whether it would work or not. > - New gnulib modules to make some functions work with sockets: > - close() > - fcntl() which handles O_NONBLOCK for sockets > > - Call WSAStartup() / WSACleanup() somewhere without having them in the > main code. I'm not sure how to do this, but may be doable. Perhaps calling WSAStartup/WSACleanup in a #ifdef WIN32 is acceptable. > - Non-networking issues: > - getpwuid(), getuid() > - signal handling: > Using SIGALARM for network timeouts could be replaced by using > setsockopt with SO_RCVTIMEO and SO_SNDTIMEO. But this does not work on > Windows <= 2000 and on several UNIX versions including Solaris. It does > work on GNU/Linux and *BSD. I wonder if there is a better solution. > I'm sorry to say that I currently don't have enough spare time to be > able to work on these things. Your message is a very good stating point... >> Btw, have you tested to run a mingw32 built gnutls-cli on a Windows >> platform? It shouldn't be too hard to test it to see whether it works >> or almost works. > > It does not. I tested > $ gnutls-cli.exe --print-cert --port 25 --starttls some.smtp.server > It hangs after printing "Simple Client Mode:". That's because select() > is called and the test after the call assumes that errno is set. This > results in an endless loop. The next step would be to integrate the plibc select and see what breaks then. Thanks, Simon From jas at extundo.com Sat Sep 24 11:58:27 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 24 Sep 2005 11:58:27 +0200 Subject: [Help-gnutls] Re: Build gnutls on windows In-Reply-To: (Simon Josefsson's message of "Sat, 24 Sep 2005 10:04:02 +0200") References: <20050822175128.GA8086@cthulhu.lambers.home> <20050822220915.GA7425@cthulhu.lambers.home> <20050823201935.GA24128@cthulhu.lambers.home> <20050921185738.GA13311@cthulhu.lambers.home> <20050922211502.GA9894@cthulhu.lambers.home> <20050923193517.GA10477@cthulhu.lambers.home> Message-ID: Following up to myself... Simon Josefsson writes: >> - Integration of existing gnulib modules: >> - inet_ntop > > The module is LGPL so this isn't a problem. I noticed we had a check for inet_ntop, and a simple replacement in src/common.c already, so I replaced it with the gnulib module. >> - New gnulib modules for missing headers: >> - >> - >> - >> - > > Bruno said on the gnulib list that this was doable. Let's see how useful that module would be first... Perhaps it just hide other problems. Thanks, Simon From jme at off.net Mon Sep 26 21:09:08 2005 From: jme at off.net (jerome etienne) Date: Mon, 26 Sep 2005 21:09:08 +0200 Subject: [Help-gnutls] gnutls x509 library to get a rsa encryption Message-ID: <43384754.7090709@off.net> Hello, I would like to do encryption/decryption based on a x509 certificate, i looked at the documentation of the x509 library and failed to find a function for it. Is there a function that i missed ? some existing source code that i could look at ? any suggestion ? i looked at the gnutls 1.2.7 source and, in lib/gnutls_pk.c, found _gnutls_pkcs1_rsa_encrypt() which is exactly what im looking for. is this functions exported and i missed it ? thanks From nmav at gnutls.org Mon Sep 26 22:08:13 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Sep 2005 22:08:13 +0200 Subject: [Help-gnutls] gnutls x509 library to get a rsa encryption In-Reply-To: <43384754.7090709@off.net> References: <43384754.7090709@off.net> Message-ID: <200509262208.13675.nmav@gnutls.org> On Monday 26 September 2005 21:09, jerome etienne wrote: > Hello, > I would like to do encryption/decryption based on a x509 certificate, i > looked at the documentation of the x509 library and failed to find a > function for it. Is there a function that i missed ? some existing > source code that i could look at ? any suggestion ? Indeed there are only signing functions (gnutls_x509_crt_verify_data, gnutls_x509_privkey_sign_data). > i looked at the gnutls 1.2.7 source and, in lib/gnutls_pk.c, found > _gnutls_pkcs1_rsa_encrypt() which is exactly what im looking for. is > this functions exported and i missed it ? No it is not exported. The current gnutls_x509_* interface is quite and initially was not intended for low level uses as this one. Adding this might not harm either and it doesn't look that hard. However I don't think I have time to do it, but patches are always welcome! > thanks -- Nikos Mavrogiannopoulos From jas at extundo.com Tue Sep 27 10:27:17 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 27 Sep 2005 10:27:17 +0200 Subject: [Help-gnutls] Re: gnutls x509 library to get a rsa encryption In-Reply-To: <43384754.7090709@off.net> (jerome etienne's message of "Mon, 26 Sep 2005 21:09:08 +0200") References: <43384754.7090709@off.net> Message-ID: jerome etienne writes: > Hello, > > I would like to do encryption/decryption based on a x509 certificate, i > looked at the documentation of the x509 library and failed to find a > function for it. Is there a function that i missed ? some existing > source code that i could look at ? any suggestion ? If you want to do X.509 based message protection, I think you should look at CMS aka S/MIME. You'll likely have to reinvent the wheel otherwise. Development versions of GnuPG has S/MIME functionality. Thanks, Simon