From unleashed at amule.org Sun May 1 07:18:02 2005 From: unleashed at amule.org (Alex Unleashed) Date: Sun, 01 May 2005 07:18:02 +0200 Subject: [gnutls-dev] Re: MD4 support In-Reply-To: References: <1114881404.11072.8.camel@localhost> <1114888510.10787.24.camel@localhost> Message-ID: <1114924682.10712.8.camel@localhost> El s?b, 30-04-2005 a las 22:54 +0200, Simon Josefsson escribi?: > Ah, but then, can't you use libgcrypt? Libgcrypt support MD4. Or Yes, I'll have a look at it tomorrow. At first glance it seems quite appropriate while still covering my other requirements. Thank you for the hint. > I think it is a layering violation. GnuTLS' goal is to provide an TLS Indeed it is. :) > Hope this helps, Yes, thank you all for your kind answers. Regards, Alex From guus at sliepen.eu.org Sat May 7 15:45:45 2005 From: guus at sliepen.eu.org (Guus Sliepen) Date: Sat, 7 May 2005 15:45:45 +0200 Subject: [gnutls-dev] Intent to implement DTLS Message-ID: <20050507134545.GJ2945@sliepen.eu.org> Hello developers, Unless others are already working on it, I intend to implement Datagram TLS, as specified in draft-rescorla-dtls-04.txt, in GNUTLS. DTLS slightly changes the handshake protocol and the record layer to allow TLS to run over UDP (or other datagram protocols). Some applications need the UDP semantics (unreliable, out-of-order packet delivery) in order to function well. These include multimedia applications and VPNs. Once GNUTLS supports DTLS, tinc (http://www.tinc-vpn.org/) will use it to securely transmit network packets over the Internet. OpenSSL has recently merged a patch for DTLS support in its CVS repository. DTLS support will be included in version 0.9.8. Thus it will be possible to do interoperability tests. I would welcome CVS write access, but otherwise I'll send patches. I also do not mind transferring copyrights to the FSF (I know I have to sign a form and send it back to the FSF, but last time I got free stickers so it was OK). If you have suggestions about how to proceed, please tell me. Also, I will be working on this in spare time, help is appreciated. -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- 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 Sat May 7 16:54:12 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 07 May 2005 16:54:12 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: <20050507134545.GJ2945@sliepen.eu.org> (Guus Sliepen's message of "Sat, 7 May 2005 15:45:45 +0200") References: <20050507134545.GJ2945@sliepen.eu.org> Message-ID: Guus Sliepen writes: > Hello developers, > > Unless others are already working on it, I intend to implement Datagram > TLS, as specified in draft-rescorla-dtls-04.txt, in GNUTLS. DTLS > slightly changes the handshake protocol and the record layer to allow > TLS to run over UDP (or other datagram protocols). Some applications > need the UDP semantics (unreliable, out-of-order packet delivery) in > order to function well. These include multimedia applications and VPNs. > Once GNUTLS supports DTLS, tinc (http://www.tinc-vpn.org/) will use it > to securely transmit network packets over the Internet. > > OpenSSL has recently merged a patch for DTLS support in its CVS > repository. DTLS support will be included in version 0.9.8. Thus > it will be possible to do interoperability tests. Hi Guus, and welcome. DTLS sounds like a lovely contribution. > I would welcome CVS write access, but otherwise I'll send patches. I think that can be arranged, but it might be simpler to wait until you have something that sort of work. It would have to be added to a branch anyway initially, so you could copy our CVS tree and set up a local CVS mirror to play with meanwhile. > If you have suggestions about how to proceed, please tell me. I'd suggest a high-level approach like this: 1. Implement it grossly, possibly modifying existing functions, until it interoperate with OpenSSL. 2. Building on what you've learned doing 1, write up a suggestion of what you think a clean API would be and post it here. Try not to think about how you would actually implement that API, but rather how it would be used. Perhaps some discussion at this point. 3. Change the code to implement the clean API. Just my $.2. > Also, I will be working on this in spare time, help is appreciated. I'll cheer you on, and will try to assist with testing etc, but will probably have little time to code. The last might change, I have mentioned DTLS support as a useful project to some people. Regards, Simon From guus at sliepen.eu.org Sat May 7 17:18:22 2005 From: guus at sliepen.eu.org (Guus Sliepen) Date: Sat, 7 May 2005 17:18:22 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: References: <20050507134545.GJ2945@sliepen.eu.org> Message-ID: <20050507151822.GN2945@sliepen.eu.org> On Sat, May 07, 2005 at 04:54:12PM +0200, Simon Josefsson wrote: > > I would welcome CVS write access, but otherwise I'll send patches. > > I think that can be arranged, but it might be simpler to wait until > you have something that sort of work. It would have to be added to a > branch anyway initially, so you could copy our CVS tree and set up a > local CVS mirror to play with meanwhile. Ok. > > If you have suggestions about how to proceed, please tell me. > > I'd suggest a high-level approach like this: > > 1. Implement it grossly, possibly modifying existing functions, until > it interoperate with OpenSSL. > > 2. Building on what you've learned doing 1, write up a suggestion of > what you think a clean API would be and post it here. Try not to > think about how you would actually implement that API, but rather > how it would be used. Perhaps some discussion at this point. > > 3. Change the code to implement the clean API. Sounds like a good idea. But of course I have already looked at the GNUTLS source and I already have a suggestion for an API. Since the difference between TLS and DTLS is the transport layer (TCP vs. UDP), I would suggest adding the following enum and function calls: typedef enum gnutls_transport_type { GNUTLS_TRANSPORT_TYPE_STREAM = 1, GNUTLS_TRANSPORT_TYPE_DATAGRAM, } gnutls_transport_type; void gnutls_transport_set_type(gnutls_session session, gnutls_transport_type type); gnutls_transport_type gnutls_transport_get_type(gnutls_session session); Of course the transport type will default to GNUTLS_TRANSPORT_TYPE_STREAM, but it can be changed after gnutls_init() but not after the first gnutls_handshake(). Apart from this the only necessary addition to the API that I forsee is a function call to deal with the retransmit timers necessary for DTLS. > > Also, I will be working on this in spare time, help is appreciated. > > I'll cheer you on, and will try to assist with testing etc, but will > probably have little time to code. The last might change, I have > mentioned DTLS support as a useful project to some people. Great! -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- 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 Sat May 7 17:30:25 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 07 May 2005 17:30:25 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: <20050507151822.GN2945@sliepen.eu.org> (Guus Sliepen's message of "Sat, 7 May 2005 17:18:22 +0200") References: <20050507134545.GJ2945@sliepen.eu.org> <20050507151822.GN2945@sliepen.eu.org> Message-ID: Guus Sliepen writes: > Sounds like a good idea. But of course I have already looked at the > GNUTLS source and I already have a suggestion for an API. Since the > difference between TLS and DTLS is the transport layer (TCP vs. UDP), I > would suggest adding the following enum and function calls: > > typedef enum gnutls_transport_type { > GNUTLS_TRANSPORT_TYPE_STREAM = 1, > GNUTLS_TRANSPORT_TYPE_DATAGRAM, > } gnutls_transport_type; > > void gnutls_transport_set_type(gnutls_session session, gnutls_transport_type type); > gnutls_transport_type gnutls_transport_get_type(gnutls_session session); > > Of course the transport type will default to > GNUTLS_TRANSPORT_TYPE_STREAM, but it can be changed after gnutls_init() > but not after the first gnutls_handshake(). Apart from this the only > necessary addition to the API that I forsee is a function call to deal > with the retransmit timers necessary for DTLS. Very simple and non-obtrusive, so it sounds good to me. Perhaps a 'gnutls_init_datagram' is useful, as a shortcut to create a DTLS connection. Regards, Simon From guus at sliepen.eu.org Mon May 9 12:06:48 2005 From: guus at sliepen.eu.org (Guus Sliepen) Date: Mon, 9 May 2005 12:06:48 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: References: <20050507134545.GJ2945@sliepen.eu.org> Message-ID: <20050509100648.GJ2949@sliepen.eu.org> On Sat, May 07, 2005 at 04:54:12PM +0200, Simon Josefsson wrote: > 1. Implement it grossly, possibly modifying existing functions, until > it interoperate with OpenSSL. > > 2. Building on what you've learned doing 1, write up a suggestion of > what you think a clean API would be and post it here. Try not to > think about how you would actually implement that API, but rather > how it would be used. Perhaps some discussion at this point. > > 3. Change the code to implement the clean API. It is not hard to make the API clean; the DTLS protocol is such that it works almost exactly like TLS for the application; no need to change the semantics of gnutls_handshake() and gnutls_record_send/recv(). Implementing it will be a bit harder than I thought at first sight. The problem is that internally, GNUTLS has no clear seperation between the layers involved in TLS, and it is heavily biased towards TCP. This combination is a disaster for me :). I see two ways to proceed. 1) Create copies of all handshake, record and transport layer functions and modify them to do DTLS instead of TLS. This means lots of code duplication, but at least it won't mess with the existing code. 2) "Fix" the current code by (re)introducing a clean separation between the handshake, record and transport layer, and remove the bias towards TCP. This means adding DTLS on top of it will be painless and there won't be lots of code duplication. However it will touch a lot of existing code. I strongly favour the second way, but if that means the chances of having it merged are nihil, I'll go with the first way. -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- 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 May 9 12:43:03 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 09 May 2005 12:43:03 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: <20050509100648.GJ2949@sliepen.eu.org> (Guus Sliepen's message of "Mon, 9 May 2005 12:06:48 +0200") References: <20050507134545.GJ2945@sliepen.eu.org> <20050509100648.GJ2949@sliepen.eu.org> Message-ID: Guus Sliepen writes: > Implementing it will be a bit harder than I thought at first sight. The > problem is that internally, GNUTLS has no clear seperation between the > layers involved in TLS, and it is heavily biased towards TCP. This > combination is a disaster for me :). I see two ways to proceed. Ouch. > 1) Create copies of all handshake, record and transport layer functions > and modify them to do DTLS instead of TLS. This means lots of code > duplication, but at least it won't mess with the existing code. > > 2) "Fix" the current code by (re)introducing a clean separation between > the handshake, record and transport layer, and remove the bias towards > TCP. This means adding DTLS on top of it will be painless and there > won't be lots of code duplication. However it will touch a lot of > existing code. > > I strongly favour the second way, but if that means the chances of > having it merged are nihil, I'll go with the first way. I would not want to have the 1) situation. Duplicated code is painful to maintain. I don't know how deep the modifications 2) would be, but I'd vote for going that route too, even if it mean more work initially. Perhaps Nikos has more input. /Simon From nmav at gnutls.org Mon May 9 13:31:48 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 May 2005 13:31:48 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: <20050509100648.GJ2949@sliepen.eu.org> References: <20050507134545.GJ2945@sliepen.eu.org> <20050509100648.GJ2949@sliepen.eu.org> Message-ID: <200505091331.49070.nmav@gnutls.org> On Monday 09 May 2005 12:06, Guus Sliepen wrote: > 2) "Fix" the current code by (re)introducing a clean separation between > the handshake, record and transport layer, and remove the bias towards > TCP. This means adding DTLS on top of it will be painless and there > won't be lots of code duplication. However it will touch a lot of > existing code. Hello, I think this is the best approach to use. But what kind of separation between the layers do you need? In what sense they are not separated? -- Nikos Mavrogiannopoulos From guus at sliepen.eu.org Mon May 9 14:38:44 2005 From: guus at sliepen.eu.org (Guus Sliepen) Date: Mon, 9 May 2005 14:38:44 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: <200505091331.49070.nmav@gnutls.org> References: <20050507134545.GJ2945@sliepen.eu.org> <20050509100648.GJ2949@sliepen.eu.org> <200505091331.49070.nmav@gnutls.org> Message-ID: <20050509123844.GK2949@sliepen.eu.org> On Mon, May 09, 2005 at 01:31:48PM +0200, Nikos Mavrogiannopoulos wrote: > > 2) "Fix" the current code by (re)introducing a clean separation between > > the handshake, record and transport layer, and remove the bias towards > > TCP. This means adding DTLS on top of it will be painless and there > > won't be lots of code duplication. However it will touch a lot of > > existing code. > Hello, > I think this is the best approach to use. But what kind of separation between > the layers do you need? In what sense they are not separated? As I see it there are three layers: transport, record and handshake. The transport layers deals with sending and receiving raw data. The record layer reads and writes records from/to the transport layer, and it handles encryption and compression. The handshake layer reads and writes handshake records and sets the encryption and compression parameters of the record layer. As far as I have seen, the transport layer is in gnutls_buffer.c, the record layer in gnutls_record.c and the handshake layer in gnutls_handshake.c. However in gnutls_buffer.c I see the function _gnutls_handshake_io_send_int() which seems to suggest that the transport layer receives knowledge about what kind of record types it has to deal with. In gnutls_record.c the function _gnutls_recv_int(), which I assume tries to read a record, looks at the record type and depending on the type does different things with it. There are more examples of functions which do not stay within their own layer. What I would like is this: - A transport layer which provides read() and write() functionality, nothing more, nothing less. That means no buffering at all. - A record layer which can read and write records. It buffers read()s and write()s from the transport layer if necessary (ie, it buffers until it has at least one whole record). This layer also encrypts and compresses data. It does not look at the record type field at all. - A handshake layer which can read and write handshake messages. It buffers records it reads and writes from the record layer if necessary (ie, buffers until it has at least one whole handshake message). - The top layer which does the whole handshake protocol and handles application_data records. The handshake protocol is done by gnutls_handshake(), the application data is done by gnutls_record_send/recv(). As an example, when gnutls_handshake() is called and it is in a state where it should receive a handshake message from the other end, it would call _gnutls_handshake_recv(), which in turn would do a _gnutls_record_recv() which would do a _gnutls_transport_recv(). If at any point not enough data is read to return a whole record or handshake message, GNUTLS_E_AGAIN is returned. If there is enough data for a whole handshake message, then _gnutls_handshake_recv() will return without an error and the gnutls_handshake() function can process the handshake message. -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Mon May 9 15:01:48 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 May 2005 15:01:48 +0200 Subject: [gnutls-dev] Re: Intent to implement DTLS In-Reply-To: <20050509123844.GK2949@sliepen.eu.org> References: <20050507134545.GJ2945@sliepen.eu.org> <200505091331.49070.nmav@gnutls.org> <20050509123844.GK2949@sliepen.eu.org> Message-ID: <200505091501.48526.nmav@gnutls.org> On Monday 09 May 2005 14:38, Guus Sliepen wrote: > As I see it there are three layers: transport, record and handshake. The > transport layers deals with sending and receiving raw data. The record > layer reads and writes records from/to the transport layer, and it handles > encryption and compression. The handshake layer reads and writes > handshake records and sets the encryption and compression parameters of > the record layer. As far as I have seen, the transport layer is in > gnutls_buffer.c, the record layer in gnutls_record.c and the handshake > layer in gnutls_handshake.c. However in gnutls_buffer.c I see the > function _gnutls_handshake_io_send_int() which seems to suggest that the > transport layer receives knowledge about what kind of record types it No this is not really the case. The gnutls_buffers.c is more than the transport functions. The gnutls_io_handshake stuff are wrappers over record_send/recv_int(). There is a case where the record protocol has to know the handshake packet it expects. This is the case for the client hello, thus it can parse an SSL 2.0 packet. In all other cases this information is not used/needed. > has to deal with. In gnutls_record.c the function _gnutls_recv_int(), > which I assume tries to read a record, looks at the record type and > depending on the type does different things with it. There are more > examples of functions which do not stay within their own layer. No gnutls_recv_int() does not really care about the data it receives. > - A transport layer which provides read() and write() functionality, > nothing more, nothing less. That means no buffering at all. These are provided by the user in session->internals._gnutls_pull_func or the default recv()/send() are used. > - A record layer which can read and write records. It buffers read()s > and write()s from the transport layer if necessary (ie, it buffers > until it has at least one whole record). This layer also encrypts and > compresses data. It does not look at the record type field at all. This is not what record_recv() provides? > - A handshake layer which can read and write handshake messages. It > buffers records it reads and writes from the record layer if necessary > (ie, buffers until it has at least one whole handshake message). I think that you seek for the io_handshake() functions... > - The top layer which does the whole handshake protocol and handles > application_data records. The handshake protocol is done by > gnutls_handshake(), the application data is done by > gnutls_record_send/recv(). This one will be probably much different than the current ones, thus they functions in gnutls_handshake() might not fit. Anyway check handshake_recv(), handshake_recv_header() etc. > As an example, when gnutls_handshake() is called and it is in a state > where it should receive a handshake message from the other end, it would > call _gnutls_handshake_recv(), which in turn would do a handshake_io_recv_int() and in turn gnutls_record_recv_int() > _gnutls_record_recv() which would do a _gnutls_transport_recv(). If at > any point not enough data is read to return a whole record or handshake > message, GNUTLS_E_AGAIN is returned. If there is enough data for a whole > handshake message, then _gnutls_handshake_recv() will return without an > error and the gnutls_handshake() function can process the handshake > message. -- Nikos Mavrogiannopoulos From alangley at gmail.com Wed May 18 18:11:41 2005 From: alangley at gmail.com (Adam Langley) Date: Wed, 18 May 2005 17:11:41 +0100 Subject: [gnutls-dev] EDH_RSA Support Message-ID: <396556a2050518091114636e5d@mail.gmail.com> Can anyone tell me what the difference between EDH and DHE is, and how much work it might be to implement it in gnutls? It isn't mentioned in any of the TLS RFCs that I can find. I need EDH_RSA support for a project and it might be easier to add it rather than try to use OpenSSL. Cheers AGL -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From nmav at gnutls.org Wed May 18 21:05:49 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 May 2005 21:05:49 +0200 Subject: [gnutls-dev] EDH_RSA Support In-Reply-To: <396556a2050518091114636e5d@mail.gmail.com> References: <396556a2050518091114636e5d@mail.gmail.com> Message-ID: <200505182105.50632.nmav@gnutls.org> On Wednesday 18 May 2005 18:11, Adam Langley wrote: > Can anyone tell me what the difference between EDH and DHE is, and how > much work it might be to implement it in gnutls? It isn't mentioned in > any of the TLS RFCs that I can find. It's the same thing. Both of them stand for Ephemeral diffie hellman. They are discussed in the TLS 1.0 RFC (2246). -- Nikos Mavrogiannopoulos From jas at extundo.com Sat May 28 12:15:58 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 28 May 2005 12:15:58 +0200 Subject: [gnutls-dev] GnuTLS 1.2.4 Message-ID: We are pleased to announce the availability of GnuTLS 1.2.4! Noteworthy changes since version 1.2.3: - Corrected some bugs that could affect 64 bit systems. - Some corrections in the header files to include the prototype of memmem properly (affected 64 bit systems). Report and patch by Yoann Vandoorselaere . - Introduced the --fix-key option to certtool, which can be used to regenerate the (optional) parameters in a private key. It should be used together with --key-info. - Corrected a bug in certificate chain verification that could lead to marking a trusted chain as non trusted, if the last certificate in the chain was a self signed one. - Gnulib portability files were updated. - License were updated to reflect new FSF address. The NEWS file fail to mention it, but there are no API/ABI changes between 1.2.3 and 1.2.4. 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.4.tar.bz2 (2.4MB) ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.4.tar.bz2 (2.4MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.2.4.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.4.tar.bz2.sig Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the MD5/SHA1 checksums: 57f97e1544f19e986ea20d5180b013fd gnutls-1.2.4.tar.bz2 ae0d1c36c62ca558faaf4282b0f18bfd gnutls-1.2.4.tar.bz2.sig f54c9fe5aa11b3e4cb2109d29cf38d98d11c72dc gnutls-1.2.4.tar.bz2 9240d8c1dfac96027f9d528132e4402d366e4be8 gnutls-1.2.4.tar.bz2.sig Enjoy, Nikos and Simon From alangley at gmail.com Sat May 28 20:04:46 2005 From: alangley at gmail.com (Adam Langley) Date: Sat, 28 May 2005 19:04:46 +0100 Subject: [gnutls-dev] [PATCH 1/1] crt_get_issuer_dn and friends request the wrong sized buffer Message-ID: <396556a205052811045a5e096d@mail.gmail.com> With GnuTLS 1.2.[34] calling gnutls_x509_crt_get_issuer_dn with a NULL parameter will cause the function to request (by filling out the int *size argument) a buffer which is one byte too small. Calling the function again with a buffer of the requested size will fail. When a larger buffer is provided, the returned size is one byte too large as it includes the NUL terminator which seems to be counter to the convention in GnuTLS. AGL -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-1.2.4-fix-dn-requested-size.patch Type: application/octet-stream Size: 513 bytes Desc: not available URL: From nmav at gnutls.org Sat May 28 21:10:03 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 May 2005 21:10:03 +0200 Subject: [gnutls-dev] [PATCH 1/1] crt_get_issuer_dn and friends request the wrong sized buffer In-Reply-To: <396556a205052811045a5e096d@mail.gmail.com> References: <396556a205052811045a5e096d@mail.gmail.com> Message-ID: <200505282110.03415.nmav@gnutls.org> On Saturday 28 May 2005 20:04, Adam Langley wrote: > With GnuTLS 1.2.[34] calling gnutls_x509_crt_get_issuer_dn with a NULL > parameter will cause the function to request (by filling out the int > *size argument) a buffer which is one byte too small. Calling the > function again with a buffer of the requested size will fail. > When a larger buffer is provided, the returned size is one byte too > large as it includes the NUL terminator which seems to be counter to > the convention in GnuTLS. Indeed, it was the other way round. I corrected it in the cvs, thank you. -- Nikos Mavrogiannopoulos