From sdecugis at nict.go.jp Fri Aug 1 07:26:17 2008 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Fri, 01 Aug 2008 14:26:17 +0900 Subject: TLS over SCTP Message-ID: <48929E79.7000702@nict.go.jp> Hello, [sorry to reposting on the same topic as in help-gnutls, but the content is slightly different] I am wanting to use the gnutls library to achieve TLS over a multi-stream SCTP connection, as detailed in RFC 3436. Unfortunately it seems that the current support in gnutls for providing custom transport functions is not sufficient to achieve this. For people who are not familiar with SCTP, I'll now give a short introduction on this protocol. SCTP is a reliable transport protocol (as TCP), message-oriented (as UDP), which provides the capability to create multiple streams inside one connection. The messages in one stream are ordered, but each stream is independent from the others. This allows (in some applications) to avoid head-of-the-line blocking problem that occurs in TCP when some data is lost during a transmission. SCTP also provides other interesting features such as support for multihoming. On an API point of view, one socket object is created, and the number of streams is negotiated between the endpoints. sendmsg() function is used to send a message on this socket, with some options available to specify the stream on which the message is sent. recvmsg() function receives a message from any stream, and the message contains the stream id on which it was received in its meta-data. RFC3436 specifies how TLS should be used to secure SCTP connections. In a row, independent pairs of streams (bi-directional) are used as independent TLS channels. For example, if an SCTP connection between two peers negotiates 4 outbound streams and 6 inbound streams, then 4 TLS handshakes will occur on streams 0 to 3, and the two remaining inbound streams are not protected by TLS. In its current state, the gnutls library misses the ability to have several gnutls_session_t associated to a single connection object. It is a problem on message reception, because we can determine the session to which a message belongs only *after* we receive it. This demultiplexing operation is not currently allowed in gnutls, AFAIU. I am considering to implement such support in the gnutls library, either as a new session object ("gnutls_session_multistream_t") or as an extension of the current session object (adding new fields to it). Basically, the differences are: -> ability to define a number of independent communication channels (bi-directional streams) in the object. -> storage for this same number of sessions states (the current gnutls_session_t) -> different prototype of the push and pull transport callbacks, that take an additional parameter (the stream id on which to send / on which the message was received) The functions such as gnutls_handshake would also need a new version, either as gnutls_handshake_multistream or merged in the same function, to provide the ability to negociate the TLS sessions on all streams. I have no knowledge of the gnutls code so far, so I'd like to hear comments from the experienced developpers on this topic, before I start. More specifically, would such feature be considered for inclusion in a future release when it is stable? Would you give me advices and hints for implementing this cleanly? Thank you in advance, Sebastien. From nmav at gnutls.org Sat Aug 2 10:31:34 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Aug 2008 11:31:34 +0300 Subject: TLS over SCTP In-Reply-To: <48929E79.7000702@nict.go.jp> References: <48929E79.7000702@nict.go.jp> Message-ID: <48941B66.3050506@gnutls.org> Sebastien Decugis wrote: > In its current state, the gnutls library misses the ability to have > several gnutls_session_t associated to a single connection object. It is I depends on how you define the object. You can associate each session with a transport pointer, which can be anything you like and will be passed to push/pull functions and also a custom pointer which can be anything you like and is available to you only. > a problem on message reception, because we can determine the session to > which a message belongs only *after* we receive it. This demultiplexing > operation is not currently allowed in gnutls, AFAIU. A layer that would demultiplex the streams before should be needed. That's correct. > I am considering to implement such support in the gnutls library, either > as a new session object ("gnutls_session_multistream_t") or as an > extension of the current session object (adding new fields to it). > Basically, the differences are: > -> ability to define a number of independent communication channels > (bi-directional streams) in the object. > -> storage for this same number of sessions states (the current > gnutls_session_t) > -> different prototype of the push and pull transport callbacks, that > take an additional parameter (the stream id on which to send / on which > the message was received) Can't this be achieved by having a layer of demultiplexing before gnutls that will use separate pull/push functions and a custom transport pointer? That we could include in gnutls as helper functions for SCTP. regards, Nikos From sdecugis at nict.go.jp Mon Aug 4 03:16:16 2008 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Mon, 04 Aug 2008 10:16:16 +0900 Subject: [SPAM] Re: TLS over SCTP In-Reply-To: <48941B66.3050506@gnutls.org> References: <48929E79.7000702@nict.go.jp> <48941B66.3050506@gnutls.org> Message-ID: <48965860.2090208@nict.go.jp> Hello Nikos, Thank you for your answer. Please see my comments below. > A layer that would demultiplex the streams before should be needed. > That's correct. > Ok >> I am considering to implement such support in the gnutls library, either >> as a new session object ("gnutls_session_multistream_t") or as an >> extension of the current session object (adding new fields to it). >> Basically, the differences are: >> -> ability to define a number of independent communication channels >> (bi-directional streams) in the object. >> -> storage for this same number of sessions states (the current >> gnutls_session_t) >> -> different prototype of the push and pull transport callbacks, that >> take an additional parameter (the stream id on which to send / on which >> the message was received) >> > > Can't this be achieved by having a layer of demultiplexing before gnutls > that will use separate pull/push functions and a custom transport > pointer? That we could include in gnutls as helper functions for SCTP. > I understand your point. My first attempt was to come up with such intermediate layer that would provide these two functions: send_to_stream(message, length, streamid); recv_from_stream(message, length, streamid); It would be quite straight-forward to use the user pointer from the session, or the connection object, to retrieve the stream id of a session. Unfortunately, whereas the send function can be written quite easily, I cannot figure out how to write the recv function. Using the SCTP socket API [1], we do not specify the stream on which we are listening for a new message. Instead, we are listening for the next message from any stream, and when we receive it we can also get its stream id. That is a fundamental difference between a multistream SCTP association, and many separated connections. That is the reason for my previous proposal. An alternate approach would be to be able to change the current TLS session from inside the transport handler, but I don't think this is a good approach, if possible at all. What do you think, is there another possibility to solve the problem that I cannot see? Thank you in advance, Best regards, Sebastien. [1] http://www3.tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-17 From nmav at gnutls.org Sat Aug 9 11:37:20 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 09 Aug 2008 12:37:20 +0300 Subject: [SPAM] Re: TLS over SCTP In-Reply-To: <48965860.2090208@nict.go.jp> References: <48929E79.7000702@nict.go.jp> <48941B66.3050506@gnutls.org> <48965860.2090208@nict.go.jp> Message-ID: <489D6550.6040707@gnutls.org> Sebastien Decugis wrote: > I understand your point. My first attempt was to come up with such > intermediate layer that would provide these two functions: > send_to_stream(message, length, streamid); > recv_from_stream(message, length, streamid); > It would be quite straight-forward to use the user pointer from the > session, or the connection object, to retrieve the stream id of a session. > > Unfortunately, whereas the send function can be written quite easily, I > cannot figure out how to write the recv function. Using the SCTP socket > API [1], we do not specify the stream on which we are listening for a > new message. Instead, we are listening for the next message from any > stream, and when we receive it we can also get its stream id. That is a > fundamental difference between a multistream SCTP association, and many > separated connections. Hello Sebastien, Actually I think the recv_from_stream() is doable. You should wait for any message, then if it is not for this stream save it for later processing. You only need to cache messages and read from the cache if they exist. It is easy to describe but might be tricky implementing it. The gnutls_recv function behave similarly. You can read from different "streams" such as application data, handshake data etc. Only they are read they are cached for later processing by someone who is interested. regards, Nikos From sdecugis at nict.go.jp Mon Aug 11 02:46:36 2008 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Mon, 11 Aug 2008 09:46:36 +0900 Subject: [SPAM] Re: TLS over SCTP In-Reply-To: <489D6550.6040707@gnutls.org> References: <48929E79.7000702@nict.go.jp> <48941B66.3050506@gnutls.org> <48965860.2090208@nict.go.jp> <489D6550.6040707@gnutls.org> Message-ID: <489F8BEC.60008@nict.go.jp> Hi Nikkos, Thank you for this feedback! It actualy gives me new insights I did not think about. You are right, I may be able to actually receive data in a separate thread, and then use buffer queues and conditional variables to receive "inside" the gnutls wrappers... I will give this a try, and send the implementation to the list in case it may be useful to other people. Thanks again! Best regards, Sebastien. Nikos Mavrogiannopoulos a ?crit : > Sebastien Decugis wrote: > > >> I understand your point. My first attempt was to come up with such >> intermediate layer that would provide these two functions: >> send_to_stream(message, length, streamid); >> recv_from_stream(message, length, streamid); >> It would be quite straight-forward to use the user pointer from the >> session, or the connection object, to retrieve the stream id of a session. >> >> Unfortunately, whereas the send function can be written quite easily, I >> cannot figure out how to write the recv function. Using the SCTP socket >> API [1], we do not specify the stream on which we are listening for a >> new message. Instead, we are listening for the next message from any >> stream, and when we receive it we can also get its stream id. That is a >> fundamental difference between a multistream SCTP association, and many >> separated connections. >> > > Hello Sebastien, > Actually I think the recv_from_stream() is doable. You should wait for > any message, then if it is not for this stream save it for later > processing. You only need to cache messages and read from the cache if > they exist. It is easy to describe but might be tricky implementing it. > > The gnutls_recv function behave similarly. You can read from different > "streams" such as application data, handshake data etc. Only they are > read they are cached for later processing by someone who is interested. > > regards, > Nikos > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From dkg-debian.org at fifthhorseman.net Thu Aug 14 04:15:37 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Aug 2008 22:15:37 -0400 Subject: more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K") Message-ID: <87zlng2vg6.fsf@squeak.fifthhorseman.net> After reading Nikos' assessment of the state of OpenCDK in handling enciphered subpackets, i've backed off from my original goal of actually decrypting secret keys. I'd like GnuTLS to be able to do that at some point, but i don't understand OpenCDK's filter model well enough yet to actually implement the cipher needed to decrypt locked secret keys. However, there is a reason to prefer to be able to identify and parse locked secret keys, even if we can't unlock them yet. In particular, RFC4880 allows for some secret subkeys (or the primary key) in a keyset to be unlocked while others are locked. For example, you might want to provide a TLS service with the Authentication subkey for the host's key, but not provide it with the unlocked primary key itself. Presented with a keyset like this (locked primary key, unlocked subkey), and asked to use the subkey, GnuTLS will currently fail to operate despite having access to all the information needed. My earlier read_s2k implementation [0] would have allowed GnuTLS to handle this case properly. gpg itself is capable of generating such a keyset, using the flag: --export-secret-subkeys But it "locks" the primary key by removing the secret MPIs entirely for the primary key packet, using an experimental S2K identifier (101), which GPG classifies as "gnu-dummy". gpg(1) says of --export-secret-subkeys: the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key. However, it isn't difficult to actually import such a key (and to ensure that such a packet conforms to the flavor emitted by GPG). The attached patch is an update to my earlier read_s2k implementation and is capable of interpreting the gnu-dummy S2K extension. As a GNU project, this seems like a worthwhile step to me. Is there any objection to including this GNU extension in the event that a 2.4.2 release is made? I'd be happy to implement the same thing for the 2.5.x branch as well, if there are no objections. As always, i welcome feedback! --dkg ? [0] http://lists.gnu.org/archive/html/gnutls-devel/2008-06/msg00092.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 19_functional_s2k_with_GNU_dummy.diff Type: text/x-diff Size: 3930 bytes Desc: functional s2k against GnuTLS 2.4.1 (including interpretation of gnu-dummy S2K extension) URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From simon at josefsson.org Thu Aug 14 10:19:01 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 14 Aug 2008 10:19:01 +0200 Subject: more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K") In-Reply-To: <87zlng2vg6.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 13 Aug 2008 22:15:37 -0400") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> Message-ID: <873al8j9fu.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > After reading Nikos' assessment of the state of OpenCDK in handling > enciphered subpackets, i've backed off from my original goal of > actually decrypting secret keys. I'd like GnuTLS to be able to do > that at some point, but i don't understand OpenCDK's filter model well > enough yet to actually implement the cipher needed to decrypt locked > secret keys. Ouch. FWIW, I think your goal is fine and it should be supported eventually. > For example, you might want to provide a TLS service with the > Authentication subkey for the host's key, but not provide it with the > unlocked primary key itself. Presented with a keyset like this > (locked primary key, unlocked subkey), and asked to use the subkey, > GnuTLS will currently fail to operate despite having access to all the > information needed. Good example, I agree. > However, it isn't difficult to actually import such a key (and to > ensure that such a packet conforms to the flavor emitted by GPG). The > attached patch is an update to my earlier read_s2k implementation and > is capable of interpreting the gnu-dummy S2K extension. As a GNU > project, this seems like a worthwhile step to me. > > Is there any objection to including this GNU extension in the event > that a 2.4.2 release is made? > > I'd be happy to implement the same thing for the 2.5.x branch as well, > if there are no objections. > > As always, i welcome feedback! I'm not sure this can go into 2.4.x, it seems like a somewhat large addition, although I'll let Nikos comment as well. Maybe it could go in. However, this certainly seems appropriate for 2.5. Please create a patch for it, and I'll apply it. Btw, I want to get the 2.6.x release process started, I think we have enough new features in 2.5.x to be ready for a new stable release. So maybe it isn't that important to get into 2.4.x if 2.6.x is release relatively soon. /Simon From simon at josefsson.org Thu Aug 14 10:37:44 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 14 Aug 2008 10:37:44 +0200 Subject: GnuTLS 2.5.3 Message-ID: <87tzdohu07.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.3.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.3.tar.bz2 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. See http://josefsson.org/ for more details. /Simon * Version 2.5.3 (released 2008-08-14) ** libgnutls: New API to set the public parameters in a certificate request ** from a private key. The function is gnutls_x509_crq_set_key_rsa_raw. ** libgnutls: New API to set a callback to extract TLS Finished data. The function to register is gnutls_session_set_finished_function and it takes a callback of the gnutls_finished_callback_func type. ** libgnutls: Drop final comma after GNUTLS_CRT_PRINT_UNSIGNED_FULL in enum. Reported in . ** libgnutls: Fix namespace problem with TLS_MASTER_SIZE and TLS_RANDOM_SIZE. The new names are GNUTLS_MASTER_SIZE and GNUTLS_RANDOM_SIZE. The old names are mapped to the new names in compat.h. These mappings will likely be removed more quickly than other mappings in that file due to the namespace violation. ** libgnutlsxx: Make it build when SRP is disabled. ** doc: Add doxygen files in doc/doxygen/. ** API and ABI modifications: gnutls_x509_crq_set_key_rsa_raw: ADDED gnutls_session_set_finished_function: ADDED gnutls_finished_callback_func: ADDED GNUTLS_MASTER_SIZE: ADDED GNUTLS_RANDOM_SIZE: ADDED TLS_MASTER_SIZE: DEPRECATED TLS_RANDOM_SIZE: DEPRECATED -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From dkg-debian.org at fifthhorseman.net Fri Aug 15 02:59:41 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 Aug 2008 20:59:41 -0400 Subject: more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K") In-Reply-To: <873al8j9fu.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu\, 14 Aug 2008 10\:19\:01 +0200") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> Message-ID: <87r68rhz42.fsf@squeak.fifthhorseman.net> On Thu 2008-08-14 04:19:01 -0400, Simon Josefsson wrote: > Ouch. I know! One day i'll be a better programmer, i hope :/ > FWIW, I think your goal is fine and it should be supported > eventually. Thanks, that's good to hear. > I'm not sure this can go into 2.4.x, it seems like a somewhat large > addition, although I'll let Nikos comment as well. Maybe it could > go in. Hrm. I don't think it's that big of a change (and it only affects a people using GnuTLS for OpenPGP), but of course i'll defer to you and Nikos. > However, this certainly seems appropriate for 2.5. Please create a > patch for it, and I'll apply it. The patch to enable parsing (but not decrypting) of locked secret keys (including the "gnu-dummy" S2K option) against GnuTLS 2.5.3 is attached, and seems to work for me. Please let me know if you have any problems or concerns with it. > Btw, I want to get the 2.6.x release process started, I think we > have enough new features in 2.5.x to be ready for a new stable > release. So maybe it isn't that important to get into 2.4.x if > 2.6.x is release relatively soon. I was hoping for 2.4.x because i'd love to see support for this in debian lenny, but we likely won't be able to get a new version of 2.4.x into lenny at this point in debian's release cycle anyway. Regardless of its status in 2.4.x, i'd certainly like to see this behavior in 2.6. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: 20_functional_s2k_with_GNU_dummy_against_2.5.diff Type: text/x-diff Size: 3089 bytes Desc: patch against 2.5.3, implementing read_s2k() and enabling support for gnu-dummy S2K extension URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sdecugis at nict.go.jp Fri Aug 15 10:45:44 2008 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Fri, 15 Aug 2008 17:45:44 +0900 Subject: TLS over multi-stream SCTP, a wrapper... In-Reply-To: <489F8BEC.60008@nict.go.jp> References: <48929E79.7000702@nict.go.jp> <48941B66.3050506@gnutls.org> <48965860.2090208@nict.go.jp> <489D6550.6040707@gnutls.org> <489F8BEC.60008@nict.go.jp> Message-ID: <48A54238.6060804@nict.go.jp> Hello, Following a design idea from Nikos Mavrogiannopoulos (thanks again), I have written a wrapper around the GNU TLS library to achieve TLS protection over a multi-stream SCTP connection. The basic idea is to replace the transport functions used by gnutls for transport, and use an object to aggregate all the sessions and other data. One thread is receiving data from the socket, and queueing this data in per-stream FIFO lists (demultiplxing step). Then the gnutls "pull" function will pick data from the appropriate FIFO list, and actually decrypt this data. This is done by a separate thread (one per stream). The decrypted data is queued in another FIFO list, from which the user can retrieve the received data. See the header file and the comments at the top of the files for more information. I know this wrapper is not very performant at session initiation because it does a full handshake on each pair of stream, and does not parallelize this process. This can be easily improved, but makes it more complex to debug. I have compiled and tested this wrapper in my Linux environment ( libgnutls distribution release libgnutls13 2.0.4-1ubuntu2.1 ) and it seems to work properly. There will propably need some minor changes (gnutls_kx_set_priority -> gnutls_set_priority for example) to adapt it to the latest gnutls releases. A test program is embedded withing the source code. To compile it, one has to define the STANDALONE_WRAPPER symbol. For example, to compile the file (under Linux Ubuntu) I use (content of the COMPIL file): gcc -o sctp_tls -DSTANDALONE_WRAPPER -lgnutls -pthread gnutls_sctp_wrapper.c Then simply run the ./sctp_tls program to create a SCTP socket on localhost:4433 and exchange TLS-protected data over it. Please feel free to contact me if you have any question with regards to this peace of code. As a final note, this wrapper was initially written as part of an open-source Diameter daemon implementation, called "waaad". See [1] if you are interested in this implementation, or want to find a more recent version of the wrapper source code. I hope this code will be useful to other people as well. If you make improvements to this code and can share it under the same licence, please send me a note / patch. Best regards, Sebastien Decugis. [1] http://aaa.koganei.wide.ad.jp/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls_sctp_wrapper.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls_sctp_wrapper.h URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: COMPIL URL: From nmav at gnutls.org Sun Aug 17 00:37:08 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 17 Aug 2008 01:37:08 +0300 Subject: TLS over multi-stream SCTP, a wrapper... In-Reply-To: <48A54238.6060804@nict.go.jp> References: <48929E79.7000702@nict.go.jp> <48941B66.3050506@gnutls.org> <48965860.2090208@nict.go.jp> <489D6550.6040707@gnutls.org> <489F8BEC.60008@nict.go.jp> <48A54238.6060804@nict.go.jp> Message-ID: <48A75694.5040005@gnutls.org> Sebastien Decugis wrote: > Hello, > > Following a design idea from Nikos Mavrogiannopoulos (thanks again), I > have written a wrapper around the GNU TLS library to achieve TLS > protection over a multi-stream SCTP connection. > > The basic idea is to replace the transport functions used by gnutls for > transport, and use an object to aggregate all the sessions and other > data. One thread is receiving data from the socket, and queueing this > data in per-stream FIFO lists (demultiplxing step). Then the gnutls > "pull" function will pick data from the appropriate FIFO list, and > actually decrypt this data. This is done by a separate thread (one per > stream). The decrypted data is queued in another FIFO list, from which > the user can retrieve the received data. See the header file and the > comments at the top of the files for more information. > > I know this wrapper is not very performant at session initiation because > it does a full handshake on each pair of stream, and does not > parallelize this process. This can be easily improved, but makes it more > complex to debug. A quick improvement would be to use session resuming after the 1st session is established. Thus the handshake afterwards would be much faster. regards, Nikos From sdecugis at nict.go.jp Mon Aug 18 03:42:07 2008 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Mon, 18 Aug 2008 10:42:07 +0900 Subject: TLS over multi-stream SCTP, a wrapper... In-Reply-To: <48A75694.5040005@gnutls.org> References: <48929E79.7000702@nict.go.jp> <48941B66.3050506@gnutls.org> <48965860.2090208@nict.go.jp> <489D6550.6040707@gnutls.org> <489F8BEC.60008@nict.go.jp> <48A54238.6060804@nict.go.jp> <48A75694.5040005@gnutls.org> Message-ID: <48A8D36F.8090003@nict.go.jp> > A quick improvement would be to use session resuming after the 1st > session is established. Thus the handshake afterwards would be much faster. > Thank you for this tip. I will do this in my project. If people are interested that I send the updated tls_sctp_handshake function, please let me know. Best regards, Sebastien From joe at manyfish.co.uk Mon Aug 18 10:52:20 2008 From: joe at manyfish.co.uk (Joe Orton) Date: Mon, 18 Aug 2008 09:52:20 +0100 Subject: Problem with Subversion + Neon + GnuTLS 2.5 In-Reply-To: <200808172213.36767.Arfrever.FTA@gmail.com> References: <200808172213.36767.Arfrever.FTA@gmail.com> Message-ID: <20080818085220.GA3136@manyfish.co.uk> [resent with the correct address for gnutls-devel] On Sun, Aug 17, 2008 at 10:13:36PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > I have Neon configured with the --with-ssl=gnutls option. I use > Neon trunk r1531 and Subversion trunk r32513. I recently upgraded > GnuTLS from 2.4.1 to 2.5.3 and now when I try to use Subversion > (which uses Neon) with https:// protocol I get this error: > > Ohhhh jeeee: operation is not possible without initialized secure memory > Aborted > > This error doesn't happen when I use ra_serf instead of ra_neon. > This error also ceases to happen after downgrading GnuTLS to 2.4.1. Sounds like an issue in GnuTLS 2.5, I can't see any new initialization requirements there. CC'ing gnutls-dev for any further clues? Regards, Joe _______________________________________________ neon mailing list neon at lists.manyfish.co.uk http://lists.manyfish.co.uk/mailman/listinfo/neon From simon at josefsson.org Mon Aug 18 13:00:47 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 18 Aug 2008 13:00:47 +0200 Subject: Problem with Subversion + Neon + GnuTLS 2.5 In-Reply-To: <20080818085220.GA3136@manyfish.co.uk> (Joe Orton's message of "Mon, 18 Aug 2008 09:52:20 +0100") References: <200808172213.36767.Arfrever.FTA@gmail.com> <20080818085220.GA3136@manyfish.co.uk> Message-ID: <878wuulh9c.fsf@mocca.josefsson.org> Joe Orton writes: > [resent with the correct address for gnutls-devel] > > On Sun, Aug 17, 2008 at 10:13:36PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: >> I have Neon configured with the --with-ssl=gnutls option. I use >> Neon trunk r1531 and Subversion trunk r32513. I recently upgraded >> GnuTLS from 2.4.1 to 2.5.3 and now when I try to use Subversion >> (which uses Neon) with https:// protocol I get this error: >> >> Ohhhh jeeee: operation is not possible without initialized secure memory >> Aborted >> >> This error doesn't happen when I use ra_serf instead of ra_neon. >> This error also ceases to happen after downgrading GnuTLS to 2.4.1. > > Sounds like an issue in GnuTLS 2.5, I can't see any new initialization > requirements there. CC'ing gnutls-dev for any further clues? I believe this happens if gnutls is initialized after gcrypt has already been initialized to use secure memory (the default). Libgcrypt-applications needs a setuid bit in this case, I think. Normally it is better to disable secure memory usage in libgcrypt and avoid the root-requirement to be able to lock memory pages. GnuTLS does takes care of this in its gnutls_global_init() code, but if libgcrypt has already been initialized, this cannot be modified. I cannot explain why this happens only for 2.5.3 and not 2.4.1 though. Hm. The new crypto code in 2.5.x could explain this. Possibly the initialization order changed. Yes. Try the patch below. Thanks, /Simon diff --git a/lib/gnutls_global.c b/lib/gnutls_global.c index ad0dde6..d94b926 100644 --- a/lib/gnutls_global.c +++ b/lib/gnutls_global.c @@ -250,11 +250,6 @@ gnutls_global_init (void) return GNUTLS_E_INCOMPATIBLE_GCRYPT_LIBRARY; } - /* for gcrypt in order to be able to allocate memory */ - gcry_set_allocation_handler (gnutls_malloc, gnutls_secure_malloc, - _gnutls_is_secure_memory, gnutls_realloc, - gnutls_free); - /* gcry_control (GCRYCTL_DISABLE_INTERNAL_LOCKING, NULL, 0); */ gcry_control (GCRYCTL_INITIALIZATION_FINISHED, NULL, 0); @@ -267,6 +262,11 @@ gnutls_global_init (void) #endif } + /* for gcrypt in order to be able to allocate memory */ + gcry_set_allocation_handler (gnutls_malloc, gnutls_secure_malloc, + _gnutls_is_secure_memory, gnutls_realloc, + gnutls_free); + #ifdef DEBUG gnutls_global_set_log_function (dlog); #endif From dkg-debian.org at fifthhorseman.net Tue Aug 19 00:10:21 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 Aug 2008 18:10:21 -0400 Subject: read_s2k() for GnuTLS 2.5.3 (including "GNU dummy S2K") [was: Re: more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K")] In-Reply-To: <87r68rhz42.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu\, 14 Aug 2008 20\:59\:41 -0400") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> Message-ID: <87r68mc6uq.fsf_-_@squeak.fifthhorseman.net> On Thu 2008-08-14 20:59:41 -0400, Daniel Kahn Gillmor wrote: > The patch to enable parsing (but not decrypting) of locked secret > keys (including the "gnu-dummy" S2K option) against GnuTLS 2.5.3 is > attached, and seems to work for me. Please let me know if you have > any problems or concerns with it. Any thoughts about whether this is something that might be adopted? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From simon at josefsson.org Tue Aug 19 01:07:57 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 19 Aug 2008 01:07:57 +0200 Subject: GnuTLS 2.5.4 Message-ID: <87d4k5exbm.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.4.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.4.tar.bz2 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. See http://josefsson.org/ for more details. /Simon * Version 2.5.4 (released 2008-08-19) ** Fix secure memory initialization of libgcrypt. Reported by Joe Orton in . ** Doc fixes. Reference to NIST SP 800-57 in the manual on key size recommendations. Added 'Since:' tags to new APIs for gtk-doc. ** API and ABI modifications: No changes since last version. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From nmav at gnutls.org Tue Aug 19 12:02:04 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 19 Aug 2008 13:02:04 +0300 Subject: more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K") In-Reply-To: <87r68rhz42.fsf@squeak.fifthhorseman.net> References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> Message-ID: On Fri, Aug 15, 2008 at 3:59 AM, Daniel Kahn Gillmor wrote: Hello! >> I'm not sure this can go into 2.4.x, it seems like a somewhat large >> addition, although I'll let Nikos comment as well. Maybe it could >> go in. > > Hrm. I don't think it's that big of a change (and it only affects a > people using GnuTLS for OpenPGP), but of course i'll defer to you and > Nikos. It's better to add new features to the development branch. Thus we'll have more time for testing and experimentation (also API-wise). >> However, this certainly seems appropriate for 2.5. Please create a >> patch for it, and I'll apply it. > The patch to enable parsing (but not decrypting) of locked secret keys > (including the "gnu-dummy" S2K option) against GnuTLS 2.5.3 is > attached, and seems to work for me. Please let me know if you have > any problems or concerns with it. It looks nice. Expect me to apply it soon (later today or tomorrow). regards, Nikos From dkg-debian.org at fifthhorseman.net Tue Aug 19 16:39:05 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Aug 2008 10:39:05 -0400 Subject: more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K") In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue\, 19 Aug 2008 13\:02\:04 +0300") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> Message-ID: <87k5ed133q.fsf@squeak.fifthhorseman.net> On Tue 2008-08-19 06:02:04 -0400, Nikos Mavrogiannopoulos wrote: > It's better to add new features to the development branch. Thus we'll > have more time for testing and experimentation (also API-wise). I don't think this causes any change in the API; it only changes what's recognizable as a private key. I supposed it's a slight change in the semantics of gnutls_openpgp_privkey_import() in that it can sometimes return encrypted keys whose private material are inaccessible. But i don't see any documentation that suggests that this was an impossibility before anyway. > It looks nice. Expect me to apply it soon (later today or tomorrow). Sweet, thanks! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From arfrever.fta at gmail.com Mon Aug 18 14:40:39 2008 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 18 Aug 2008 14:40:39 +0200 Subject: Problem with Subversion + Neon + GnuTLS 2.5 In-Reply-To: <878wuulh9c.fsf@mocca.josefsson.org> References: <200808172213.36767.Arfrever.FTA@gmail.com> <20080818085220.GA3136@manyfish.co.uk> <878wuulh9c.fsf@mocca.josefsson.org> Message-ID: <200808181440.39675.Arfrever.FTA@gmail.com> 2008-08-18 13:00:47 Simon Josefsson napisa?(a): > Joe Orton writes: > > On Sun, Aug 17, 2008 at 10:13:36PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > >> I have Neon configured with the --with-ssl=gnutls option. I use > >> Neon trunk r1531 and Subversion trunk r32513. I recently upgraded > >> GnuTLS from 2.4.1 to 2.5.3 and now when I try to use Subversion > >> (which uses Neon) with https:// protocol I get this error: > >> > >> Ohhhh jeeee: operation is not possible without initialized secure memory > >> Aborted > >> > >> This error doesn't happen when I use ra_serf instead of ra_neon. > >> This error also ceases to happen after downgrading GnuTLS to 2.4.1. > > > > Sounds like an issue in GnuTLS 2.5, I can't see any new initialization > > requirements there. CC'ing gnutls-dev for any further clues? > > I believe this happens if gnutls is initialized after gcrypt has already > been initialized to use secure memory (the default). > Libgcrypt-applications needs a setuid bit in this case, I think. > Normally it is better to disable secure memory usage in libgcrypt and > avoid the root-requirement to be able to lock memory pages. GnuTLS does > takes care of this in its gnutls_global_init() code, but if libgcrypt > has already been initialized, this cannot be modified. > > I cannot explain why this happens only for 2.5.3 and not 2.4.1 though. > > Hm. The new crypto code in 2.5.x could explain this. Possibly the > initialization order changed. Yes. Try the patch below. > > Thanks, > /Simon > > diff --git a/lib/gnutls_global.c b/lib/gnutls_global.c > index ad0dde6..d94b926 100644 > --- a/lib/gnutls_global.c > +++ b/lib/gnutls_global.c > @@ -250,11 +250,6 @@ gnutls_global_init (void) > return GNUTLS_E_INCOMPATIBLE_GCRYPT_LIBRARY; > } > > - /* for gcrypt in order to be able to allocate memory */ > - gcry_set_allocation_handler (gnutls_malloc, gnutls_secure_malloc, > - _gnutls_is_secure_memory, gnutls_realloc, > - gnutls_free); > - > /* gcry_control (GCRYCTL_DISABLE_INTERNAL_LOCKING, NULL, 0); */ > > gcry_control (GCRYCTL_INITIALIZATION_FINISHED, NULL, 0); > @@ -267,6 +262,11 @@ gnutls_global_init (void) > #endif > } > > + /* for gcrypt in order to be able to allocate memory */ > + gcry_set_allocation_handler (gnutls_malloc, gnutls_secure_malloc, > + _gnutls_is_secure_memory, gnutls_realloc, > + gnutls_free); > + > #ifdef DEBUG > gnutls_global_set_log_function (dlog); > #endif > I'm confirming that this patch fixes this problem. -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From joe at manyfish.co.uk Sun Aug 17 22:29:33 2008 From: joe at manyfish.co.uk (Joe Orton) Date: Sun, 17 Aug 2008 21:29:33 +0100 Subject: Problem with Subversion + Neon + GnuTLS 2.5 In-Reply-To: <200808172213.36767.Arfrever.FTA@gmail.com> References: <200808172213.36767.Arfrever.FTA@gmail.com> Message-ID: <20080817202932.GA22052@manyfish.co.uk> On Sun, Aug 17, 2008 at 10:13:36PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > I have Neon configured with the --with-ssl=gnutls option. I use > Neon trunk r1531 and Subversion trunk r32513. I recently upgraded > GnuTLS from 2.4.1 to 2.5.3 and now when I try to use Subversion > (which uses Neon) with https:// protocol I get this error: > > Ohhhh jeeee: operation is not possible without initialized secure memory > Aborted > > This error doesn't happen when I use ra_serf instead of ra_neon. > This error also ceases to happen after downgrading GnuTLS to 2.4.1. Sounds like an issue in GnuTLS 2.5, I can't see any new initialization requirements there. CC'ing gnutls-dev for any further clues? Regards, Joe From simon at josefsson.org Tue Aug 19 18:08:25 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 19 Aug 2008 18:08:25 +0200 Subject: Problem with Subversion + Neon + GnuTLS 2.5 In-Reply-To: <200808181440.39675.Arfrever.FTA@gmail.com> (Arfrever Frehtes Taifersar Arahesis's message of "Mon, 18 Aug 2008 14:40:39 +0200") References: <200808172213.36767.Arfrever.FTA@gmail.com> <20080818085220.GA3136@manyfish.co.uk> <878wuulh9c.fsf@mocca.josefsson.org> <200808181440.39675.Arfrever.FTA@gmail.com> Message-ID: <871w0l56o6.fsf@mocca.josefsson.org> Arfrever Frehtes Taifersar Arahesis writes: > I'm confirming that this patch fixes this problem. Thanks, I have released 2.5.4 with the patch. /Simon From alvaro at gnu.org Thu Aug 21 23:17:56 2008 From: alvaro at gnu.org (Alvaro Lopez Ortega) Date: Thu, 21 Aug 2008 22:17:56 +0100 Subject: Server Credentials: x509 cert and key Message-ID: <48ADDB84.1050400@gnu.org> Hello there, I have a quick question for you guys, I hope someone can give me a hand with this. The thing is that I do not know how to access the X509 cert and key from within a gnutls_certificate_server_credentials object. Allow me to summarize the problem. All this is happening in a server; I create one of the certificate_server_credentials structures for each virtual server and then, I read the key and cert for each of them by calling the gnutls_certificate_set_x509_key_file() function. Right after that, gnutls_certificate_server_set_retrieve_function() sets the SNI callback from which I can access the virtual server credentials that I'd like the TLS connection to use. However, there is where it gets kind of confusing to me. How am I supposed to set the cert.x509 and key.x509 values in the gnutls_retr_st structure? Is there a way to get those values by using the certificate server credential object? Thanks! -- Greetings, alo http://www.alobbs.com/ From dkg-debian.org at fifthhorseman.net Fri Aug 22 07:14:11 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Aug 2008 01:14:11 -0400 Subject: GNU extensions to read_s2k for 2.5.x [was: Re: more on read_s2k() for GnuTLS ...] In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue\, 19 Aug 2008 13\:02\:04 +0300") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> Message-ID: <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> On Tue 2008-08-19 06:02:04 -0400, Nikos Mavrogiannopoulos wrote: > It looks nice. Expect me to apply it soon (later today or tomorrow). I see that it's applied in git already. Thank you very much, Nikos! But ack! i've got a frustrating request (but one that i figure is better done now than later): I've done a bit more reading, and found a reference to one other GNU S2K extension used by GPG. In DETAILS from the GnuPG sources [0], it says: GNU extensions to the S2K algorithm =================================== S2K mode 101 is used to identify these extensions. After the hash algorithm the 3 bytes "GNU" are used to make clear that these are extensions for GNU, the next bytes gives the GNU protection mode - 1000. Defined modes are: 1001 - do not store the secret part at all 1002 - a stub to access smartcards (not used in 1.2.x) I'm not proposing that we handle mode 1002 yet (i haven't encountered it and don't know how we'd talk to the smartcard anyway), but semantically, the code i asked you to commit now seems slightly wrong. In particular, it treats S2K mode 101 as GNU-Dummy, when in fact it should be "GNU Extensions", and it should just test the data after the hash to find out whether it's the gnu-dummy extension or not. The attached patch (against the current git head) doesn't change any functionality in the code, but it makes the semantics more congruent with the extension strategy outlined by GPG. It should also make it easier for any of us to implement/adopt other GNU S2K extensions in the future. Sorry for the confusion. Please let me know if there's any trouble with the patch. Regards, --dkg [0] http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/DETAILS?root=GnuPG -------------- next part -------------- A non-text attachment was scrubbed... Name: 24_clarify_GNU_S2K_extensions_2.5.x.diff Type: text/x-diff Size: 2659 bytes Desc: Clarify semantics of GNU S2K extensions against GnuTLS 2.5.x (git head) URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dkg-debian.org at fifthhorseman.net Fri Aug 22 08:36:45 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Aug 2008 02:36:45 -0400 Subject: GNU extensions to read_s2k for GnuTLS 2.4.x [was: Re: GNU extensions to read_s2k for 2.5.x] In-Reply-To: <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri\, 22 Aug 2008 01\:14\:11 -0400") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> Message-ID: <87hc9do8si.fsf_-_@squeak.fifthhorseman.net> On Fri 2008-08-22 01:14:11 -0400, Daniel Kahn Gillmor wrote: > In particular, it treats S2K mode 101 as GNU-Dummy, when in fact it > should be "GNU Extensions", and it should just test the data after > the hash to find out whether it's the gnu-dummy extension or not. Attached is the revised patch against the GnuTLS 2.4.x series that adopts the same semantic clarification. This applies against 2.4.1 as shipped in debian lenny, if anyone is interested. I've prepared patched .debs, which are available from the monkeysphere repository: http://monkeysphere.info/news/modified-gnutls-2.4.x-available/ They're working for me nicely at the moment. For anyone interested in testing, below is a public key with the primary key stripped (using GNU-Dummy S2K), and an authentication-capable subkey with unencrypted secret material. I think this would be a reasonable method to provide private keys to a typical TLS-capable service (such as HTTPS or SMTP). -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v1.4.9 (GNU/Linux) lQCVBEO3YdABBACRqqEnucag4+vyZny2M67Pai5+5suIRRvY+Ly8Ms5MvgCi3EVV xT05O/+0ShiRaf+QicCOFrhbU9PZzzU+seEvkeW2UCu4dQfILkmj+HBEIltGnHr3 G0yegHj5pnqrcezERURf2e17gGFWX91cXB9Cm721FPXczuKraphKwCA9PwARAQAB /gNlAkdOVQG0OURlbW9uc3RyYXRpb24gS2V5IGZvciBTMksgR05VIGV4dGVuc2lv biAxMDAxIC0tIGdudS1kdW1teYi8BBMBAgAmBQJDt2HQAhsDBQkB4TOABgsJCAcD AgQVAggDBBYCAwECHgECF4AACgkQQZUwSa4UDezTOQP/TMQXUVrWzHYZGopoPZ2+ ZS3qddiznBHsgb7MGYg1KlTiVJSroDUBCHIUJvdQKZV9zrzrFl47D07x6hGyUPHV aZXvuITW8t1o5MMHkCy3pmJ2KgfDvdUxrBvLfgPMICA4c6zA0mWquee43syEW9NY g3q61iPlQwD1J1kX1wlimLCdAdgEQ7dh0AEEANAwa63zlQbuy1Meliy8otwiOa+a mH6pxxUgUNggjyjO5qx+rl25mMjvGIRX4/L1QwIBXJBVi3SgvJW1COZxZqBYqj9U 8HVT07mWKFEDf0rZLeUE2jTm16cF9fcW4DQhW+sfYm+hi2sY3HeMuwlUBK9KHfW2 +bGeDzVZ4pqfUEudABEBAAEAA/0bemib+wxub9IyVFUp7nPobjQC83qxLSNzrGI/ RHzgu/5CQi4tfLOnwbcQsLELfker2hYnjsLrT9PURqK4F7udrWEoZ1I1LymOtLG/ 4tNZ7Mnul3wRC2tCn7FKx8sGJwGh/3li8vZ6ALVJAyOia5TZ/buX0+QZzt6+hPKk 7MU1WQIA4bUBjtrsqDwro94DvPj3/jBnMZbXr6WZIItLNeVDUcM8oHL807Am97K1 ueO/f6v1sGAHG6lVPTmtekqPSTWBfwIA7CGFvEyvSALfB8NUa6jtk27NCiw0csql kuhCmwXGMVOiryKEfegkIahf2bAd/gnWHPrpWp7bUE20v8YoW22I4wIAhnm5Wr5Q Sy7EHDUxmJm5TzadFp9gq08qNzHBpXSYXXJ3JuWcL1/awUqp3tE1I6zZ0hZ38Ia6 SdBMN88idnhDPqPoiKUEGAECAA8FAkO3YdACGyAFCQHhM4AACgkQQZUwSa4UDezm vQP/ZhK+2ly9oI2z7ZcNC/BJRch0/ybQ3haahII8pXXmOThpZohr/LUgoWgCZdXg vP6yiszNk2tIs8KphCAw7Lw/qzDC2hEORjWO4f46qk73RAgSqG/GyzI4ltWiDhqn vnQCFl3+QFSe4zinqykHnLwGPMXv428d/ZjkIc2ju8dRsn4= =CR5w -----END PGP PRIVATE KEY BLOCK----- As always, feedback is appreciated. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: 22_functional_s2k_with_GNU_dummy.diff Type: text/x-diff Size: 4521 bytes Desc: patch to enable read_s2k with GNU-Dummy against GnuTLS 2.4.x URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From simon at josefsson.org Fri Aug 22 14:45:35 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 22 Aug 2008 14:45:35 +0200 Subject: GNU extensions to read_s2k for GnuTLS 2.4.x In-Reply-To: <87hc9do8si.fsf_-_@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 22 Aug 2008 02:36:45 -0400") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> <87hc9do8si.fsf_-_@squeak.fifthhorseman.net> Message-ID: <87zln5usk0.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > For anyone interested in testing, below is a public key with the > primary key stripped (using GNU-Dummy S2K), and an > authentication-capable subkey with unencrypted secret material. > > I think this would be a reasonable method to provide private keys to a > typical TLS-capable service (such as HTTPS or SMTP). > > -----BEGIN PGP PRIVATE KEY BLOCK----- > Version: GnuPG v1.4.9 (GNU/Linux) > > lQCVBEO3YdABBACRqqEnucag4+vyZny2M67Pai5+5suIRRvY+Ly8Ms5MvgCi3EVV ... Daniel, it would be excellent if you could implement a small self-test of the functionality using that dummy private key, to be placed in tests/. It should use the public gnutls interfaces, not the direct opencdk interfaces. For inspiration, look at for example tests/certificate_set_x509_crl.c. Thanks, /Simon From simon at josefsson.org Fri Aug 22 14:53:26 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 22 Aug 2008 14:53:26 +0200 Subject: Server Credentials: x509 cert and key In-Reply-To: <48ADDB84.1050400@gnu.org> (Alvaro Lopez Ortega's message of "Thu, 21 Aug 2008 22:17:56 +0100") References: <48ADDB84.1050400@gnu.org> Message-ID: <87vdxtus6x.fsf@mocca.josefsson.org> Alvaro Lopez Ortega writes: > Hello there, > > I have a quick question for you guys, I hope someone can give me a > hand with this. The thing is that I do not know how to access the X509 > cert and key from within a gnutls_certificate_server_credentials > object. > > Allow me to summarize the problem. All this is happening in a server; > I create one of the certificate_server_credentials structures for each > virtual server and then, I read the key and cert for each of them by > calling the gnutls_certificate_set_x509_key_file() function. > > Right after that, gnutls_certificate_server_set_retrieve_function() > sets the SNI callback from which I can access the virtual server > credentials that I'd like the TLS connection to use. However, there is > where it gets kind of confusing to me. > > How am I supposed to set the cert.x509 and key.x509 values in the > gnutls_retr_st structure? Is there a way to get those values by using > the certificate server credential object? Are the virtual servers listening on the same port? If so, you shouldn't use gnutls_certificate_set_x509_key_file: that function is intended where you know which certificate+key should be used before the connection is started. But with SNI, you can't know this. Thus, in the callback from gnutls_certificate_server_set_retrieve_function, you need to figure out which virtual server is requested by the client by calling gnutls_server_name_get, and then load the proper certificate+key by using gnutls_x509_crt_list_import and gnutls_x509_privkey_import. The gnutls_retr_st should contain pointer to the imported certificate/key. I hope this helps. If you can suggest documentation improvements that would have helped you understand this, please do! /Simon From wk at gnupg.org Fri Aug 22 16:59:22 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Aug 2008 16:59:22 +0200 Subject: GNU extensions to read_s2k for 2.5.x In-Reply-To: <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 22 Aug 2008 01:14:11 -0400") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> Message-ID: <87r68h859x.fsf@wheatstone.g10code.de> On Fri, 22 Aug 2008 07:14, dkg-debian.org at fifthhorseman.net said: > I'm not proposing that we handle mode 1002 yet (i haven't encountered > it and don't know how we'd talk to the smartcard anyway), but It encodes the smartcard's seriaon number so the user can be asked to put in the right card and gpg diverts the opwrations to the smartcard code. > semantically, the code i asked you to commit now seems slightly wrong. > In particular, it treats S2K mode 101 as GNU-Dummy, when in fact it > should be "GNU Extensions", and it should just test the data after the > hash to find out whether it's the gnu-dummy extension or not. Background: The reason for this is that 101 is an OpenPGP identifier to be used for experimental/testing algorithms and thus we need to make sure that there is no ID clash. Adding the string "GNU" should be sufficient and the extra ID after the GNU allows us to even add more algorithms. Salam-Shalom, Werner -- Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg-debian.org at fifthhorseman.net Fri Aug 22 17:30:23 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Aug 2008 11:30:23 -0400 Subject: GNU extensions to read_s2k for GnuTLS 2.4.x In-Reply-To: <87zln5usk0.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri\, 22 Aug 2008 14\:45\:35 +0200") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> <87hc9do8si.fsf_-_@squeak.fifthhorseman.net> <87zln5usk0.fsf@mocca.josefsson.org> Message-ID: <87d4k1m5io.fsf@squeak.fifthhorseman.net> On Fri 2008-08-22 08:45:35 -0400, Simon Josefsson wrote: > Daniel, it would be excellent if you could implement a small self-test > of the functionality using that dummy private key, to be placed in > tests/. It should use the public gnutls interfaces, not the direct > opencdk interfaces. For inspiration, look at for example > tests/certificate_set_x509_crl.c. Attached is such a test. On a system running 2.4.1 without the patches, it gives me rc -59 on the gnutls_openpgp_privkey_import. With a patched GnuTLS, it exits cleanly: 0 vulcan:~# ./openpgp_gnu-dummy_extension gnutls_openpgp_privkey_import rc -59: GnuTLS internal error. 1 vulcan:~# dpkg --install ~dkg/src/gnutls/tmp.rLUgIlxWJV/libgnutls26_2.4.1-1.s2kext1_amd64.deb (Reading database ... 22502 files and directories currently installed.) Preparing to replace libgnutls26 2.4.1-1 (using .../libgnutls26_2.4.1-1.s2kext1_amd64.deb) ... Unpacking replacement libgnutls26 ... Setting up libgnutls26 (2.4.1-1.s2kext1) ... 0 vulcan:~# ./openpgp_gnu-dummy_extension 0 vulcan:~# I see no reason why the same shouldn't be a valid test for the 2.5.x series. There are too many Makefiles in my git tests/ directory (and i assume that some of them are generated from others -- why are they all in the git repo? i'm confused.) for me to know where/how to properly include this in the actual tests that get run. I'll watch the git repo changes to see how it's done if this gets added for future reference, though. The test doesn't do anything fancier than verify that the key can be successfully imported. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp_gnu-dummy_extension.c Type: text/x-csrc Size: 3691 bytes Desc: test to verify parsing of GNU-dummy S2K extension URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dkg-debian.org at fifthhorseman.net Fri Aug 22 19:19:04 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Aug 2008 13:19:04 -0400 Subject: GNU extensions to read_s2k for 2.5.x In-Reply-To: <87r68h859x.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri\, 22 Aug 2008 16\:59\:22 +0200") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> <87r68h859x.fsf@wheatstone.g10code.de> Message-ID: <87hc9dge7r.fsf@squeak.fifthhorseman.net> Hi Werner-- On Fri 2008-08-22 10:59:22 -0400, Werner Koch wrote: > On Fri, 22 Aug 2008 07:14, dkg-debian.org at fifthhorseman.net said: > >> I'm not proposing that we handle mode 1002 yet (i haven't >> encountered it and don't know how we'd talk to the smartcard >> anyway), but > > It encodes the smartcard's seriaon number so the user can be asked > to put in the right card and gpg diverts the opwrations to the > smartcard code. If you could include the concrete details of how the serial number is represented in doc/DETAILS, that would be great! >> semantically, the code i asked you to commit now seems slightly >> wrong. In particular, it treats S2K mode 101 as GNU-Dummy, when in >> fact it should be "GNU Extensions", and it should just test the >> data after the hash to find out whether it's the gnu-dummy >> extension or not. > > Background: The reason for this is that 101 is an OpenPGP identifier > to be used for experimental/testing algorithms and thus we need to > make sure that there is no ID clash. Adding the string "GNU" should > be sufficient and the extra ID after the GNU allows us to even add > more algorithms. This is a very forward-thinking approach. I hope my revised patch honors your original intentions. Thanks for setting it up this way, Werner. I personally think that GNU-dummy is useful enough (and simple enough) that something like it should be submitted to the S2K extension registry, as described in RFC 4880 section 10.1 [0] to encourage the ability to store partial keyrings. Regards, --dkg [0] http://tools.ietf.org/html/rfc4880#section-10.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dkg-debian.org at fifthhorseman.net Fri Aug 22 20:14:00 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Aug 2008 14:14:00 -0400 Subject: failure in certtool -p on gnutls 2.5.3 Message-ID: <87iqtsgbo7.fsf@squeak.fifthhorseman.net> certtool -p seems to be failing for me in a build of GnuTLS 2.5.3. For some reason, gdb isn't picking up all the debugging symbols i'd expect it to either (and i don't have time to look into that right now). But i thought i'd put this out there to see if anyone who's using bleeding-edge gnutls can run "certtool -p" without it choking. Below is the (fairly unintelligible) data i get from gdb. Regards, --dkg (gdb) run -p Starting program: /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool -p Generating a 2048 bit RSA private key... *** glibc detected *** /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool: malloc(): memory corruption (fast): 0x09dfada8 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6[0xb7cf84f4] /lib/i686/cmov/libc.so.6[0xb7cfb4ae] /lib/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7cfc525] /usr/lib/libgcrypt.so.11[0xb7e2d627] /usr/lib/libgcrypt.so.11[0xb7e2d85a] /usr/lib/libgcrypt.so.11[0xb7e2d87e] /usr/lib/libgcrypt.so.11[0xb7e74498] /usr/lib/libgcrypt.so.11[0xb7e74571] /usr/lib/libgcrypt.so.11[0xb7e74a8e] /usr/lib/libgcrypt.so.11[0xb7e6e5c2] /usr/lib/libgcrypt.so.11[0xb7e6ff90] /usr/lib/libgcrypt.so.11(gcry_mpi_invm+0x2b)[0xb7e2c11b] /usr/lib/libgnutls.so.26[0xb7ed052b] /usr/lib/libgnutls.so.26[0xb7eed9e0] /usr/lib/libgnutls.so.26(gnutls_x509_privkey_generate+0xf3)[0xb7eeebe3] /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool[0x804f2b1] /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool[0x804f4cc] /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool[0x8053a7d] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7ca0455] /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool[0x804bc51] ======= Memory map: ======== 08048000-0805e000 r-xp 00000000 fd:05 966808 /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool 0805e000-0805f000 rw-p 00016000 fd:05 966808 /home/dkg/src/gnutls/gnutls-2.5.3/src/.libs/certtool 0805f000-0806f000 rw-p 0805f000 00:00 0 09dde000-09dff000 rw-p 09dde000 00:00 0 [heap] b7b00000-b7b21000 rw-p b7b00000 00:00 0 b7b21000-b7c00000 ---p b7b21000 00:00 0 b7c2c000-b7c38000 r-xp 00000000 fd:02 49464 /lib/libgcc_s.so.1 b7c38000-b7c39000 rw-p 0000b000 fd:02 49464 /lib/libgcc_s.so.1 b7c39000-b7c3a000 rw-p b7c39000 00:00 0 b7c3a000-b7c3c000 r-xp 00000000 fd:02 49620 /lib/i686/cmov/libdl-2.7.so b7c3c000-b7c3e000 rw-p 00001000 fd:02 49620 /lib/i686/cmov/libdl-2.7.so b7c3e000-b7c6d000 r-xp 00000000 fd:02 49450 /lib/libncurses.so.5.6 b7c6d000-b7c70000 rw-p 0002f000 fd:02 49450 /lib/libncurses.so.5.6 b7c70000-b7c73000 r-xp 00000000 fd:03 132711 /usr/lib/libgpg-error.so.0.3.0 b7c73000-b7c74000 rw-p 00002000 fd:03 132711 /usr/lib/libgpg-error.so.0.3.0 b7c74000-b7c75000 rw-p b7c74000 00:00 0 b7c75000-b7c89000 r-xp 00000000 fd:03 133457 /usr/lib/libz.so.1.2.3.3 b7c89000-b7c8a000 rw-p 00013000 fd:03 133457 /usr/lib/libz.so.1.2.3.3 b7c8a000-b7ddf000 r-xp 00000000 fd:02 49617 /lib/i686/cmov/libc-2.7.so b7ddf000-b7de0000 r--p 00155000 fd:02 49617 /lib/i686/cmov/libc-2.7.so b7de0000-b7de2000 rw-p 00156000 fd:02 49617 /lib/i686/cmov/libc-2.7.so b7de2000-b7de5000 rw-p b7de2000 00:00 0 b7de5000-b7e11000 r-xp 00000000 fd:02 49495 /lib/libreadline.so.5.2 b7e11000-b7e15000 rw-p 0002c000 fd:02 49495 /lib/libreadline.so.5.2 b7e15000-b7e16000 rw-p b7e15000 00:00 0 b7e16000-b7e25000 r-xp 00000000 fd:03 133309 /usr/lib/libtasn1.so.3.0.15 b7e25000-b7e26000 rw-p 0000e000 fd:03 133309 /usr/lib/libtasn1.so.3.0.15 b7e26000-b7e8c000 r-xp 00000000 fd:03 132604 /usr/lib/libgcrypt.so.11.4.4 b7e8c000-b7e8e000 rw-p 00066000 fd:03 132604 /usr/lib/libgcrypt.so.11.4.4 b7e8e000-b7f24000 r-xp 00000000 fd:03 131592 /usr/lib/libgnutls.so.26.6.1 b7f24000-b7f2a000 rw-p 00095000 fd:03 131592 /usr/lib/libgnutls.so.26.6.1 b7f2a000-b7f2b000 rw-p b7f2a000 00:00 0 b7f45000-b7f46000 rw-p b7f45000 00:00 0 b7f46000-b7f47000 r-xp b7f46000 00:00 0 [vdso] b7f47000-b7f61000 r-xp 00000000 fd:02 49441 /lib/ld-2.7.so b7f61000-b7f63000 rw-p 0001a000 fd:02 49441 /lib/ld-2.7.so bfa4e000-bfa63000 rw-p bffeb000 00:00 0 [stack] Program received signal SIGABRT, Aborted. 0xb7f46424 in __kernel_vsyscall () (gdb) bt #0 0xb7f46424 in __kernel_vsyscall () #1 0xb7cb5640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7cb7018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7cf234d in ?? () from /lib/i686/cmov/libc.so.6 #4 0x00000007 in ?? () #5 0xbfa61958 in ?? () #6 0x00000400 in ?? () #7 0xffffffff in ?? () #8 0x00000000 in ?? () (gdb) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From simon at josefsson.org Sat Aug 23 12:34:14 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 23 Aug 2008 12:34:14 +0200 Subject: failure in certtool -p on gnutls 2.5.3 In-Reply-To: <87iqtsgbo7.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 22 Aug 2008 14:14:00 -0400") References: <87iqtsgbo7.fsf@squeak.fifthhorseman.net> Message-ID: <87zln4hvfd.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > certtool -p seems to be failing for me in a build of GnuTLS 2.5.3. > For some reason, gdb isn't picking up all the debugging symbols i'd > expect it to either (and i don't have time to look into that right > now). But i thought i'd put this out there to see if anyone who's > using bleeding-edge gnutls can run "certtool -p" without it choking. > > Below is the (fairly unintelligible) data i get from gdb. I get the same. Seems like it was introduced with the crypto interface, Nikos can you take a look? /Simon From simon at josefsson.org Sat Aug 23 15:52:46 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 23 Aug 2008 15:52:46 +0200 Subject: French translation of gnutls In-Reply-To: <48AFFD2E.5090603@quadriv.com> (N. Provost's message of "Sat, 23 Aug 2008 14:06:06 +0200") References: <48AFFD2E.5090603@quadriv.com> Message-ID: <87iqtrj0sx.fsf@mocca.josefsson.org> "N. Provost" writes: > Hello, > > I just sent my french translation of gnutls to the Translation > project's robot (gnutls-2.4.0.fr.po). > > I hope you'll agree with this work (I'll probably translate also the > next releases, if possible). Hi Nicolas! I have added your translation to the development branch (2.5.x), it will eventually become the next stable branch. Thanks, /Simon From simon at josefsson.org Mon Aug 25 13:26:27 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 25 Aug 2008 13:26:27 +0200 Subject: gnuTLS issues In-Reply-To: <200808242042.51960.christian@grothoff.org> (Christian Grothoff's message of "Sun, 24 Aug 2008 20:42:51 -0600") References: <200808242042.51960.christian@grothoff.org> Message-ID: <873aktgwt8.fsf@mocca.josefsson.org> Christian Grothoff writes: > I also find some minor memory leaks; you can find the diffs against our > repository at > > http://lists.gnu.org/archive/html/gnunet-svn/2008-08/msg00075.html Hi Christian! I have applied this patch to libtasn1, see: http://repo.or.cz/w/libtasn1.git?a=commitdiff;h=7cea3aa2d9ab4313be0aeaf08059877dd888b7c0 Thanks, Simon From simon at josefsson.org Mon Aug 25 14:02:48 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 25 Aug 2008 14:02:48 +0200 Subject: gnuTLS issues In-Reply-To: <200808242042.51960.christian@grothoff.org> (Christian Grothoff's message of "Sun, 24 Aug 2008 20:42:51 -0600") References: <200808242042.51960.christian@grothoff.org> Message-ID: <87y72lfgk7.fsf@mocca.josefsson.org> Christian Grothoff writes: > Hi Simon, > > I've just stumbled over a problem in the GNUtls codebase (dereferencing of > uninitialized pointer) and I cannot even figure out how the code was supposed > to work. I've filed a report in *our* bugtracking system at: > > https://gnunet.org/mantis/view.php?id=1417 > > I would appreciate any insight you may have to offer. Hi Christian! I agree the code looks broken. Do you have, or can generate, a test-PKCS#7 blob that can be used to test this code? As far as I can see, GnuTLS's certtool cannot generate a degenerate PKCS#7 blob with multiple certificates in it. I can't seem to see how to generate it using OpenSSL either. Nikos, do you have any insight to this code? The logic seems broken. Finally, do you think anyone will ever need the functionality to load certificates from a PKCS#7 blob? It isn't working right now, and nobody has complained (well, at least not until now), so maybe we could just remove the code. Christian, how did you find this problem? Do you want to store certificate lists in PKCS#7 blobs? Thanks, /Simon From nmav at gnutls.org Mon Aug 25 19:02:36 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 25 Aug 2008 20:02:36 +0300 Subject: gnuTLS issues In-Reply-To: <87y72lfgk7.fsf@mocca.josefsson.org> References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> Message-ID: <48B2E5AC.6020807@gnutls.org> Simon Josefsson wrote: > Christian Grothoff writes: > >> Hi Simon, >> >> I've just stumbled over a problem in the GNUtls codebase (dereferencing of >> uninitialized pointer) and I cannot even figure out how the code was supposed >> to work. I've filed a report in *our* bugtracking system at: >> >> https://gnunet.org/mantis/view.php?id=1417 >> >> I would appreciate any insight you may have to offer. > > Hi Christian! > > I agree the code looks broken. > > Do you have, or can generate, a test-PKCS#7 blob that can be used to > test this code? As far as I can see, GnuTLS's certtool cannot generate > a degenerate PKCS#7 blob with multiple certificates in it. I can't seem > to see how to generate it using OpenSSL either. > > Nikos, do you have any insight to this code? The logic seems broken. > Finally, do you think anyone will ever need the functionality to load > certificates from a PKCS#7 blob? It isn't working right now, and nobody > has complained (well, at least not until now), so maybe we could just > remove the code. Please don't remove the code. It is perfectly correct. It seems at some point the initialization of tmp was removed (or maybe was never commited correctly?). Anyway I've corrected it and it can now parse pkcs7 structures. I used openssl-0.9.7c/crypto/pkcs7/t/ff to test. regards, Nikos From nmav at gnutls.org Mon Aug 25 19:15:53 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 25 Aug 2008 20:15:53 +0300 Subject: failure in certtool -p on gnutls 2.5.3 In-Reply-To: <87iqtsgbo7.fsf@squeak.fifthhorseman.net> References: <87iqtsgbo7.fsf@squeak.fifthhorseman.net> Message-ID: <48B2E8C9.5040907@gnutls.org> Daniel Kahn Gillmor wrote: > certtool -p seems to be failing for me in a build of GnuTLS 2.5.3. > For some reason, gdb isn't picking up all the debugging symbols i'd > expect it to either (and i don't have time to look into that right > now). But i thought i'd put this out there to see if anyone who's > using bleeding-edge gnutls can run "certtool -p" without it choking. > > Below is the (fairly unintelligible) data i get from gdb. There was some issue with RSA parameter generation (less space provided to write parameters). It should now be fixed in the repository. Thank you. regards, Nikos From nmav at gnutls.org Mon Aug 25 19:47:55 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 25 Aug 2008 20:47:55 +0300 Subject: gnuTLS issues In-Reply-To: <48B2E5AC.6020807@gnutls.org> References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> Message-ID: >> Do you have, or can generate, a test-PKCS#7 blob that can be used to >> test this code? As far as I can see, GnuTLS's certtool cannot generate >> a degenerate PKCS#7 blob with multiple certificates in it. I can't seem >> to see how to generate it using OpenSSL either. >> >> Nikos, do you have any insight to this code? The logic seems broken. >> Finally, do you think anyone will ever need the functionality to load >> certificates from a PKCS#7 blob? It isn't working right now, and nobody >> has complained (well, at least not until now), so maybe we could just >> remove the code. > > Please don't remove the code. It is perfectly correct. It seems at some > point the initialization of tmp was removed (or maybe was never commited > correctly?). Anyway I've corrected it and it can now parse pkcs7 structures. And if I remember correctly this feature was used to convert the certificate lists (pkcs7) from the NIST tests. regards, Nikos From christian at grothoff.org Mon Aug 25 15:35:49 2008 From: christian at grothoff.org (Christian Grothoff) Date: Mon, 25 Aug 2008 07:35:49 -0600 Subject: gnuTLS issues In-Reply-To: <87y72lfgk7.fsf@mocca.josefsson.org> References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> Message-ID: <200808250735.49451.christian@grothoff.org> I found the problem by reading the code -- not by running any particular test. What we want to do is HTTPS supporting mostly only canonical features, certainly nothing exotic. I was trying to understand the code and figure out what code could / should be removed since we're concerned about code size for libmicrohttpd. Is GnuTLS usually compiled with ENABLE_PKI set to 1? When Amir imported the GnuTLS code, he made sure that this flag was always set -- what does it do? Christian On Monday 25 August 2008 06:02:48 am Simon Josefsson wrote: > Christian Grothoff writes: > > Hi Simon, > > > > I've just stumbled over a problem in the GNUtls codebase (dereferencing > > of uninitialized pointer) and I cannot even figure out how the code was > > supposed to work. I've filed a report in *our* bugtracking system at: > > > > https://gnunet.org/mantis/view.php?id=1417 > > > > I would appreciate any insight you may have to offer. > > Hi Christian! > > I agree the code looks broken. > > Do you have, or can generate, a test-PKCS#7 blob that can be used to > test this code? As far as I can see, GnuTLS's certtool cannot generate > a degenerate PKCS#7 blob with multiple certificates in it. I can't seem > to see how to generate it using OpenSSL either. > > Nikos, do you have any insight to this code? The logic seems broken. > Finally, do you think anyone will ever need the functionality to load > certificates from a PKCS#7 blob? It isn't working right now, and nobody > has complained (well, at least not until now), so maybe we could just > remove the code. > > Christian, how did you find this problem? Do you want to store > certificate lists in PKCS#7 blobs? > > Thanks, > /Simon From simon at josefsson.org Tue Aug 26 21:07:02 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 26 Aug 2008 21:07:02 +0200 Subject: gnuTLS issues In-Reply-To: <48B2E5AC.6020807@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 25 Aug 2008 20:02:36 +0300") References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> Message-ID: <87bpzfmw89.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> Christian Grothoff writes: >> >>> Hi Simon, >>> >>> I've just stumbled over a problem in the GNUtls codebase (dereferencing of >>> uninitialized pointer) and I cannot even figure out how the code was supposed >>> to work. I've filed a report in *our* bugtracking system at: >>> >>> https://gnunet.org/mantis/view.php?id=1417 >>> >>> I would appreciate any insight you may have to offer. >> >> Hi Christian! >> >> I agree the code looks broken. >> >> Do you have, or can generate, a test-PKCS#7 blob that can be used to >> test this code? As far as I can see, GnuTLS's certtool cannot generate >> a degenerate PKCS#7 blob with multiple certificates in it. I can't seem >> to see how to generate it using OpenSSL either. >> >> Nikos, do you have any insight to this code? The logic seems broken. >> Finally, do you think anyone will ever need the functionality to load >> certificates from a PKCS#7 blob? It isn't working right now, and nobody >> has complained (well, at least not until now), so maybe we could just >> remove the code. > > Please don't remove the code. It is perfectly correct. It seems at some > point the initialization of tmp was removed (or maybe was never commited > correctly?). Anyway I've corrected it and it can now parse pkcs7 structures. > > I used openssl-0.9.7c/crypto/pkcs7/t/ff to test. Ok. I've added a self tests tests/set_pkcs7_cred.c to test this functionality. It doesn't seem to work, but see next e-mail... /Simon From simon at josefsson.org Tue Aug 26 21:16:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 26 Aug 2008 21:16:04 +0200 Subject: another gnutls issue... In-Reply-To: <200808252059.00751.christian@grothoff.org> (Christian Grothoff's message of "Mon, 25 Aug 2008 20:59:00 -0600") References: <200808252059.00751.christian@grothoff.org> Message-ID: <87abezmvt7.fsf@mocca.josefsson.org> Christian Grothoff writes: > https://gnunet.org/mantis/view.php?id=1418 > > [again, no specific test or code to show anything wrong, it just looks, well, > odd...] The code looks indeed weird, and seems to be the reason why the set_pkcs7_cred self test fails. Any ideas, Nikos? It seems that way old GnuTLS versions have had the same problem with non-initialized tmp (at least v1.0.18). It doesn't seem like very widely used code... /Simon From simon at josefsson.org Tue Aug 26 21:19:58 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 26 Aug 2008 21:19:58 +0200 Subject: gnuTLS issues In-Reply-To: <200808250735.49451.christian@grothoff.org> (Christian Grothoff's message of "Mon, 25 Aug 2008 07:35:49 -0600") References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <200808250735.49451.christian@grothoff.org> Message-ID: <8763pnmvmp.fsf@mocca.josefsson.org> Christian Grothoff writes: > I found the problem by reading the code -- not by running any particular test. > What we want to do is HTTPS supporting mostly only canonical features, > certainly nothing exotic. I was trying to understand the code and figure out > what code could / should be removed since we're concerned about code size for > libmicrohttpd. You can definitely remove the code in your port. Nobody seem to have used it in GnuTLS either since it hasn't been working since at least around v1.0... > Is GnuTLS usually compiled with ENABLE_PKI set to 1? When Amir imported the > GnuTLS code, he made sure that this flag was always set -- what does it do? Yes, ENABLE_PKI is normally always 1 in GnuTLS, but there is --disable-extra-pki to set it to 0. I'm not sure the code even builds with ENABLE_PKI set to 0 any more, I don't check for that. Originally the symbol was likely intended to strip GnuTLS of the larger X.509 parts which are normally not needed. But it is an old symbol, so Nikos will know what it was intended for. /Simon > Christian > > On Monday 25 August 2008 06:02:48 am Simon Josefsson wrote: >> Christian Grothoff writes: >> > Hi Simon, >> > >> > I've just stumbled over a problem in the GNUtls codebase (dereferencing >> > of uninitialized pointer) and I cannot even figure out how the code was >> > supposed to work. I've filed a report in *our* bugtracking system at: >> > >> > https://gnunet.org/mantis/view.php?id=1417 >> > >> > I would appreciate any insight you may have to offer. >> >> Hi Christian! >> >> I agree the code looks broken. >> >> Do you have, or can generate, a test-PKCS#7 blob that can be used to >> test this code? As far as I can see, GnuTLS's certtool cannot generate >> a degenerate PKCS#7 blob with multiple certificates in it. I can't seem >> to see how to generate it using OpenSSL either. >> >> Nikos, do you have any insight to this code? The logic seems broken. >> Finally, do you think anyone will ever need the functionality to load >> certificates from a PKCS#7 blob? It isn't working right now, and nobody >> has complained (well, at least not until now), so maybe we could just >> remove the code. >> >> Christian, how did you find this problem? Do you want to store >> certificate lists in PKCS#7 blobs? >> >> Thanks, >> /Simon From simon at josefsson.org Tue Aug 26 21:36:14 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 26 Aug 2008 21:36:14 +0200 Subject: gnuTLS issues In-Reply-To: <48B2E5AC.6020807@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 25 Aug 2008 20:02:36 +0300") References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> Message-ID: <87y72jlgb5.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Please don't remove the code. It is perfectly correct. It seems at some > point the initialization of tmp was removed (or maybe was never commited > correctly?). Anyway I've corrected it and it can now parse pkcs7 structures. I looked at the history here, and the code was broken in a patch installed on 2003-02-09: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e25325c312e339bd1a3624de4b877c73960b58c7#patch17 That means it has been broken since v0.9.0 and nobody has missed it. I think we should remove the code, it seems nobody needs the feature and removing code decreases complexity. People can use 'certtool --p7-info' to convert PKCS#7 blobs into lists of PEM certificates. I tried it and it works fine on the OpenSSL file. /Simon From nmav at gnutls.org Wed Aug 27 16:22:29 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Aug 2008 17:22:29 +0300 Subject: gnuTLS issues In-Reply-To: <87y72jlgb5.fsf@mocca.josefsson.org> References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> <87y72jlgb5.fsf@mocca.josefsson.org> Message-ID: On Tue, Aug 26, 2008 at 10:36 PM, Simon Josefsson wrote: > That means it has been broken since v0.9.0 and nobody has missed it. I > think we should remove the code, it seems nobody needs the feature and > removing code decreases complexity. > > People can use 'certtool --p7-info' to convert PKCS#7 blobs into lists > of PEM certificates. I tried it and it works fine on the OpenSSL file. Isn't it the code being used by --p7-info? From simon at josefsson.org Wed Aug 27 16:46:25 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Aug 2008 16:46:25 +0200 Subject: gnuTLS issues In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 27 Aug 2008 17:22:29 +0300") References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> <87y72jlgb5.fsf@mocca.josefsson.org> Message-ID: <873akqh5xa.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Tue, Aug 26, 2008 at 10:36 PM, Simon Josefsson wrote: >> That means it has been broken since v0.9.0 and nobody has missed it. I >> think we should remove the code, it seems nobody needs the feature and >> removing code decreases complexity. >> >> People can use 'certtool --p7-info' to convert PKCS#7 blobs into lists >> of PEM certificates. I tried it and it works fine on the OpenSSL file. > > Isn't it the code being used by --p7-info? Ah, no. What I suggest is to remove the code to read PKCS#7 certificate chains in the gnutls_certificate_set_x509_key* functions. The current code hasn't worked since v0.9.0 and apparently nobody has missed it, see tests/set_pkcs7_cred.c for example code. Storing certificate chains in PKCS#7 blobs is not what that standard is intended for. Getting rid of the code may speed up loading certificate slightly, and will definitely improve code readability. The PKCS#7 functions used by certtool --p7-info are fine. What do you think? /Simon From tmraz at redhat.com Wed Aug 27 17:15:15 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 27 Aug 2008 17:15:15 +0200 Subject: Symbol conflict between libgnutls-openssl and real openssl Message-ID: <1219850116.22088.53.camel@vespa.frost.loc> Hello, some symbols in libgnutls-openssl are not renamed from their originals in OpenSSL. Unfortunately this causes conflicts when the application indirectly links to some library which then links to openssl. The situation can happen for example in case the system is configured to use ldap in the nsswitch.conf. The nss_ldap links to openldap libraries which is itself linked to the real OpenSSL libraries. Some symbols are then resolved from real OpenSSL and some from libgnutls-openssl which causes crashes because they are of course ABI incompatible. See: https://bugzilla.redhat.com/show_bug.cgi?id=446860 and https://bugzilla.redhat.com/show_bug.cgi?id=460310 The proposal is to use #defines in the public headers of gnutls/openssl.h to rename the symbols so they do not clash with real OpenSSL. It would of course require SONAME bump of libgnutls-openssl and rebuild of the dependent applications. What do you think about this proposal? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From simon at josefsson.org Wed Aug 27 17:34:57 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Aug 2008 17:34:57 +0200 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: <1219850116.22088.53.camel@vespa.frost.loc> (Tomas Mraz's message of "Wed, 27 Aug 2008 17:15:15 +0200") References: <1219850116.22088.53.camel@vespa.frost.loc> Message-ID: <87prnufp3y.fsf@mocca.josefsson.org> Tomas Mraz writes: > Hello, Hi Tomas! > some symbols in libgnutls-openssl are not renamed from their originals > in OpenSSL. That is sort of the idea... However, I understand the problems it can cause as you describe. > Unfortunately this causes conflicts when the application indirectly > links to some library which then links to openssl. The situation can > happen for example in case the system is configured to use ldap in the > nsswitch.conf. > > The nss_ldap links to openldap libraries which is itself linked to the > real OpenSSL libraries. Some symbols are then resolved from real OpenSSL > and some from libgnutls-openssl which causes crashes because they are of > course ABI incompatible. > > See: > > https://bugzilla.redhat.com/show_bug.cgi?id=446860 > and > https://bugzilla.redhat.com/show_bug.cgi?id=460310 > > The proposal is to use #defines in the public headers of > gnutls/openssl.h to rename the symbols so they do not clash with real > OpenSSL. It would of course require SONAME bump of libgnutls-openssl and > rebuild of the dependent applications. > > What do you think about this proposal? I like it. gnutls/openssl.h should thus contain a set of #define's such as: #define MD5_Init gnutls_openssl_MD5_Init Fortunately we have never guaranteed binary level compatibility with OpenSSL, so this change does not require any API changes in applications that uses libgnutls-openssl, just a recompile. It will indeed require a SONAME bump, and currently both libgnutls and libgnutls-openssl share the same SONAME version. We have discussed before if and how these versions can be separated. I suspect we have to make a decision now. Please send a patch for further discussions. Thanks, /Simon From nmav at gnutls.org Wed Aug 27 17:54:12 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Aug 2008 18:54:12 +0300 Subject: gnuTLS issues In-Reply-To: <873akqh5xa.fsf@mocca.josefsson.org> References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> <87y72jlgb5.fsf@mocca.josefsson.org> <873akqh5xa.fsf@mocca.josefsson.org> Message-ID: On Wed, Aug 27, 2008 at 5:46 PM, Simon Josefsson wrote: > Ah, no. What I suggest is to remove the code to read PKCS#7 certificate > chains in the gnutls_certificate_set_x509_key* functions. > > The current code hasn't worked since v0.9.0 and apparently nobody has > missed it, see tests/set_pkcs7_cred.c for example code. Storing > certificate chains in PKCS#7 blobs is not what that standard is intended > for. Getting rid of the code may speed up loading certificate slightly, > and will definitely improve code readability. > > The PKCS#7 functions used by certtool --p7-info are fine. > What do you think? ok then! I thought you were talking about the whole pkcs7 parsing functionality. regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Aug 27 17:58:04 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 27 Aug 2008 18:58:04 +0300 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: <87prnufp3y.fsf@mocca.josefsson.org> References: <1219850116.22088.53.camel@vespa.frost.loc> <87prnufp3y.fsf@mocca.josefsson.org> Message-ID: On Wed, Aug 27, 2008 at 6:34 PM, Simon Josefsson wrote: >> The nss_ldap links to openldap libraries which is itself linked to the >> real OpenSSL libraries. Some symbols are then resolved from real OpenSSL >> and some from libgnutls-openssl which causes crashes because they are of >> course ABI incompatible. >> >> See: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=446860 >> and >> https://bugzilla.redhat.com/show_bug.cgi?id=460310 >> >> The proposal is to use #defines in the public headers of >> gnutls/openssl.h to rename the symbols so they do not clash with real >> OpenSSL. It would of course require SONAME bump of libgnutls-openssl and >> rebuild of the dependent applications. >> >> What do you think about this proposal? > > I like it. gnutls/openssl.h should thus contain a set of #define's such > as: > > #define MD5_Init gnutls_openssl_MD5_Init > > Fortunately we have never guaranteed binary level compatibility with > OpenSSL, so this change does not require any API changes in applications > that uses libgnutls-openssl, just a recompile. It will indeed require a > SONAME bump, and currently both libgnutls and libgnutls-openssl share > the same SONAME version. We have discussed before if and how these > versions can be separated. I suspect we have to make a decision now. I think this is too much fuss. The gnutls-openssl layer is quick and dirty fix. I wouldn't recommend to any applications to use it. Either use openssl or gnutls directly. If you have this issue why not recompile the application with openssl instead? From nmav at gnutls.org Wed Aug 27 17:59:56 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Aug 2008 18:59:56 +0300 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: References: <1219850116.22088.53.camel@vespa.frost.loc> <87prnufp3y.fsf@mocca.josefsson.org> Message-ID: On Wed, Aug 27, 2008 at 6:58 PM, Nikos Mavrogiannopoulos wrote: >>> What do you think about this proposal? >> >> I like it. gnutls/openssl.h should thus contain a set of #define's such >> as: >> >> #define MD5_Init gnutls_openssl_MD5_Init >> >> Fortunately we have never guaranteed binary level compatibility with >> OpenSSL, so this change does not require any API changes in applications >> that uses libgnutls-openssl, just a recompile. It will indeed require a >> SONAME bump, and currently both libgnutls and libgnutls-openssl share >> the same SONAME version. We have discussed before if and how these >> versions can be separated. I suspect we have to make a decision now. > > I think this is too much fuss. The gnutls-openssl layer is quick and > dirty fix. I wouldn't recommend to any applications to use it. Either > use openssl or gnutls directly. If you have this issue why not > recompile the application with openssl instead? I'm not so much against any such patch. I'm mostly against maintaining this gnutls-openssl library. I think we should drop it. regards, Nikos From simon at josefsson.org Wed Aug 27 23:36:11 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Aug 2008 23:36:11 +0200 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 27 Aug 2008 18:59:56 +0300") References: <1219850116.22088.53.camel@vespa.frost.loc> <87prnufp3y.fsf@mocca.josefsson.org> Message-ID: <87fxoqf8dw.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Wed, Aug 27, 2008 at 6:58 PM, Nikos Mavrogiannopoulos > wrote: > >>>> What do you think about this proposal? >>> >>> I like it. gnutls/openssl.h should thus contain a set of #define's such >>> as: >>> >>> #define MD5_Init gnutls_openssl_MD5_Init >>> >>> Fortunately we have never guaranteed binary level compatibility with >>> OpenSSL, so this change does not require any API changes in applications >>> that uses libgnutls-openssl, just a recompile. It will indeed require a >>> SONAME bump, and currently both libgnutls and libgnutls-openssl share >>> the same SONAME version. We have discussed before if and how these >>> versions can be separated. I suspect we have to make a decision now. >> >> I think this is too much fuss. The gnutls-openssl layer is quick and >> dirty fix. I wouldn't recommend to any applications to use it. Either >> use openssl or gnutls directly. If you have this issue why not >> recompile the application with openssl instead? > > I'm not so much against any such patch. I'm mostly against maintaining > this gnutls-openssl library. I think we should drop it. I agree that libgnutls-openssl is ugly... however, I think there are some licensing corner cases where libgnutls-openssl actually is useful to some people. I think if people send patches we can apply them, but I don't see any reason to do anything beyond that. /Simon From simon at josefsson.org Thu Aug 28 10:01:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Aug 2008 10:01:37 +0200 Subject: gnuTLS issues In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 27 Aug 2008 18:54:12 +0300") References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <48B2E5AC.6020807@gnutls.org> <87y72jlgb5.fsf@mocca.josefsson.org> <873akqh5xa.fsf@mocca.josefsson.org> Message-ID: <873akpftzy.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Wed, Aug 27, 2008 at 5:46 PM, Simon Josefsson wrote: >> Ah, no. What I suggest is to remove the code to read PKCS#7 certificate >> chains in the gnutls_certificate_set_x509_key* functions. >> >> The current code hasn't worked since v0.9.0 and apparently nobody has >> missed it, see tests/set_pkcs7_cred.c for example code. Storing >> certificate chains in PKCS#7 blobs is not what that standard is intended >> for. Getting rid of the code may speed up loading certificate slightly, >> and will definitely improve code readability. >> >> The PKCS#7 functions used by certtool --p7-info are fine. >> What do you think? > > ok then! I thought you were talking about the whole pkcs7 parsing > functionality. Here is the patch I installed. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=cf07213ed160ce93d14a5801ace847b12b281ee5 /Simon From simon at josefsson.org Thu Aug 28 10:03:55 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Aug 2008 10:03:55 +0200 Subject: gnuTLS issues In-Reply-To: <8763pnmvmp.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 26 Aug 2008 21:19:58 +0200") References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <200808250735.49451.christian@grothoff.org> <8763pnmvmp.fsf@mocca.josefsson.org> Message-ID: <87vdxlefbo.fsf@mocca.josefsson.org> Simon Josefsson writes: > Christian Grothoff writes: > >> I found the problem by reading the code -- not by running any particular test. >> What we want to do is HTTPS supporting mostly only canonical features, >> certainly nothing exotic. I was trying to understand the code and figure out >> what code could / should be removed since we're concerned about code size for >> libmicrohttpd. > > You can definitely remove the code in your port. Nobody seem to have > used it in GnuTLS either since it hasn't been working since at least > around v1.0... Christian, we now have removed this code in GnuTLS too. If you find other code which looks strange when you review it, please let us know! Finding things like this is time consuming and often happens just by chance when someone reads the code like you've done. /Simon From simon at josefsson.org Thu Aug 28 13:24:13 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Aug 2008 13:24:13 +0200 Subject: Use of gcry_cipher_get_algo_blklen in opencdk? Message-ID: <87ej49z8ki.fsf@mocca.josefsson.org> Nikos, opencdk calls this function -- it seems it should use the new crypto layer instead. However, I can't find any way to get the block length of a cipher in the new framework. Should this be added? /Simon From info at jth.net Thu Aug 28 02:03:48 2008 From: info at jth.net (jth.net ApS) Date: Thu, 28 Aug 2008 02:03:48 +0200 Subject: --with-included-libtasn1 does not work Message-ID: <80gbb4584t21ejffqaht47ec43lm4lcbak@4ax.com> Linux Fedora 6 gnutls-2.5.4 ./configure --with-gnu-ld --prefix=/usr --with-included-libtasn1 Making all in opencdk make[3]: Entering directory `/usr/src/other/gnutls-2.5.4/lib/opencdk' /bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../includes -I../../includes -I../../lgl -I../../lgl -pipe -I/usr/local/include -g -O2 -Wno-pointer-sign -MT armor.lo -MD -MP -MF .deps/armor.Tpo -c -o armor.lo armor.c gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../includes -I../../includes -I../../lgl -I../../lgl -pipe -I/usr/local/include -g -O2 -Wno-pointer-sign -MT armor.lo -MD -MP -MF .deps/armor.Tpo -c armor.c -fPIC -DPIC -o .libs/armor.o In file included from ../../lib/gnutls_int.h:112, from opencdk.h:30, from armor.c:37: ../../lib/gnutls_mpi.h:29:23: error: libtasn1.h: No such file or directory In file included from ../../lib/gnutls_cert.h:30, from ../../lib/gnutls_int.h:238, from opencdk.h:30, from armor.c:37: This does not work: # include This will work # include "../../lib/minitasn1/libtasn1.h" Same problem in lib/gnutls_cert.h From nmav at gnutls.org Thu Aug 28 22:29:16 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Aug 2008 23:29:16 +0300 Subject: Use of gcry_cipher_get_algo_blklen in opencdk? In-Reply-To: <87ej49z8ki.fsf@mocca.josefsson.org> References: <87ej49z8ki.fsf@mocca.josefsson.org> Message-ID: <48B70A9C.7060008@gnutls.org> Simon Josefsson wrote: > Nikos, opencdk calls this function -- it seems it should use the new > crypto layer instead. However, I can't find any way to get the block > length of a cipher in the new framework. Should this be added? done. Now the _gnutls_cipher_get_block_size() is used. > /Simon > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From andrew at mcdonald.org.uk Thu Aug 28 23:11:19 2008 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Thu, 28 Aug 2008 22:11:19 +0100 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: <87fxoqf8dw.fsf@mocca.josefsson.org> References: <1219850116.22088.53.camel@vespa.frost.loc> <87prnufp3y.fsf@mocca.josefsson.org> <87fxoqf8dw.fsf@mocca.josefsson.org> Message-ID: <20080828211119.GA23063@mcdonald.org.uk> On Wed, Aug 27, 2008 at 11:36:11PM +0200, Simon Josefsson wrote: > > I agree that libgnutls-openssl is ugly... however, I think there are > some licensing corner cases where libgnutls-openssl actually is useful > to some people. > > I think if people send patches we can apply them, but I don't see any > reason to do anything beyond that. I agree (and I'm the one that wrote most of it). For the record (and to defend myself, since Simon just called something I wrote ugly :-) I originally wrote it as a quick-and-dirty hack to allow some applications in Debian to continue to provide SSL support, when this would otherwise have been dropped due to GPL/OpenSSL licence compatibility questions. The main reason it was only ever GPL (rather than LGPL) was to discourage its use for other than this particular reason. Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From simon at josefsson.org Fri Aug 29 10:04:51 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Aug 2008 10:04:51 +0200 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: <20080828211119.GA23063@mcdonald.org.uk> (Andrew McDonald's message of "Thu, 28 Aug 2008 22:11:19 +0100") References: <1219850116.22088.53.camel@vespa.frost.loc> <87prnufp3y.fsf@mocca.josefsson.org> <87fxoqf8dw.fsf@mocca.josefsson.org> <20080828211119.GA23063@mcdonald.org.uk> Message-ID: <87tzd4w8kc.fsf@mocca.josefsson.org> Andrew McDonald writes: > On Wed, Aug 27, 2008 at 11:36:11PM +0200, Simon Josefsson wrote: >> >> I agree that libgnutls-openssl is ugly... however, I think there are >> some licensing corner cases where libgnutls-openssl actually is useful >> to some people. >> >> I think if people send patches we can apply them, but I don't see any >> reason to do anything beyond that. > > I agree (and I'm the one that wrote most of it). > > For the record (and to defend myself, since Simon just called something > I wrote ugly :-) I originally wrote it as a quick-and-dirty hack to > allow some applications in Debian to continue to provide SSL support, > when this would otherwise have been dropped due to GPL/OpenSSL licence > compatibility questions. The main reason it was only ever GPL (rather > than LGPL) was to discourage its use for other than this particular > reason. Sorry, I didn't mean to belittle your contribution -- I wasn't talking about the code per se but the idea of having a OpenSSL compatibility library in GnuTLS generally. However, since people use it, I think we can keep the code and apply any patches sent to us, but at least right now I don't see anyone doing much work beyond that. /Simon From tmraz at redhat.com Fri Aug 29 10:21:53 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 29 Aug 2008 10:21:53 +0200 Subject: Symbol conflict between libgnutls-openssl and real openssl In-Reply-To: <87tzd4w8kc.fsf@mocca.josefsson.org> References: <1219850116.22088.53.camel@vespa.frost.loc> <87prnufp3y.fsf@mocca.josefsson.org> <87fxoqf8dw.fsf@mocca.josefsson.org> <20080828211119.GA23063@mcdonald.org.uk> <87tzd4w8kc.fsf@mocca.josefsson.org> Message-ID: <1219998113.22088.106.camel@vespa.frost.loc> On Fri, 2008-08-29 at 10:04 +0200, Simon Josefsson wrote: > Andrew McDonald writes: > > > On Wed, Aug 27, 2008 at 11:36:11PM +0200, Simon Josefsson wrote: > >> > >> I agree that libgnutls-openssl is ugly... however, I think there are > >> some licensing corner cases where libgnutls-openssl actually is useful > >> to some people. > >> > >> I think if people send patches we can apply them, but I don't see any > >> reason to do anything beyond that. > > > > I agree (and I'm the one that wrote most of it). > > > > For the record (and to defend myself, since Simon just called something > > I wrote ugly :-) I originally wrote it as a quick-and-dirty hack to > > allow some applications in Debian to continue to provide SSL support, > > when this would otherwise have been dropped due to GPL/OpenSSL licence > > compatibility questions. The main reason it was only ever GPL (rather > > than LGPL) was to discourage its use for other than this particular > > reason. > > Sorry, I didn't mean to belittle your contribution -- I wasn't talking > about the code per se but the idea of having a OpenSSL compatibility > library in GnuTLS generally. > > However, since people use it, I think we can keep the code and apply any > patches sent to us, but at least right now I don't see anyone doing much > work beyond that. Hopefully I will have a time to write such patch some time in the next month. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From simon at josefsson.org Fri Aug 29 10:01:31 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Aug 2008 10:01:31 +0200 Subject: --with-included-libtasn1 does not work In-Reply-To: <80gbb4584t21ejffqaht47ec43lm4lcbak@4ax.com> (jth net ApS's message of "Thu, 28 Aug 2008 02:03:48 +0200") References: <80gbb4584t21ejffqaht47ec43lm4lcbak@4ax.com> Message-ID: <87y72gw8pw.fsf@mocca.josefsson.org> "jth.net ApS" writes: > Linux Fedora 6 > gnutls-2.5.4 > > ./configure --with-gnu-ld --prefix=/usr --with-included-libtasn1 > > Making all in opencdk > make[3]: Entering directory `/usr/src/other/gnutls-2.5.4/lib/opencdk' > /bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H > -I. -I../.. -I../../lib -I../../includes -I../../includes -I../../lgl > -I../../lgl -pipe -I/usr/local/include -g -O2 -Wno-pointer-sign -MT armor.lo > -MD -MP -MF .deps/armor.Tpo -c -o armor.lo armor.c > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../includes > -I../../includes -I../../lgl -I../../lgl -pipe -I/usr/local/include -g -O2 > -Wno-pointer-sign -MT armor.lo -MD -MP -MF .deps/armor.Tpo -c armor.c -fPIC > -DPIC -o .libs/armor.o > In file included from ../../lib/gnutls_int.h:112, > from opencdk.h:30, > from armor.c:37: > ../../lib/gnutls_mpi.h:29:23: error: libtasn1.h: No such file or directory > In file included from ../../lib/gnutls_cert.h:30, > from ../../lib/gnutls_int.h:238, > from opencdk.h:30, > from armor.c:37: > > > This does not work: > # include > > This will work > # include "../../lib/minitasn1/libtasn1.h" > > Same problem in lib/gnutls_cert.h I believe I have fixed it with this patch: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b855779d46c07ae5a03280536e24f8405c374dcf I'll release 2.5.5 later today, please test it. /Simon From simon at josefsson.org Fri Aug 29 11:39:53 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Aug 2008 11:39:53 +0200 Subject: gnuTLS issues References: <200808242042.51960.christian@grothoff.org> <87y72lfgk7.fsf@mocca.josefsson.org> <200808250735.49451.christian@grothoff.org> <8763pnmvmp.fsf@mocca.josefsson.org> Message-ID: <87ej48w45y.fsf@mocca.josefsson.org> Simon Josefsson writes: >> Is GnuTLS usually compiled with ENABLE_PKI set to 1? When Amir imported the >> GnuTLS code, he made sure that this flag was always set -- what does it do? > > Yes, ENABLE_PKI is normally always 1 in GnuTLS, but there is > --disable-extra-pki to set it to 0. I'm not sure the code even builds > with ENABLE_PKI set to 0 any more, I don't check for that. Originally > the symbol was likely intended to strip GnuTLS of the larger X.509 parts > which are normally not needed. But it is an old symbol, so Nikos will > know what it was intended for. I looked into this more, and you should be able to compile with EXTRA_PKI set to 0 if you want to reduce code size. Setting EXTRA_PKI to 0 disables features such as: * CRL * PKCS#7 * PKCS#12 * X.509 certificate generation including signing * Certificate requests However the code necessary to verify X.509 signature remains, so you shouldn't be vulnerable to many more problem compared to before. Except that CRLs won't be verified, of course, but practically nobody uses CRLs anyway so.... your choice. Note that the command line tools and many self-tests won't build because they need this extra functions. The libraries should build fine, at least it does here. /Simon From simon at josefsson.org Fri Aug 29 13:21:38 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Aug 2008 13:21:38 +0200 Subject: Libtasn1 1.5 Message-ID: <873akovzgd.fsf@mocca.josefsson.org> Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding and DER/BER decoding. Libtasn1 is used by GnuTLS to manipulate X.509 objects and by Shishi to handle Kerberos V5 packets. Version 1.5 (released 2008-07-29) - Update gnulib files. - Fix memory leaks, from Christian Grothoff . Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join our help-gnutls mailing list, see: . Homepage: http://josefsson.org/libtasn1/ Manual in many formats: http://josefsson.org/libtasn1/manual/ Here are the compressed sources (1.5MB): ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.5.tar.gz http://ftp.gnu.org/gnu/gnutls/libtasn1-1.5.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.5.tar.gz.sig http://ftp.gnu.org/gnu/gnutls/libtasn1-1.5.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: b60dafd5c25af38f434175faf5efa82767653d05 libtasn1-1.5.tar.gz 8afa9c00aa0ec076c2c1bd19edabda36697aa90563502383e796327f libtasn1-1.5.tar.gz Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Fri Aug 29 13:45:53 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Aug 2008 13:45:53 +0200 Subject: GnuTLS 2.5.5, first release candidate for 2.6.0 Message-ID: <87y72gujri.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. I don't recall any new major features that are pending for the 2.5.x branch, so consider this a first release candidate for the next stable release 2.6.0. Test it as if it were a new stable release! Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.5.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.5.tar.bz2 The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.5.5.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.5.5.exe.sig The Windows binaries (DLL, EXE, etc) without the installer: http://josefsson.org/gnutls4win/gnutls-2.5.5.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.5.5.zip.sig Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.5.5-1_all.deb (4.9MB) 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. See http://josefsson.org/ for more details. /Simon * Version 2.5.5 (released 2008-08-29) ** libgnutls: New API to get a string corresponding to a error symbol. The function is gnutls_strerror_name. ** libgnutls: Fix include paths so that building with internal libtasn1 works. Reported by "jth.net ApS" . ** libgnutls: Fix segmentation fault when generating private keys. Reported by Daniel Kahn Gillmor . ** libgnutls: Remove code to import certificate chains in PKCS#7 format. The code has not worked since v0.9.0 and apparently nobody has missed it, so we decided to remove the code rather than fix it. If you have old certificate chains stored in PKCS#7 format, you can convert them to a list of PEM certificates by using 'certtool --p7-info'. Reported by Christian Grothoff . ** opencdk: Parse (but not decrypt) encrypted secret keys. Contributed by Daniel Kahn Gillmor . ** libgnutls: Fix many warnings. ** Included copy of libtasn1 is upgraded to version 1.5. ** Add French translation, thanks to Nicolas Provost. ** API and ABI modifications: gnutls_strerror_name: ADDED -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From jw+debian at jameswestby.net Fri Aug 29 18:25:48 2008 From: jw+debian at jameswestby.net (James Westby) Date: Fri, 29 Aug 2008 17:25:48 +0100 Subject: [PATCH] Document all gnutls-cli options in the manpage Message-ID: <1220027148.8580.49.camel@flash> Hi, In response to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492775 I went though and added all the missing options from gnutls-cli's manpage, removing --xml along the way. Please find attached the resulting diff. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-cli.1.diff Type: text/x-patch Size: 2553 bytes Desc: not available URL: