From nmav at gnutls.org Sun Jan 1 12:10:22 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 1 Jan 2012 13:10:22 +0200 Subject: gnutls for win32 In-Reply-To: <87aa68dfao.fsf@lifelogs.com> References: <87aa68dfao.fsf@lifelogs.com> Message-ID: 2011/12/31 Ted Zlatanov : > NM> Hello all and best wishes for new year, > NM> ?I've put pre-built win32 dlls and the other gnutls applications for > NM> 3.0.9 in [0]. I've managed to automate the procedure, so it could be > NM> that next releases (at least the major ones) will have the > NM> corresponding windows dlls released as well. > NM> [0]. http://homes.esat.kuleuven.be/~nikos/gnutls-win32/ > Great news! ?That lets GNU Emacs use the latest GnuTLS on all the > supported platforms. > Currently we're in a feature freeze for the Emacs pretest, but after the > next Emacs release we'll make GnuTLS 3.x required. ?That also lets us > ensure that we're not fighting old, already-fixed bugs. > Could the W32 releases go on the official GnuTLS site so we can point to > them in the GNU Emacs installation notes? ?And could you, when able, > publish the build script so developers can make their own W32 builds? Hi Ted, The build script is on the repository (cross.mk). I'll see what's the optimal release method of windows binaries. regards, Nikos From nmav at gnutls.org Wed Jan 4 00:04:58 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Jan 2012 01:04:58 +0200 Subject: Fwd: FSF fundraising drive In-Reply-To: <201201032202.q03M25l4001424@freefriends.org> References: <201201032202.q03M25l4001424@freefriends.org> Message-ID: ---------- Forwarded message ---------- From: Karl Berry Date: Wed, Jan 4, 2012 at 12:02 AM Subject: FSF fundraising drive To: gnu-prog at gnu.org The FSF is nearing the end of its current fundraising drive and all support is welcome, as always. ?Of course, the more members and/or donations, the more support for GNU infrastructure and free software campaigns. The direct url to join is http://www.fsf.org/join, or donate at https://my.fsf.org/donate. If you think it's appropriate, please forward this to your project mailing list and/or specific friends you think would be interested. ?Or if you'd like to join yourself, please go for it :). ?If you're already a member, and in any case for your contributions to GNU, thanks very much. Happy hacking to all, Karl From fweimer at bfk.de Wed Jan 4 17:07:14 2012 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 04 Jan 2012 16:07:14 +0000 Subject: gnutls 3.0.9 In-Reply-To: <4EE7D078.6090007@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 13 Dec 2011 23:23:52 +0100") References: <4EE7D078.6090007@gnutls.org> Message-ID: <824nwbladp.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > ** libgnutls: Added new priority string %SERVER_PRECEDENCE, which > changes the ciphersuite selection procedure. If specified the server > priorities will be used for selection instead of the client's. Is it true that without %SERVER_PRECEDENCE (and in earlier versions), the GNUTLS client only looks at its own cipher list, and does not restrict itself to the intersection of its own suites and that provided by the server? We're seeing interop issues with a TLSv1.2 server which advertises are fairly restricted list of cipher suites. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nmav at gnutls.org Wed Jan 4 17:33:55 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Jan 2012 17:33:55 +0100 Subject: gnutls 3.0.9 In-Reply-To: <824nwbladp.fsf@mid.bfk.de> References: <4EE7D078.6090007@gnutls.org> <824nwbladp.fsf@mid.bfk.de> Message-ID: <4F047F73.2010208@gnutls.org> On 01/04/2012 05:07 PM, Florian Weimer wrote: > * Nikos Mavrogiannopoulos: > >> ** libgnutls: Added new priority string %SERVER_PRECEDENCE, which >> changes the ciphersuite selection procedure. If specified the server >> priorities will be used for selection instead of the client's. > Is it true that without %SERVER_PRECEDENCE (and in earlier versions), > the GNUTLS client only looks at its own cipher list, and does not > restrict itself to the intersection of its own suites and that provided > by the server? %SERVER_PRECEDENCE has no effect if given in client side. It affects how the server selects the ciphersuite from the common supported. > We're seeing interop issues with a TLSv1.2 server which advertises are > fairly restricted list of cipher suites. What do you see? regards, Nikos From nmav at gnutls.org Wed Jan 4 19:26:17 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Jan 2012 19:26:17 +0100 Subject: gnutls 3.0.10 Message-ID: <4F0499C9.5030603@gnutls.org> Hello, I've just released gnutls 3.0.10. This release adds support for random-art images which display a drawing representing the public key's fingerprint, fixes several open issues for ms-windows support, and other fixes. * Version 3.0.10 (released 2012-01-04) ** gnutls-cli/serv: Set don't fragment bit in DTLS sessions in Linux as well as in BSD. ** gnutls-cli: Fixed reading from windows terminals. ** libgnutls: When GNUTLS_OPENPGP_FMT_BASE64 is specified the stream is assumed to be base64 encoded (previously the encoding was auto-detected). This avoids a decoding issue in windows systems. ** libgnutls: Corrected ciphersuite GNUTLS_ECDHE_PSK_AES_256_CBC_SHA384 ** libgnutls: Added ciphersuites: GNUTLS_PSK_WITH_AES_256_GCM_SHA384 and GNUTLS_DHE_PSK_WITH_AES_256_GCM_SHA384. ** libgnutls: Added function gnutls_random_art() to convert fingerprints to images (currently ascii-art). ** libgnutls: Corrected bug in DSA private key parsing, which prevented the verification of the key. ** API and ABI modifications: gnutls_random_art: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.10.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.10.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From fweimer at bfk.de Thu Jan 5 10:29:02 2012 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 05 Jan 2012 09:29:02 +0000 Subject: TLSv1.2 interop issue (was: Re: gnutls 3.0.9) In-Reply-To: <4F047F73.2010208@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 04 Jan 2012 17:33:55 +0100") References: <4EE7D078.6090007@gnutls.org> <824nwbladp.fsf@mid.bfk.de> <4F047F73.2010208@gnutls.org> Message-ID: <82ty4ajy5d.fsf_-_@mid.bfk.de> * Nikos Mavrogiannopoulos: >> We're seeing interop issues with a TLSv1.2 server which advertises are >> fairly restricted list of cipher suites. > What do you see? Well, the cipher suite thing was a different bug, on the server side, not caused by GNUTLS. Fixing that didn't make a dent in the original issue. The issue is triggered when I use GNTULS 2.12.14 to connect to an OpenJDK 7u2 server which requires client certificates. Here's output from "gnutls-cli --debug 255": |<3>| HSK[0x163a450]: SERVER HELLO DONE was received [4 bytes] |<6>| BUF[HSK]: Peeked 36 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<3>| HSK[0x163a450]: CERTIFICATE was sent [742 bytes] |<6>| BUF[HSK]: Peeked 4 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<7>| HWRITE: enqueued 742. Total 742 bytes. |<3>| HSK[0x163a450]: CLIENT KEY EXCHANGE was sent [262 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<7>| HWRITE: enqueued 262. Total 1004 bytes. |<2>| sign handshake cert vrfy: picked RSA-SHA512 with SHA512 |<2>| ASSERT: gnutls_sig.c:630 |<2>| ASSERT: auth_cert.c:1562 |<2>| ASSERT: gnutls_kx.c:336 |<2>| ASSERT: gnutls_handshake.c:2831 |<6>| BUF[HSK]: Cleared Data from buffer *** Fatal error: GnuTLS internal error. |<4>| REC: Sending Alert[2|80] - Internal error |<4>| REC[0x163a450]: Sending Packet[1] Alert(21) with length: 2 gnutls_sig.c:630 says: | return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); /* too bad we only support SHA1 and SHA256 */ This is a bit puzzling. Why does GNUTLS pick RSA-SHA512 if it doesn't support the algorithm? I remove RSA-SHA384 and RSA-SHA512 from gnutls_algorithm.c, and now I end up with: |<2>| sign handshake cert vrfy: picked RSA-SHA256 with SHA256 And the handshake completes. The next task is to figure out how to disable SHA-384 and SHA-512 in the server and client code. *sigh* -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nmav at gnutls.org Thu Jan 5 10:37:10 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 5 Jan 2012 10:37:10 +0100 Subject: TLSv1.2 interop issue (was: Re: gnutls 3.0.9) In-Reply-To: <82ty4ajy5d.fsf_-_@mid.bfk.de> References: <4EE7D078.6090007@gnutls.org> <824nwbladp.fsf@mid.bfk.de> <4F047F73.2010208@gnutls.org> <82ty4ajy5d.fsf_-_@mid.bfk.de> Message-ID: On Thu, Jan 5, 2012 at 10:29 AM, Florian Weimer wrote: > * Nikos Mavrogiannopoulos: >>> We're seeing interop issues with a TLSv1.2 server which advertises are >>> fairly restricted list of cipher suites. >> What do you see? > Well, the cipher suite thing was a different bug, on the server side, > not caused by GNUTLS. ?Fixing that didn't make a dent in the original > issue. > The issue is triggered when I use GNTULS 2.12.14 to connect to an > OpenJDK 7u2 server which requires client certificates. > Here's output from "gnutls-cli --debug 255": [...] > gnutls_sig.c:630 says: > | ? ?return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); /* too bad we only support SHA1 and SHA256 */ Can you try gnutls 3.0.x? It doesn't have this limitation. > This is a bit puzzling. ?Why does GNUTLS pick RSA-SHA512 if it doesn't > support the algorithm? Could you send me the transaction as a tcpdump raw file (to open with wireshark). I'll check later whether there can be a fix for 2.12.x. regards, Nikos From fweimer at bfk.de Thu Jan 5 10:49:13 2012 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 05 Jan 2012 09:49:13 +0000 Subject: TLSv1.2 interop issue In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 5 Jan 2012 10:37:10 +0100") References: <4EE7D078.6090007@gnutls.org> <824nwbladp.fsf@mid.bfk.de> <4F047F73.2010208@gnutls.org> <82ty4ajy5d.fsf_-_@mid.bfk.de> Message-ID: <82hb0ajx7q.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: >> gnutls_sig.c:630 says: >> | ? ?return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); /* too bad we only support SHA1 and SHA256 */ > > Can you try gnutls 3.0.x? It doesn't have this limitation. I tried, but it seems to require nettle 2.4 to build, which I currently lack. >> This is a bit puzzling. ?Why does GNUTLS pick RSA-SHA512 if it doesn't >> support the algorithm? > > Could you send me the transaction as a tcpdump raw file (to open with > wireshark). I'll send it by separate mail. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nmav at gnutls.org Fri Jan 6 20:54:19 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 06 Jan 2012 20:54:19 +0100 Subject: gnutls 3.0.11 Message-ID: <4F07516B.8050907@gnutls.org> Hello, I've just released gnutls 3.0.11. This release fixes a timing attack possible in the DTLS code (report and patch by Nadhem Alfardan and Kenny Paterson). * Version 3.0.11 (released 2012-01-06) ** libgnutls: Corrected functionality of gnutls_record_get_direction(). Reported by Philip Allison. ** libgnutls: Provide less timing information when decoding TLS/DTLS record packets. Patch by Nadhem Alfardan. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.11.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.11.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Jan 6 21:40:20 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 06 Jan 2012 21:40:20 +0100 Subject: gnutls 2.12.15 Message-ID: <4F075C34.4070309@gnutls.org> Hello, I've just released gnutls 2.12.15. This is a bugfix release on the 2.12.x branch. Version 2.12.15 (released 2011-01-06) ** libgnutls: Disable signature algorithms that are not supported for client certificate verification. Reported by Florian Weimer. ** libgnutls: Optimized DH generation process (ported from 3.0.x) ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Jan 6 22:00:59 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 06 Jan 2012 22:00:59 +0100 Subject: gnutls 2.12.16 Message-ID: <4F07610B.1090601@gnutls.org> Hello, I've just released gnutls 2.12.16. It seems 2.12.15 was missing an important fix that is included in this release. Version 2.12.16 (released 2011-01-06) ** libgnutls: Corrected functionality of gnutls_record_get_direction(). Reported by Philip Allison. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From rich at kde.org Sun Jan 8 23:00:20 2012 From: rich at kde.org (Richard Moore) Date: Sun, 8 Jan 2012 22:00:20 +0000 Subject: Experiments with GnuTLS and Qt Message-ID: I've been evaluating using GnuTLS with Qt this weekend. There's a basic tool that prints out cert info and converts from some Qt data types like QDateTime etc. at http://xmelegance.org/devel/cert-prototype.tar.bz2 I'm just posting it here in case it happens to be useful to anyone. Issues I've encountered are documented in the NOTES file. Cheers Rich. From ali.khalfan at gmail.com Mon Jan 9 05:25:35 2012 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Sun, 08 Jan 2012 23:25:35 -0500 Subject: porting gnutls to mozilla Message-ID: <4F0A6C3F.5040303@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I was wondering ever since the paper that describes the attack on pre-tls 1.2 (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf ) whether it is possible to use gnutls on mozilla software instead of libnss. Has anyone ever attempted doing something similar? I am assuming it is theoretically possible to import gnutls libraries in the mozilla source and re-compile. I would like to know if anyone has attempted such a thing. - --Ali -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPCmw6AAoJELPotgzy0FtQ7oAQALzfIg6Bz9ywN4B3ylTv9qKY qB0lRifqe7gthgaEK91mV9fI8UOKFS5CXYIhDSXlmqV2XhPvO3s49UiXHfETyWQI B9wY0rl65o3HKlpas3iW34tJzDavGEiJpfQH6hrBNtKP+uwxtc2SETJttbOFxPdl GndUEcooOHwEetFzmaBXCrd3PMzHOrPJeY37qDpbob4qjDe8OTv/iQ+5KryyVD60 dfcZ9QkW9GGbsiWg1EPPp2qwdpQ/C3rZ+C5Xu2J5LLEqSUXlWLKItqhYk7A/tzs7 TBCWXERcLzRC37SHXDcd6Kw6GJoEHQ7+3zKhNFV1Mt8VahyrxyFc+xpZxEdotQ9+ WZxGFNArNvM4auHS7e8a9KqTIU75NekySDy/3h8ZynfKEd9sLiYdOkFz+Z/O2Fh+ yFXius6Qv/6c4noCnxmGKurIWNc/Dxv0i9UtltNkGkDKK1eVJ8FQnU3dBLTCtcix sf9GsxYu2vqsWDCAmsmZyoa3F6pz6mbp1XQpFpUvo1qVm3xqSxBSSj+qrQ0RCWoW NXhiPRm/0aWRv+6nAolN1SC/zJIkcm3tbcGwhFKigG5a7EFc2SMWmDXpMydEF3+b kmiAlNHd8Q2GLcRdnGOflYVQuyrVpCSIERy6lRi7NPfBwet4RzSw/tHhO1n7nQU1 jKLQNh1JvrRbkCD2tNi6 =q52a -----END PGP SIGNATURE----- From fxchip at gmail.com Mon Jan 9 07:16:19 2012 From: fxchip at gmail.com (Zach C.) Date: Sun, 8 Jan 2012 22:16:19 -0800 Subject: porting gnutls to mozilla In-Reply-To: <4F0A6C3F.5040303@gmail.com> References: <4F0A6C3F.5040303@gmail.com> Message-ID: I think you would have to rewrite all the parts of Mozilla that use libnss to use libgnutls instead; given that libnss and libgnutls APIs are entirely different (I would think), that would not be a trivial rewrite. It's definitely not just a matter of "swap the library." On Sun, Jan 8, 2012 at 8:25 PM, Ali Khalfan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I was wondering ever since the paper that describes the attack on > pre-tls 1.2 > ( > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf > ) whether it is possible to use gnutls on mozilla software instead of > libnss. Has anyone ever attempted doing something similar? I am > assuming it is theoretically possible to import gnutls libraries in the > mozilla source and re-compile. > > I would like to know if anyone has attempted such a thing. > > - --Ali > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCgAGBQJPCmw6AAoJELPotgzy0FtQ7oAQALzfIg6Bz9ywN4B3ylTv9qKY > qB0lRifqe7gthgaEK91mV9fI8UOKFS5CXYIhDSXlmqV2XhPvO3s49UiXHfETyWQI > B9wY0rl65o3HKlpas3iW34tJzDavGEiJpfQH6hrBNtKP+uwxtc2SETJttbOFxPdl > GndUEcooOHwEetFzmaBXCrd3PMzHOrPJeY37qDpbob4qjDe8OTv/iQ+5KryyVD60 > dfcZ9QkW9GGbsiWg1EPPp2qwdpQ/C3rZ+C5Xu2J5LLEqSUXlWLKItqhYk7A/tzs7 > TBCWXERcLzRC37SHXDcd6Kw6GJoEHQ7+3zKhNFV1Mt8VahyrxyFc+xpZxEdotQ9+ > WZxGFNArNvM4auHS7e8a9KqTIU75NekySDy/3h8ZynfKEd9sLiYdOkFz+Z/O2Fh+ > yFXius6Qv/6c4noCnxmGKurIWNc/Dxv0i9UtltNkGkDKK1eVJ8FQnU3dBLTCtcix > sf9GsxYu2vqsWDCAmsmZyoa3F6pz6mbp1XQpFpUvo1qVm3xqSxBSSj+qrQ0RCWoW > NXhiPRm/0aWRv+6nAolN1SC/zJIkcm3tbcGwhFKigG5a7EFc2SMWmDXpMydEF3+b > kmiAlNHd8Q2GLcRdnGOflYVQuyrVpCSIERy6lRi7NPfBwet4RzSw/tHhO1n7nQU1 > jKLQNh1JvrRbkCD2tNi6 > =q52a > -----END PGP SIGNATURE----- > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Jan 9 13:50:48 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Jan 2012 13:50:48 +0100 Subject: Experiments with GnuTLS and Qt In-Reply-To: References: Message-ID: On Sun, Jan 8, 2012 at 11:00 PM, Richard Moore wrote: > I've been evaluating using GnuTLS with Qt this weekend. There's a > basic tool that prints out cert info and converts from some Qt data > types like QDateTime etc. at > http://xmelegance.org/devel/cert-prototype.tar.bz2 I'm just posting it > here in case it happens to be useful to anyone. Issues I've > encountered are documented in the NOTES file. Hello, Interesting comments. - The docs say to report bugs to one place, but they also seem to use the bug reporting tool from savanah. No indication of which is the one to use. It seems the bug report email actually goes to the development list. Actually both end up in the development list and are treated equally. - Getting at the subject/issuer details seems a bit tricky. There seem to be errors in the docs here which doesn't help. Also seems to be using a mixture of void * and char * to hold oids which means we'll need some casts. Would you like to elaborate on that? Is there is something we should fix (in the documentation or code)? - There appears to be no method to map oids to human readable names, there's some internal functions for it but nothing public. Are you referring to the DN oids? If this is the case and it is an interesting feature we could consider exporting the known OIDs. However this cannot be a general OID -> string convertion. - Both subject/issuer (distinguished name) and extensions APIs seem to involve querying the oids and passing them around. This is likely to be slow since we're talking string comparisions (and even worse the part of the string that varies is at the end though this might be worked around internally since we provide a length). To which functions do you refer to? In general I try to promote the gnutls_x509_crt_get_dn() that provides an RFC2253 compliant single string to describe the DN. It appears there's another way to get this info gnutls_x509_crt_get_subject() no idea if this is a better mechanism at this time. If less string comparisons is your goal this looks like an alternative. However, unless you expect millions of DN queries I wouldn't worry about string comparisons. Its impact would be minimal to the cost of DER decoding overhead. - No support for OCSP in the released version, OCSP code appears to be under active development in a branch of the git repo. It is expected to be merged soon. regards, Nikos From rich at kde.org Mon Jan 9 14:35:52 2012 From: rich at kde.org (Richard Moore) Date: Mon, 9 Jan 2012 13:35:52 +0000 Subject: Experiments with GnuTLS and Qt In-Reply-To: References: Message-ID: On Mon, Jan 9, 2012 at 12:50 PM, Nikos Mavrogiannopoulos wrote: > On Sun, Jan 8, 2012 at 11:00 PM, Richard Moore wrote: >> I've been evaluating using GnuTLS with Qt this weekend. There's a >> basic tool that prints out cert info and converts from some Qt data >> types like QDateTime etc. at >> http://xmelegance.org/devel/cert-prototype.tar.bz2 I'm just posting it >> here in case it happens to be useful to anyone. Issues I've >> encountered are documented in the NOTES file. > > Hello, > ?Interesting comments. > > - The docs say to report bugs to one place, but they also seem to use the bug > ?reporting tool from savanah. No indication of which is the one to use. It > ?seems the bug report email actually goes to the development list. > > Actually both end up in the development list and are treated equally. That makes sense. > > - Getting at the subject/issuer details seems a bit tricky. There seem to be > ?errors in the docs here which doesn't help. Also seems to be using a mixture > ?of void * and char * to hold oids which means we'll need some casts. > > Would you like to elaborate on that? Is there is something we should > fix (in the > documentation or code)? Sure, there's certainly a doc error, but I haven't had a chance to check if it's due to a problem in the doc comments yet or a bug in the generation tool. If you go here: http://www.gnu.org/software/gnutls/manual/html_node/X509-certificate-API.html#X509-certificate-API and search for gnutls_x509_crt_get_dn you'll see that the docs refer to raw_flag which is only present in the gnutls_x509_crt_get_dn_by_oid() function. You can also see that gnutls_x509_crt_get_dn_oid uses void * for the oid wheras gnutls_x509_crt_get_dn_by_oid() uses a const char *. > > - There appears to be no method to map oids to human readable names, there's > ?some internal functions for it but nothing public. > > Are you referring to the DN oids? If this is the case and it is an interesting > feature we could consider exporting the known OIDs. However this cannot > be a general OID -> string convertion. Yeah, I wasn't expecting a fully generic conversion. The way this works in openssl is that if it's a known OID then it converts it to a human readable name, and if not it returns the oid as a string. Normally openssl uses internal id numbers for the oid in order to improve performance. > > - Both subject/issuer (distinguished name) and extensions APIs seem to involve > ?querying the oids and passing them around. This is likely to be slow since > ?we're talking string comparisions (and even worse the part of the string > ?that varies is at the end though this might be worked around internally > ?since we provide a length). > > To which functions do you refer to? In general I try to promote the > gnutls_x509_crt_get_dn() that provides an RFC2253 compliant single > string to describe the DN. I need to be able to return the DN components in a structured way to implement this API: http://doc.qt.nokia.com/5.0-snapshot/qsslcertificate.html#subjectInfo Getting the DN as a string and then parsing it to get the information is likely to be slow, and risks mishandling strange DNs that are deliberately crafted to be mishandled. For example many tools get repeated elements like multiple CNs wrong, to say nothing of deliberately strange ones. > > ?It appears there's another way to get this info > ?gnutls_x509_crt_get_subject() no idea if this is a better mechanism at this > ?time. > > If less string comparisons is your goal this looks like an alternative. However, > unless you expect millions of DN queries I wouldn't worry about string > comparisons. > Its impact would be minimal to the cost of DER decoding overhead. Yeah, I haven't benchmarked anything, so this is most likely correct. It just seems a bit daft to convert the oid to a string, then do a string comparison just in order to map something like the country oid back to 'C'. > > - No support for OCSP in the released version, OCSP code appears to be under > ?active development in a branch of the git repo. > > It is expected to be merged soon. Great. Thanks for taking the time to read through this. Cheers rich. > > regards, > Nikos From nmav at gnutls.org Mon Jan 9 21:12:22 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 09 Jan 2012 21:12:22 +0100 Subject: Experiments with GnuTLS and Qt In-Reply-To: References: Message-ID: <4F0B4A26.2030701@gnutls.org> On 01/09/2012 02:35 PM, Richard Moore wrote: >> - Getting at the subject/issuer details seems a bit tricky. There seem to be >> errors in the docs here which doesn't help. Also seems to be using a mixture >> of void * and char * to hold oids which means we'll need some casts. >> >> Would you like to elaborate on that? Is there is something we should >> fix (in the >> documentation or code)? > Sure, there's certainly a doc error, but I haven't had a chance to > check if it's due to a problem in the doc comments yet or a bug in the > generation tool. If you go here: > http://www.gnu.org/software/gnutls/manual/html_node/X509-certificate-API.html#X509-certificate-API > and search for gnutls_x509_crt_get_dn you'll see that the docs refer > to raw_flag which is only present in the > gnutls_x509_crt_get_dn_by_oid() function. Thanks. I've removed that. It will be included in the next release. > You can also see that gnutls_x509_crt_get_dn_oid uses void * for the > oid wheras gnutls_x509_crt_get_dn_by_oid() uses a const char *. When supplying an OID the const char* type is used, while when gnutls is copying an OID, it copies to a void* pointer. In both cases though a null terminated string is used/copied. We might change those (void*) to (char*) in a future version. >> - There appears to be no method to map oids to human readable names, there's >> some internal functions for it but nothing public. >> Are you referring to the DN oids? If this is the case and it is an interesting >> feature we could consider exporting the known OIDs. However this cannot >> be a general OID -> string convertion. > Yeah, I wasn't expecting a fully generic conversion. The way this > works in openssl is that if it's a known OID then it converts it to a > human readable name, and if not it returns the oid as a string. > Normally openssl uses internal id numbers for the oid in order to > improve performance. This look pretty simple. I'll add a function for that. >> To which functions do you refer to? In general I try to promote the >> gnutls_x509_crt_get_dn() that provides an RFC2253 compliant single >> string to describe the DN. > I need to be able to return the DN components in a structured way to > implement this API: > > http://doc.qt.nokia.com/5.0-snapshot/qsslcertificate.html#subjectInfo > > Getting the DN as a string and then parsing it to get the information > is likely to be slow, and risks mishandling strange DNs that are > deliberately crafted to be mishandled. For example many tools get > repeated elements like multiple CNs wrong, to say nothing of > deliberately strange ones. No this what I meant. What I meant is to get a single string and treat it as being "the full name", rather than getting each field of DN in separate. But since you have this multiple strings requirement it doesn't look practical. >> It appears there's another way to get this info >> gnutls_x509_crt_get_subject() no idea if this is a better mechanism at this >> time. >> If less string comparisons is your goal this looks like an alternative. However, >> unless you expect millions of DN queries I wouldn't worry about string >> comparisons. >> Its impact would be minimal to the cost of DER decoding overhead. > Yeah, I haven't benchmarked anything, so this is most likely correct. > It just seems a bit daft to convert the oid to a string, then do a > string comparison just in order to map something like the country oid > back to 'C'. It can be optimized, e.g. using a hash table, but given that we support a handful of DN OIDs, it doesn't really make sense. If it proves to be a bottleneck we reconsider. regards, Nikos From rich at kde.org Mon Jan 9 22:47:38 2012 From: rich at kde.org (Richard Moore) Date: Mon, 9 Jan 2012 21:47:38 +0000 Subject: Experiments with GnuTLS and Qt In-Reply-To: <4F0B4A26.2030701@gnutls.org> References: <4F0B4A26.2030701@gnutls.org> Message-ID: On Mon, Jan 9, 2012 at 8:12 PM, Nikos Mavrogiannopoulos wrote: > On 01/09/2012 02:35 PM, Richard Moore wrote: > >>> - Getting at the subject/issuer details seems a bit tricky. There seem to be >>> ?errors in the docs here which doesn't help. Also seems to be using a mixture >>> ?of void * and char * to hold oids which means we'll need some casts. >>> >>> Would you like to elaborate on that? Is there is something we should >>> fix (in the >>> documentation or code)? >> Sure, there's certainly a doc error, but I haven't had a chance to >> check if it's due to a problem in the doc comments yet or a bug in the >> generation tool. If you go here: >> http://www.gnu.org/software/gnutls/manual/html_node/X509-certificate-API.html#X509-certificate-API >> and search for gnutls_x509_crt_get_dn you'll see that the docs refer >> to raw_flag which is only present in the >> gnutls_x509_crt_get_dn_by_oid() function. > > > Thanks. I've removed that. It will be included in the next release. Great. > >> You can also see that gnutls_x509_crt_get_dn_oid uses void * for the >> oid wheras gnutls_x509_crt_get_dn_by_oid() uses a const char *. > > > When supplying an OID the const char* type is used, while when gnutls > is copying an OID, it copies to a void* pointer. In both cases though > a null terminated string is used/copied. We might change those (void*) > to (char*) in a future version. Yeah, I managed to avoid the need for casting here, but I think treating them consistently would be clearer. > >>> - There appears to be no method to map oids to human readable names, there's >>> ?some internal functions for it but nothing public. >>> Are you referring to the DN oids? If this is the case and it is an interesting >>> feature we could consider exporting the known OIDs. However this cannot >>> be a general OID -> string convertion. >> Yeah, I wasn't expecting a fully generic conversion. The way this >> works in openssl is that if it's a known OID then it converts it to a >> human readable name, and if not it returns the oid as a string. >> Normally openssl uses internal id numbers for the oid in order to >> improve performance. > > > This look pretty simple. I'll add a function for that. Great, I think there's an internal function that does most of this anyway from reading the sources. > >>> To which functions do you refer to? In general I try to promote the >>> gnutls_x509_crt_get_dn() that provides an RFC2253 compliant single >>> string to describe the DN. >> I need to be able to return the DN components in a structured way to >> implement this API: >> >> http://doc.qt.nokia.com/5.0-snapshot/qsslcertificate.html#subjectInfo >> >> Getting the DN as a string and then parsing it to get the information >> is likely to be slow, and risks mishandling strange DNs that are >> deliberately crafted to be mishandled. For example many tools get >> repeated elements like multiple CNs wrong, to say nothing of >> deliberately strange ones. > > > No this what I meant. What I meant is to get a single string and > treat it as being "the full name", rather than getting each field of > DN in separate. But since you have this multiple strings requirement > it doesn't look practical. Yeah, that really wouldn't be sufficient here. The code I have will do the job, and with the function to convert to human readable names would work just fine. > >>> ?It appears there's another way to get this info >>> ?gnutls_x509_crt_get_subject() no idea if this is a better mechanism at this >>> ?time. >>> If less string comparisons is your goal this looks like an alternative. However, >>> unless you expect millions of DN queries I wouldn't worry about string >>> comparisons. >>> Its impact would be minimal to the cost of DER decoding overhead. >> Yeah, I haven't benchmarked anything, so this is most likely correct. >> It just seems a bit daft to convert the oid to a string, then do a >> string comparison just in order to map something like the country oid >> back to 'C'. > > > It can be optimized, e.g. using a hash table, but given that we support a > handful of DN OIDs, it doesn't really make sense. If it proves to be a > bottleneck we reconsider. I think right now there's no real evidence that this is really any kind of real world impact, so I totally agree that there's no point in expending effort here right now. Cheers Rich. From snigdhamukherjee at bel.co.in Fri Jan 13 09:40:50 2012 From: snigdhamukherjee at bel.co.in (snigdhamukherjee at bel.co.in) Date: Fri, 13 Jan 2012 14:10:50 +0530 Subject: configure cannot find -lhogweed Message-ID: <16d7d9d0831dacb21342b701af38416b.squirrel@mail.bel.co.in> Hi all, I was using gnutls 2.10 and decided to upgrade to 3.0.11 for its DTLS features. But gnutls 3.0.11 fails to configure on my RHEL 6.0. I have installed nettle 2.4 as follows ./configure --prefix=/usr --disable-openssl --enable-shared The nettle shared objects are present in /usr/lib as libnettle.a libnettle.so -> libnettle.so.4.3 libnettle.so.4 -> libnettle.so.4.3 libnettle.so.4.3 The config.log for gnutls gave the following error configure:8244: checking whether to use nettle configure:8247: result: yes configure:8742: checking for libnettle configure:8764: gcc -std=gnu99 -o conftest -g -O2?? conftest.c? /usr/local/lib/libnettle.so -lhogweed -lgmp -Wl,-rpath -Wl,/usr/local/lib >&5 /usr/bin/ld: cannot find -lhogweed collect2: ld returned 1 exit status configure:8764: $? = 1 I checked the system, there is no hogweed.so or hogweed.a. Then I checked nettle manual, It says "Nettle actually consists of two libraries, ‘libnettle’ and ‘libhogweed’. The ‘libhogweed’ library contains those functions of Nettle that uses bignum operations, and depends on the GMP library." But I downloaded nettle 2.4? from http://www.lysator.liu.se/~nisse/nettle/ and it contains bignum.c, etcetera but no hogweed. How do I compile gnutls??? Snigdha Mukherjee Please send mail to @bel.co.in only Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Bharat Electronics or support at bel.co.in immediately and destroy all copies of this message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Jan 13 15:31:53 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 13 Jan 2012 15:31:53 +0100 Subject: configure cannot find -lhogweed In-Reply-To: <16d7d9d0831dacb21342b701af38416b.squirrel@mail.bel.co.in> References: <16d7d9d0831dacb21342b701af38416b.squirrel@mail.bel.co.in> Message-ID: On Fri, Jan 13, 2012 at 9:40 AM, wrote: > Hi all, > I was using gnutls 2.10 and decided to upgrade to 3.0.11 for its DTLS > features. > But gnutls 3.0.11 fails to configure on my RHEL 6.0. > I have installed nettle 2.4 as follows > ./configure --prefix=/usr --disable-openssl --enable-shared > The nettle shared objects are present in /usr/lib as > libnettle.a > libnettle.so -> libnettle.so.4.3 > libnettle.so.4 -> libnettle.so.4.3 > libnettle.so.4.3 Nettle does not build libhogweed if you don't have the gmp library available. Most probably you need to install gmp and reconfigure nettle. regards, Nikos From skawaii at gmail.com Fri Jan 13 21:44:40 2012 From: skawaii at gmail.com (Jason Cooper) Date: Fri, 13 Jan 2012 15:44:40 -0500 Subject: Error when using an encrypted private key Message-ID: I'm using Linux Mint 12, which comes with GnuTLS 2.10.5. I'm working on configuring Git with https. On Linux Mint, Git is using GnuTLS under the hood, so I'm hoping this is the right place to get help. Basically, what I'm seeing is that my requests never get to the server when I use an encrypted private key. I started using gnutls-cli to debug and this is what I'm seeing: $ gnutls-cli -V --x509certfile usercert.pem --x509keyfile userkey.pem titan.cloud.company.com Processed 1 client certificates... *** Error loading key file: ASN1 parser: Error in TAG. If I use an unencrypted private key, then the connection is successfully made: $ gnutls-cli -V --x509certfile usercert.pem --x509keyfile userkey2.pem titan.cloud.company.com Processed 1 client certificates... Processed 1 client X.509 certificates... Resolving 'titan.cloud.company.com'... Connecting to '192.169.2.1:443'... .... What I'm really wondering is can I use encrypted keys with GnuTLS 2.10.5? If so, any hints on what else could be the problem? I'd really prefer to not have my private key stored in the clear. Thanks for the help, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sat Jan 14 09:51:59 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 14 Jan 2012 09:51:59 +0100 Subject: Error when using an encrypted private key In-Reply-To: References: Message-ID: <4F11422F.5090807@gnutls.org> On 01/13/2012 09:44 PM, Jason Cooper wrote: > I'm using Linux Mint 12, which comes with GnuTLS 2.10.5. I'm working > on configuring Git with https. On Linux Mint, Git is using GnuTLS > under the hood, so I'm hoping this is the right place to get help. Hellom GnuTLS is a library. How it is being used depends on the application. [...] > What I'm really wondering is can I use encrypted keys with GnuTLS > 2.10.5? If so, any hints on what else could be the problem? I'd > really prefer to not have my private key stored in the clear. How did you encrypt your private key? GnuTLS supports two types of encrypted keys. PKCS #8 and PKCS #12 [0]. btw. gnutls-cli doesn't support encrypted keys, use certtool to read them. [0]. http://www.gnu.org/software/gnutls/manual/html_node/Managing-encrypted-keys.html regards, Nikos From rich at kde.org Sun Jan 15 11:23:59 2012 From: rich at kde.org (Richard Moore) Date: Sun, 15 Jan 2012 10:23:59 +0000 Subject: Further experiments with using GnuTLS in Qt Message-ID: Hi, Following on from my previous mail about using the certificate parts of GnuTLS with Qt, I've just written a fairly detailed blog post about the results of writing the code needed to use the actual SSL/TLS parts too. It's at http://blogs.kde.org/node/4523 if anyone wants to take a look. Cheers Rich. From skawaii at gmail.com Tue Jan 17 01:04:57 2012 From: skawaii at gmail.com (Jason Cooper) Date: Mon, 16 Jan 2012 19:04:57 -0500 Subject: Error when using an encrypted private key In-Reply-To: <4F11422F.5090807@gnutls.org> References: <4F11422F.5090807@gnutls.org> Message-ID: <34676BD6A4AC46DE8F02C5554D45E728@gmail.com> > On Sat, Jan 14, 2012 at 3:51 AM, Nikos Mavrogiannopoulos wrote: > > On 01/13/2012 09:44 PM, Jason Cooper wrote: > > > > > I'm using Linux Mint 12, which comes with GnuTLS 2.10.5. I'm working > > > on configuring Git with https. On Linux Mint, Git is using GnuTLS > > > under the hood, so I'm hoping this is the right place to get help. > > > > > > Hellom > > GnuTLS is a library. How it is being used depends on > > the application. > > > > [...] > > > > > What I'm really wondering is can I use encrypted keys with GnuTLS > > > > > 2.10.5? If so, any hints on what else could be the problem? I'd > > > really prefer to not have my private key stored in the clear. > > > > > > How did you encrypt your private key? GnuTLS supports two types of > > encrypted keys. PKCS #8 and PKCS #12 [0]. > > Ah, well that might be the problem. I do have a PKCS#12 file, but it's both my private key and public cert. I export my private key from that using OpenSSL (openssl pkcs12 -nocerts -in mycert.p12 -out userkey.pem), but it sounds like I need to export that as a PKCS#8 or PKCS#12 file. > > Good to know. Thanks for the info. > > > > > > [0]. > > http://www.gnu.org/software/gnutls/manual/html_node/Managing-encrypted-keys.html > > > > regards, > > Nikos I exported my private key as PKCS#8, but am still getting the same error. The only thing that is currently working for me is to use my unencrypted private key. Any ideas why this might be? Again, I'm using Git 1.7.8.3 w/ GnuTLS 2.10.5 on Linux Mint 12. Thanks for your help, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Jan 17 20:07:46 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Jan 2012 20:07:46 +0100 Subject: Error when using an encrypted private key In-Reply-To: <34676BD6A4AC46DE8F02C5554D45E728@gmail.com> References: <4F11422F.5090807@gnutls.org> <34676BD6A4AC46DE8F02C5554D45E728@gmail.com> Message-ID: <4F15C702.7090809@gnutls.org> On 01/17/2012 01:04 AM, Jason Cooper wrote: >> Ah, well that might be the problem. I do have a PKCS#12 file, but >> it's both my private key and public cert. I export my private key >> from that using OpenSSL (openssl pkcs12 -nocerts -in mycert.p12 >> -out userkey.pem), but it sounds like I need to export that as a >> PKCS#8 or PKCS#12 file. Good to know. Thanks for the info. [...] > I exported my private key as PKCS#8, but am still getting the same > error. The only thing that is currently working for me is to use my > unencrypted private key. Any ideas why this might be? I believe you should check with the developers of git. Even if gnutls supports encrypted key, programs might not use that functionality. regards, Nikos From simon at josefsson.org Fri Jan 20 14:36:58 2012 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 20 Jan 2012 14:36:58 +0100 Subject: GnuTLS 3.0.12 Message-ID: <874nvq1on9.fsf@latte.josefsson.org> This release adds OCSP functionality to GnuTLS, and some other fixes. * Version 3.0.12 (released 2012-01-20) ** libgnutls: Added OCSP support. There is a new header file gnutls/ocsp.h and a set of new functions under the gnutls_ocsp namespace. Currently the functionality provided is to parse and extract information from OCSP requests/responses, to generate OCSP requests and to verify OCSP responses. See the manual for more information. Run ./configure with --disable-ocsp to build GnuTLS without OCSP support. This work was sponsored by Smoothwall . ** ocsptool: Added new command line tool. The tool can parse OCSP request/responses, generate OCSP requests and verify OCSP responses. See the manual for more information. ** certtool: --outder option now works for private and public keys as well. ** libgnutls: Added error code GNUTLS_E_NO_PRIORITIES_WERE_SET to warn when no or insufficient priorities were set. ** libgnutls: Corrected an alignment issue in ECDH key generation which prevented some keys from being correctly aligned in rare circumstances. ** libgnutls: Corrected memory leaks in DH parameter generation and ecc_projective_check_point(). ** libgnutls: Added gnutls_x509_dn_oid_name() to return a descriptive name of a DN OID. ** API and ABI modifications: gnutls_pubkey_encrypt_data: Added gnutls_x509_dn_oid_name: Added gnutls_session_resumption_requested: Added gnutls/ocsp.h: Added new header file. gnutls_ocsp_print_formats_t: Added new type. gnutls_ocsp_resp_status_t: Added new type. gnutls_ocsp_cert_status_t: Added new type. gnutls_x509_crl_reason_t: Added new type. gnutls_ocsp_req_add_cert: Added. gnutls_ocsp_req_add_cert_id: Added. gnutls_ocsp_req_deinit: Added. gnutls_ocsp_req_export: Added. gnutls_ocsp_req_get_cert_id: Added. gnutls_ocsp_req_get_extension: Added. gnutls_ocsp_req_get_nonce: Added. gnutls_ocsp_req_get_version: Added. gnutls_ocsp_req_import: Added. gnutls_ocsp_req_init: Added. gnutls_ocsp_req_print: Added. gnutls_ocsp_req_randomize_nonce: Added. gnutls_ocsp_req_set_extension: Added. gnutls_ocsp_req_set_nonce: Added. gnutls_ocsp_resp_deinit: Added. gnutls_ocsp_resp_export: Added. gnutls_ocsp_resp_get_certs: Added. gnutls_ocsp_resp_get_extension: Added. gnutls_ocsp_resp_get_nonce: Added. gnutls_ocsp_resp_get_produced: Added. gnutls_ocsp_resp_get_responder: Added. gnutls_ocsp_resp_get_response: Added. gnutls_ocsp_resp_get_signature: Added. gnutls_ocsp_resp_get_signature_algorithm: Added. gnutls_ocsp_resp_get_single: Added. gnutls_ocsp_resp_get_status: Added. gnutls_ocsp_resp_get_version: Added. gnutls_ocsp_resp_import: Added. gnutls_ocsp_resp_init: Added. gnutls_ocsp_resp_print: Added. gnutls_ocsp_resp_verify: Added. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.12.tar.xz Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.12.tar.xz.sig pub 1280R/B565716F 2002-05-05 [expires: 2013-05-10] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2013-05-10] Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 424 bytes Desc: not available URL: From symack at gmail.com Tue Jan 31 23:40:48 2012 From: symack at gmail.com (Nick Khamis) Date: Tue, 31 Jan 2012 17:40:48 -0500 Subject: Libnettle 2.4 was not found Message-ID: Hello Everyone, I am using the latest version of Debian. With lib nettle 2.4 installed: ls /usr/lib/ libnettle.a libnettle.so libnettle.so.4 libnettle.so.4.3 When compiling GNU tls, I am getting the libnettle 2.4 not found. I tried: ./configure --prefix=/usr ./configure --prefix=/usr --with-libnettle-prefix=/usr And got the same error Thanks in Advance, Nicholas.