From David.M.Marx at Oracle.Com Sun Feb 1 07:06:16 2015 From: David.M.Marx at Oracle.Com (David Marx) Date: Sat, 31 Jan 2015 22:06:16 -0800 Subject: [gnutls-devel] Compilation error with gnutls src/common.c Message-ID: <54CDC258.4000408@Oracle.Com> I get the following compilation error when trying to compile gnutls 3.3 with the Solarisstudio12.3 compiler. CC common.o "/scratch/dmmarx/12a/u/components/gnutls/gnutls-3.3.12/src/common.c", line 625: void function cannot return value The function print_cert_info returns void, and the function print_cert_info2 returns void. I think gcc allows return of a void as an extension, but it seems our compiler doesn't. The top of the gnutls tree appears to be the same code. I suggest the following patch. Thanks. Scapen-Csx12-0[63]% cat voidreturn.patch --- gnutls-3.3.12/src/common.c Sat Jan 3 09:59:47 2015 +++ gnutls-3.3.12/src/common.c Sat Jan 31 21:05:53 2015 @@ -622,7 +622,7 @@ void print_cert_info(gnutls_session_t session, int verbose, int print_cert) { - return print_cert_info2(session, verbose, stdout, print_cert); + print_cert_info2(session, verbose, stdout, print_cert); } void print_cert_info2(gnutls_session_t session, int verbose, FILE *out, int print_cert) From nmav at gnutls.org Sun Feb 1 13:37:23 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 1 Feb 2015 13:37:23 +0100 Subject: [gnutls-devel] Compilation error with gnutls src/common.c In-Reply-To: <54CDC258.4000408@Oracle.Com> References: <54CDC258.4000408@Oracle.Com> Message-ID: Fix applied, thanks. On Sun, Feb 1, 2015 at 7:06 AM, David Marx wrote: > I get the following compilation error when trying to compile gnutls 3.3 > with the Solarisstudio12.3 compiler. > CC common.o > "/scratch/dmmarx/12a/u/components/gnutls/gnutls-3.3.12/src/common.c", line > 625: > void function cannot return value > The function print_cert_info returns void, and the function print_cert_info2 > returns void. > I think gcc allows return of a void as an extension, but it seems our > compiler doesn't. > The top of the gnutls tree appears to be the same code. I suggest the > following patch. > > Thanks. > > Scapen-Csx12-0[63]% cat voidreturn.patch > --- gnutls-3.3.12/src/common.c Sat Jan 3 09:59:47 2015 > +++ gnutls-3.3.12/src/common.c Sat Jan 31 21:05:53 2015 > @@ -622,7 +622,7 @@ > > void print_cert_info(gnutls_session_t session, int verbose, int print_cert) > { > - return print_cert_info2(session, verbose, stdout, print_cert); > + print_cert_info2(session, verbose, stdout, print_cert); > } > > void print_cert_info2(gnutls_session_t session, int verbose, FILE *out, int > print_cert) > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From tim.ruehsen at gmx.de Mon Feb 2 16:27:11 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 02 Feb 2015 16:27:11 +0100 Subject: [gnutls-devel] [PATCH] OCSP check the whole cert chain In-Reply-To: References: <4350608.UCMoa1nDjP@blitz-lx> <2024118.j4zEklUhuh@debian> Message-ID: <2328920.APqMIzIEm7@blitz-lx> On Monday 19 January 2015 15:33:47 Nikos Mavrogiannopoulos wrote: > On Sat, Jan 17, 2015 at 2:55 PM, Tim R?hsen wrote: > >> > (There's an RFC for stapling multiple certs in progress.) - Matt > >> > Nordhoff" > >> > To me, this sounds reasonable. Shouldn't the ocsptool loop over the > >> > complete cert list and check each cert ? What do you think ? > >> > >> Indeed, that would be the right thing to do. If there is a patch for > >> that I'll apply it. > > > > Hi Nikos, > > I made up a first patch to check the whole cert chain. > > Not sure what to do for e.g. www.google.com where the last cert in the > > chain is not verifiable via OCSP. > > Thank you. I've applied a modified patch, where this is skipped. With > the updated patch, we check OCSP for the certificates we have > information to use. For the others, we simply cannot check them. Hi Nikos, please have a look at src/cli.c/cert_verify_ocsp(). You changed the last line in this function in a way, that if there are revoked certs in the chain but at least one not-revoked cert, the function returns 'ok'. Which it should not and which it did not in my patch. Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Tue Feb 3 12:15:28 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 03 Feb 2015 12:15:28 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' Message-ID: <6442791.4l3za9Y0AT@blitz-lx> Hi Nikos, I finally found a bit of time (sigh). I rebased ocsp2 on master and added some lines of code to gnutls-cli to check RFC6961 (OCSP multi-stapling) status. I tested with yahoo.com which I now to support OCSP (single-)stapling and had a look with wireshark 1.12.1. (Using 'src/gnutls-cli -d2 --ocsp yahoo.com') gnutls-cli 'Client Hello' has both 'status_request' and 'status_request_v2' inside. But Wireshark says 'Malformed Packet' and I am not sure what it doesn't like (The 'status_request_v2' has a 'request extension length' of 5. Not sure if this is correct.) The 'Server Hello' has a 'status_request' inside (type 5, length 0). But gnutls_ocsp_status_request_is_checked() returns 0. This seems wrong in libgnutls... I would expect a return value of 1 in this case. Could you have a look at it ? Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Tue Feb 3 13:03:09 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 03 Feb 2015 13:03:09 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <6442791.4l3za9Y0AT@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> Message-ID: <19767451.Yd2o3GP73D@blitz-lx> Sorry, forgot the patch for gnutls-cli (branch 'ocsp2'). Tim On Tuesday 03 February 2015 12:15:28 Tim Ruehsen wrote: > Hi Nikos, > > I finally found a bit of time (sigh). > > I rebased ocsp2 on master and added some lines of code to gnutls-cli to > check RFC6961 (OCSP multi-stapling) status. > > I tested with yahoo.com which I now to support OCSP (single-)stapling and > had a look with wireshark 1.12.1. (Using 'src/gnutls-cli -d2 --ocsp > yahoo.com') > > gnutls-cli 'Client Hello' has both 'status_request' and 'status_request_v2' > inside. But Wireshark says 'Malformed Packet' and I am not sure what it > doesn't like (The 'status_request_v2' has a 'request extension length' of 5. > Not sure if this is correct.) > > The 'Server Hello' has a 'status_request' inside (type 5, length 0). > But gnutls_ocsp_status_request_is_checked() returns 0. > This seems wrong in libgnutls... I would expect a return value of 1 in this > case. > > Could you have a look at it ? > > Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-OCSP-multi-stapling-test-code.patch Type: text/x-patch Size: 3033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Wed Feb 4 09:31:46 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 09:31:46 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <6442791.4l3za9Y0AT@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> Message-ID: <4081374.5TfsV8B0SP@blitz-lx> On Tuesday 03 February 2015 12:15:28 Tim Ruehsen wrote: > The 'Server Hello' has a 'status_request' inside (type 5, length 0). > But gnutls_ocsp_status_request_is_checked() returns 0. > This seems wrong in libgnutls... I would expect a return value of 1 in this > case. Here is a fix. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-OCSP-stapling-detection-for-status_request_v2-ex.patch Type: text/x-patch Size: 1314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Feb 4 10:15:26 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 10:15:26 +0100 Subject: [gnutls-devel] [PATCH] OCSP check the whole cert chain In-Reply-To: <2328920.APqMIzIEm7@blitz-lx> References: <4350608.UCMoa1nDjP@blitz-lx> <2024118.j4zEklUhuh@debian> <2328920.APqMIzIEm7@blitz-lx> Message-ID: <1423041326.2052.1.camel@gnutls.org> On Mon, 2015-02-02 at 16:27 +0100, Tim Ruehsen wrote: > please have a look at src/cli.c/cert_verify_ocsp(). > You changed the last line in this function in a way, that if there are revoked > certs in the chain but at least one not-revoked cert, the function returns > 'ok'. Which it should not and which it did not in my patch. Indeed, I was trying to address the issue of having unknown status in an OCSP response. I'll have to treat revoked and unknown as different. regards, Nikos From nmav at gnutls.org Wed Feb 4 10:54:22 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 10:54:22 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <6442791.4l3za9Y0AT@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> Message-ID: <1423043662.2052.2.camel@gnutls.org> On Tue, 2015-02-03 at 12:15 +0100, Tim Ruehsen wrote: > Hi Nikos, > > I finally found a bit of time (sigh). > > I rebased ocsp2 on master and added some lines of code to gnutls-cli to check > RFC6961 (OCSP multi-stapling) status. > > I tested with yahoo.com which I now to support OCSP (single-)stapling and had > a look with wireshark 1.12.1. (Using 'src/gnutls-cli -d2 --ocsp yahoo.com') > > gnutls-cli 'Client Hello' has both 'status_request' and 'status_request_v2' > inside. But Wireshark says 'Malformed Packet' and I am not sure what it > doesn't like (The 'status_request_v2' has a 'request extension length' of 5. > Not sure if this is correct.) The message created was wrong. I've now fixed that. It's nice that wireshark parses that extension. regards, Nikos From nmav at gnutls.org Wed Feb 4 11:01:19 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 11:01:19 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <4081374.5TfsV8B0SP@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <4081374.5TfsV8B0SP@blitz-lx> Message-ID: <1423044079.2052.4.camel@gnutls.org> On Wed, 2015-02-04 at 09:31 +0100, Tim Ruehsen wrote: > On Tuesday 03 February 2015 12:15:28 Tim Ruehsen wrote: > > The 'Server Hello' has a 'status_request' inside (type 5, length 0). > > But gnutls_ocsp_status_request_is_checked() returns 0. > > This seems wrong in libgnutls... I would expect a return value of 1 in this > > case. > > Here is a fix. I don't think that this is related. However, at the current state the packets generated seem to be in accordance with wireshark, so as far as I understand, it remains to properly support it on the server side by enhancing the ocsptool to generate a combined status request, as well as accounting the multiple OCSP responses received on peer's certificate verification. regards, Nikos From tim.ruehsen at gmx.de Wed Feb 4 11:05:51 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 11:05:51 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <1423044079.2052.4.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <4081374.5TfsV8B0SP@blitz-lx> <1423044079.2052.4.camel@gnutls.org> Message-ID: <2531509.GBs8RoR3Xk@blitz-lx> On Wednesday 04 February 2015 11:01:19 Nikos Mavrogiannopoulos wrote: > On Wed, 2015-02-04 at 09:31 +0100, Tim Ruehsen wrote: > > On Tuesday 03 February 2015 12:15:28 Tim Ruehsen wrote: > > > The 'Server Hello' has a 'status_request' inside (type 5, length 0). > > > But gnutls_ocsp_status_request_is_checked() returns 0. > > > This seems wrong in libgnutls... I would expect a return value of 1 in > > > this > > > case. > > > > Here is a fix. > > I don't think that this is related. However, at the current state the > packets generated seem to be in accordance with wireshark, so as far as > I understand, it remains to properly support it on the server side by > enhancing the ocsptool to generate a combined status request, as well as > accounting the multiple OCSP responses received on peer's certificate > verification. The fix just handles the case where status_request and status_request_v2 both are sent (client hello), but the answer (server hello) just includes status_request. I guess, that will be pretty common the next few months/years. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Feb 4 11:22:29 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 11:22:29 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <2531509.GBs8RoR3Xk@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <4081374.5TfsV8B0SP@blitz-lx> <1423044079.2052.4.camel@gnutls.org> <2531509.GBs8RoR3Xk@blitz-lx> Message-ID: <1423045349.2052.6.camel@gnutls.org> On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > I don't think that this is related. However, at the current state the > > packets generated seem to be in accordance with wireshark, so as far as > > I understand, it remains to properly support it on the server side by > > enhancing the ocsptool to generate a combined status request, as well as > > accounting the multiple OCSP responses received on peer's certificate > > verification. > The fix just handles the case where status_request and status_request_v2 both > are sent (client hello), but the answer (server hello) just includes > status_request. > I guess, that will be pretty common the next few months/years. Ok, thanks. I've handled it a bit differently. From tim.ruehsen at gmx.de Wed Feb 4 11:35:44 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 11:35:44 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <1423045349.2052.6.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <2531509.GBs8RoR3Xk@blitz-lx> <1423045349.2052.6.camel@gnutls.org> Message-ID: <18977848.CJCBn2uspY@blitz-lx> On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos wrote: > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > > I don't think that this is related. However, at the current state the > > > packets generated seem to be in accordance with wireshark, so as far as > > > I understand, it remains to properly support it on the server side by > > > enhancing the ocsptool to generate a combined status request, as well as > > > accounting the multiple OCSP responses received on peer's certificate > > > verification. > > > > The fix just handles the case where status_request and status_request_v2 > > both are sent (client hello), but the answer (server hello) just includes > > status_request. > > I guess, that will be pretty common the next few months/years. > > Ok, thanks. I've handled it a bit differently. Sorry, Nikos. I just pulled it and it does not work. gnutls_ocsp_status_request_is_checked still returns 0 though there is a status_request answer. Just apply my first patch 0001-add-OCSP-multi-stapling-test-code.patch ... it just adds some printf to show that. My patch handles it... Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Feb 4 12:34:15 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 12:34:15 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <18977848.CJCBn2uspY@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <2531509.GBs8RoR3Xk@blitz-lx> <1423045349.2052.6.camel@gnutls.org> <18977848.CJCBn2uspY@blitz-lx> Message-ID: <1423049655.2052.8.camel@gnutls.org> On Wed, 2015-02-04 at 11:35 +0100, Tim Ruehsen wrote: > On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > > > I don't think that this is related. However, at the current state the > > > > packets generated seem to be in accordance with wireshark, so as far as > > > > I understand, it remains to properly support it on the server side by > > > > enhancing the ocsptool to generate a combined status request, as well as > > > > accounting the multiple OCSP responses received on peer's certificate > > > > verification. > > > > > > The fix just handles the case where status_request and status_request_v2 > > > both are sent (client hello), but the answer (server hello) just includes > > > status_request. > > > I guess, that will be pretty common the next few months/years. > > > > Ok, thanks. I've handled it a bit differently. > > Sorry, Nikos. > I just pulled it and it does not work. > gnutls_ocsp_status_request_is_checked still returns 0 though there is a > status_request answer. > Just apply my first patch 0001-add-OCSP-multi-stapling-test-code.patch ... it > just adds some printf to show that. Ok. It was only working when the V2 request wasn't sent. I've now updated the fix to work in all scenarios. regards, Nikos > > My patch handles it... > > Tim From tim.ruehsen at gmx.de Wed Feb 4 14:23:37 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 14:23:37 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <1423049655.2052.8.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <18977848.CJCBn2uspY@blitz-lx> <1423049655.2052.8.camel@gnutls.org> Message-ID: <1881282.ertFaNIg8M@blitz-lx> On Wednesday 04 February 2015 12:34:15 Nikos Mavrogiannopoulos wrote: > On Wed, 2015-02-04 at 11:35 +0100, Tim Ruehsen wrote: > > On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos wrote: > > > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > > > > I don't think that this is related. However, at the current state > > > > > the > > > > > packets generated seem to be in accordance with wireshark, so as far > > > > > as > > > > > I understand, it remains to properly support it on the server side > > > > > by > > > > > enhancing the ocsptool to generate a combined status request, as > > > > > well as > > > > > accounting the multiple OCSP responses received on peer's > > > > > certificate > > > > > verification. > > > > > > > > The fix just handles the case where status_request and > > > > status_request_v2 > > > > both are sent (client hello), but the answer (server hello) just > > > > includes > > > > status_request. > > > > I guess, that will be pretty common the next few months/years. > > > > > > Ok, thanks. I've handled it a bit differently. > > > > Sorry, Nikos. > > I just pulled it and it does not work. > > gnutls_ocsp_status_request_is_checked still returns 0 though there is a > > status_request answer. > > Just apply my first patch 0001-add-OCSP-multi-stapling-test-code.patch ... > > it just adds some printf to show that. > > Ok. It was only working when the V2 request wasn't sent. I've now > updated the fix to work in all scenarios. Thanks, Nikos ! IMO, there are two little glitch in your code. Guess idx==0 and the first ret becomes < 0... this is not catched, than you will use priv = epriv.ptr though epriv is uninitialized (or NULL). Looks like a crash in this case. Also in if (idx == 0 && (ret < 0 || ((status_request_ext_st*)epriv.ptr)- >responses_size == 0)) { 'epriv.ptr' should be checked for NULL (else crash). Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Feb 4 14:33:58 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 14:33:58 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <1881282.ertFaNIg8M@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <18977848.CJCBn2uspY@blitz-lx> <1423049655.2052.8.camel@gnutls.org> <1881282.ertFaNIg8M@blitz-lx> Message-ID: <1423056838.2052.10.camel@gnutls.org> On Wed, 2015-02-04 at 14:23 +0100, Tim Ruehsen wrote: > On Wednesday 04 February 2015 12:34:15 Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-02-04 at 11:35 +0100, Tim Ruehsen wrote: > > > On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos wrote: > > > > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > > > > > I don't think that this is related. However, at the current state > > > > > > the > > > > > > packets generated seem to be in accordance with wireshark, so as far > > > > > > as > > > > > > I understand, it remains to properly support it on the server side > > > > > > by > > > > > > enhancing the ocsptool to generate a combined status request, as > > > > > > well as > > > > > > accounting the multiple OCSP responses received on peer's > > > > > > certificate > > > > > > verification. > > > > > > > > > > The fix just handles the case where status_request and > > > > > status_request_v2 > > > > > both are sent (client hello), but the answer (server hello) just > > > > > includes > > > > > status_request. > > > > > I guess, that will be pretty common the next few months/years. > > > > > > > > Ok, thanks. I've handled it a bit differently. > > > > > > Sorry, Nikos. > > > I just pulled it and it does not work. > > > gnutls_ocsp_status_request_is_checked still returns 0 though there is a > > > status_request answer. > > > Just apply my first patch 0001-add-OCSP-multi-stapling-test-code.patch ... > > > it just adds some printf to show that. > > > > Ok. It was only working when the V2 request wasn't sent. I've now > > updated the fix to work in all scenarios. > > Thanks, Nikos ! > > IMO, there are two little glitch in your code. > Guess idx==0 and the first ret becomes < 0... this is not catched, than you > will use priv = epriv.ptr though epriv is uninitialized (or NULL). > Looks like a crash in this case. Wouldn't that be caught by: if (idx == 0 && (ret < 0 || ((status_request_ext_st*)epriv.ptr)->responses_size == 0)) ? (the idx == 0 && ret < 0 part). > Also in > if (idx == 0 && (ret < 0 || ((status_request_ext_st*)epriv.ptr)- > >responses_size == 0)) { > 'epriv.ptr' should be checked for NULL (else crash). Thanks, I've updated the patch. regards, Nikos From tim.ruehsen at gmx.de Wed Feb 4 14:44:45 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 14:44:45 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <1423056838.2052.10.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <1881282.ertFaNIg8M@blitz-lx> <1423056838.2052.10.camel@gnutls.org> Message-ID: <2615014.rDX4beK6Qa@blitz-lx> On Wednesday 04 February 2015 14:33:58 Nikos Mavrogiannopoulos wrote: > On Wed, 2015-02-04 at 14:23 +0100, Tim Ruehsen wrote: > > On Wednesday 04 February 2015 12:34:15 Nikos Mavrogiannopoulos wrote: > > > On Wed, 2015-02-04 at 11:35 +0100, Tim Ruehsen wrote: > > > > On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos wrote: > > > > > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > > > > > > I don't think that this is related. However, at the current > > > > > > > state > > > > > > > the > > > > > > > packets generated seem to be in accordance with wireshark, so as > > > > > > > far > > > > > > > as > > > > > > > I understand, it remains to properly support it on the server > > > > > > > side > > > > > > > by > > > > > > > enhancing the ocsptool to generate a combined status request, as > > > > > > > well as > > > > > > > accounting the multiple OCSP responses received on peer's > > > > > > > certificate > > > > > > > verification. > > > > > > > > > > > > The fix just handles the case where status_request and > > > > > > status_request_v2 > > > > > > both are sent (client hello), but the answer (server hello) just > > > > > > includes > > > > > > status_request. > > > > > > I guess, that will be pretty common the next few months/years. > > > > > > > > > > Ok, thanks. I've handled it a bit differently. > > > > > > > > Sorry, Nikos. > > > > I just pulled it and it does not work. > > > > gnutls_ocsp_status_request_is_checked still returns 0 though there is > > > > a > > > > status_request answer. > > > > Just apply my first patch 0001-add-OCSP-multi-stapling-test-code.patch > > > > ... > > > > it just adds some printf to show that. > > > > > > Ok. It was only working when the V2 request wasn't sent. I've now > > > updated the fix to work in all scenarios. > > > > Thanks, Nikos ! > > > > IMO, there are two little glitch in your code. > > Guess idx==0 and the first ret becomes < 0... this is not catched, than > > you > > will use priv = epriv.ptr though epriv is uninitialized (or NULL). > > Looks like a crash in this case. > > Wouldn't that be caught by: > if (idx == 0 && (ret < 0 || > ((status_request_ext_st*)epriv.ptr)->responses_size == 0)) > ? (the idx == 0 && ret < 0 part). Yes, I meant idx!=0 and first ret < 0. Sorry. Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Wed Feb 4 14:47:42 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 14:47:42 +0100 Subject: [gnutls-devel] gnutls-cli OCSP test code for branch 'ocsp2' In-Reply-To: <2615014.rDX4beK6Qa@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <1423056838.2052.10.camel@gnutls.org> <2615014.rDX4beK6Qa@blitz-lx> Message-ID: <2896293.0aIDFGDi3V@blitz-lx> On Wednesday 04 February 2015 14:44:45 Tim Ruehsen wrote: > On Wednesday 04 February 2015 14:33:58 Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-02-04 at 14:23 +0100, Tim Ruehsen wrote: > > > On Wednesday 04 February 2015 12:34:15 Nikos Mavrogiannopoulos wrote: > > > > On Wed, 2015-02-04 at 11:35 +0100, Tim Ruehsen wrote: > > > > > On Wednesday 04 February 2015 11:22:29 Nikos Mavrogiannopoulos wrote: > > > > > > On Wed, 2015-02-04 at 11:05 +0100, Tim Ruehsen wrote: > > > > > > > > I don't think that this is related. However, at the current > > > > > > > > state > > > > > > > > the > > > > > > > > packets generated seem to be in accordance with wireshark, so > > > > > > > > as > > > > > > > > far > > > > > > > > as > > > > > > > > I understand, it remains to properly support it on the server > > > > > > > > side > > > > > > > > by > > > > > > > > enhancing the ocsptool to generate a combined status request, > > > > > > > > as > > > > > > > > well as > > > > > > > > accounting the multiple OCSP responses received on peer's > > > > > > > > certificate > > > > > > > > verification. > > > > > > > > > > > > > > The fix just handles the case where status_request and > > > > > > > status_request_v2 > > > > > > > both are sent (client hello), but the answer (server hello) just > > > > > > > includes > > > > > > > status_request. > > > > > > > I guess, that will be pretty common the next few months/years. > > > > > > > > > > > > Ok, thanks. I've handled it a bit differently. > > > > > > > > > > Sorry, Nikos. > > > > > I just pulled it and it does not work. > > > > > gnutls_ocsp_status_request_is_checked still returns 0 though there > > > > > is > > > > > a > > > > > status_request answer. > > > > > Just apply my first patch > > > > > 0001-add-OCSP-multi-stapling-test-code.patch > > > > > ... > > > > > it just adds some printf to show that. > > > > > > > > Ok. It was only working when the V2 request wasn't sent. I've now > > > > updated the fix to work in all scenarios. > > > > > > Thanks, Nikos ! > > > > > > IMO, there are two little glitch in your code. > > > Guess idx==0 and the first ret becomes < 0... this is not catched, than > > > you > > > will use priv = epriv.ptr though epriv is uninitialized (or NULL). > > > Looks like a crash in this case. > > > > Wouldn't that be caught by: > > if (idx == 0 && (ret < 0 || > > ((status_request_ext_st*)epriv.ptr)->responses_size == 0)) > > ? (the idx == 0 && ret < 0 part). > > Yes, I meant idx!=0 and first ret < 0. Sorry. Sorry, forget it ;-) Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Wed Feb 4 16:48:00 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 04 Feb 2015 16:48 +0100 Subject: [gnutls-devel] OCSP RFC6961 for web servers In-Reply-To: <1423044079.2052.4.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <4081374.5TfsV8B0SP@blitz-lx> <1423044079.2052.4.camel@gnutls.org> Message-ID: <3738978.RSWTO04EvW@blitz-lx> On Wednesday 04 February 2015 11:01:19 Nikos Mavrogiannopoulos wrote: > However, at the current state the > packets generated seem to be in accordance with wireshark, so as far as > I understand, it remains to properly support it on the server side by > enhancing the ocsptool to generate a combined status request, as well as > accounting the multiple OCSP responses received on peer's certificate > verification. Please help me to understand it. I thought ocsptool is to generate requests (and responses) for OCSP responders. What has this to do with the TLS extension status_request_v2 (despite the fact that a HTTPS server could use the responses to build status_request_v2 stapled responses for the 'Server Hello'). So in my understanding, we have to address the webserver people to support OCSP (multi-)stapling via GnuTLS (e.g. apache mod_gnutls or mod_ssl people). BTW, how trustworthy is OCSP stapling at all ? While ClientHello/ServerHello we are vulnerable to MITM. Couldn't this lead to a manipulated status_request answer, which tells the client that the cert is valid (not revoked) ? The only one who knows is the issuer's OCSP responder, which will be contacted by plain-text HTTP (but I guess the answer can be validated by the issuer of the issuer resp. the offline CA cert, thus no MITM thread !?). So, isn't OCSP stapling an insecure 'shortcut'... what did I miss ? Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Feb 4 17:29:33 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Feb 2015 17:29:33 +0100 Subject: [gnutls-devel] OCSP RFC6961 for web servers In-Reply-To: <3738978.RSWTO04EvW@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <4081374.5TfsV8B0SP@blitz-lx> <1423044079.2052.4.camel@gnutls.org> <3738978.RSWTO04EvW@blitz-lx> Message-ID: <1423067373.21202.1.camel@gnutls.org> On Wed, 2015-02-04 at 16:48 +0100, Tim Ruehsen wrote: > On Wednesday 04 February 2015 11:01:19 Nikos Mavrogiannopoulos wrote: > > However, at the current state the > > packets generated seem to be in accordance with wireshark, so as far as > > I understand, it remains to properly support it on the server side by > > enhancing the ocsptool to generate a combined status request, as well as > > accounting the multiple OCSP responses received on peer's certificate > > verification. > > Please help me to understand it. > > I thought ocsptool is to generate requests (and responses) for OCSP > responders. What has this to do with the TLS extension status_request_v2 > (despite the fact that a HTTPS server could use the responses to build > status_request_v2 stapled responses for the 'Server Hello'). Exactly (though, the status request response isn't sent on server hello). We need a way/tool for server operators to gather and concatenate their OCSP responses in a format gnutls will understand. ocsptool ought to do that. > So in my understanding, we have to address the webserver people to support > OCSP (multi-)stapling via GnuTLS (e.g. apache mod_gnutls or mod_ssl people). That's in addition to the above. > BTW, how trustworthy is OCSP stapling at all ? While ClientHello/ServerHello > we are vulnerable to MITM. Couldn't this lead to a manipulated status_request > answer, which tells the client that the cert is valid (not revoked) ? A modification of the handshake would be detected at the finished messages in TLS, so a MitM wouldn't work. In fact an attack which replaces an OCSP response with an other (e.g. a previous one which is still valid), would work with the HTTP OCSP requests, but not over TLS. regards, Nikos From tim.ruehsen at gmx.de Fri Feb 6 11:05:52 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 06 Feb 2015 11:05:52 +0100 Subject: [gnutls-devel] OCSP RFC6961 for web servers In-Reply-To: <1423067373.21202.1.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <3738978.RSWTO04EvW@blitz-lx> <1423067373.21202.1.camel@gnutls.org> Message-ID: <4437284.SB786FOXHf@blitz-lx> First, many thanks for your clarifications. On Wednesday 04 February 2015 17:29:33 Nikos Mavrogiannopoulos wrote: > > I thought ocsptool is to generate requests (and responses) for OCSP > > responders. What has this to do with the TLS extension status_request_v2 > > (despite the fact that a HTTPS server could use the responses to build > > status_request_v2 stapled responses for the 'Server Hello'). > > Exactly (though, the status request response isn't sent on server > hello). We need a way/tool for server operators to gather and > concatenate their OCSP responses in a format gnutls will understand. > ocsptool ought to do that. From status_request.c/_gnutls_status_request_decode_raw_resp() I can see, that the file format has already already fixed for v2. Just to be in line with you... Do you think it is appropriate to add an CLI option to ocsptool (e.g. --merge-response=file1,file2,...) to merge several response files into one file (specified by --outfile) readable by the library code ? Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Fri Feb 6 11:41:59 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 06 Feb 2015 11:41:59 +0100 Subject: [gnutls-devel] OCSP RFC6961 for web servers In-Reply-To: <4437284.SB786FOXHf@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <3738978.RSWTO04EvW@blitz-lx> <1423067373.21202.1.camel@gnutls.org> <4437284.SB786FOXHf@blitz-lx> Message-ID: <1423219319.2046.5.camel@gnutls.org> On Fri, 2015-02-06 at 11:05 +0100, Tim Ruehsen wrote: > First, many thanks for your clarifications. > > On Wednesday 04 February 2015 17:29:33 Nikos Mavrogiannopoulos wrote: > > > I thought ocsptool is to generate requests (and responses) for OCSP > > > responders. What has this to do with the TLS extension status_request_v2 > > > (despite the fact that a HTTPS server could use the responses to build > > > status_request_v2 stapled responses for the 'Server Hello'). > > > > Exactly (though, the status request response isn't sent on server > > hello). We need a way/tool for server operators to gather and > > concatenate their OCSP responses in a format gnutls will understand. > > ocsptool ought to do that. > > From status_request.c/_gnutls_status_request_decode_raw_resp() I can see, that > the file format has already already fixed for v2. > > Just to be in line with you... Do you think it is appropriate to add an CLI > option to ocsptool (e.g. --merge-response=file1,file2,...) to merge several > response files into one file (specified by --outfile) readable by the library > code ? That could be an option. In that case it will be challenging to make the merged file correspond to the certificate chain (e.g., response 0 correspond to cert 0 ...). A simpler approach may be to do something like: $ ocsptool --ask-multi mychain.pem --outfile multi.ocsp From tim.ruehsen at gmx.de Fri Feb 6 15:16:08 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 06 Feb 2015 15:16:08 +0100 Subject: [gnutls-devel] OCSP RFC6961 for web servers In-Reply-To: <1423219319.2046.5.camel@gnutls.org> References: <6442791.4l3za9Y0AT@blitz-lx> <4437284.SB786FOXHf@blitz-lx> <1423219319.2046.5.camel@gnutls.org> Message-ID: <2668814.a2D8eeEQTQ@blitz-lx> On Friday 06 February 2015 11:41:59 Nikos Mavrogiannopoulos wrote: > On Fri, 2015-02-06 at 11:05 +0100, Tim Ruehsen wrote: > > First, many thanks for your clarifications. > > > > On Wednesday 04 February 2015 17:29:33 Nikos Mavrogiannopoulos wrote: > > > > I thought ocsptool is to generate requests (and responses) for OCSP > > > > responders. What has this to do with the TLS extension > > > > status_request_v2 > > > > (despite the fact that a HTTPS server could use the responses to build > > > > status_request_v2 stapled responses for the 'Server Hello'). > > > > > > Exactly (though, the status request response isn't sent on server > > > hello). We need a way/tool for server operators to gather and > > > concatenate their OCSP responses in a format gnutls will understand. > > > ocsptool ought to do that. > > > > From status_request.c/_gnutls_status_request_decode_raw_resp() I can see, > > that the file format has already already fixed for v2. > > > > Just to be in line with you... Do you think it is appropriate to add an > > CLI > > option to ocsptool (e.g. --merge-response=file1,file2,...) to merge > > several > > response files into one file (specified by --outfile) readable by the > > library code ? > > That could be an option. In that case it will be challenging to make the > merged file correspond to the certificate chain (e.g., response 0 > correspond to cert 0 ...). A simpler approach may be to do something > like: > $ ocsptool --ask-multi mychain.pem --outfile multi.ocsp I admit, I have no idea how to create a cert chain PEM file. I have not much knowledge of web server administration. And I have not enough knowledge of the GnuTLS API (and/or data structure) to play around with 'cert chain' files. I am not sure If I have the time to take a deeper look into that. Too many other tasks waiting... Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Fri Feb 6 19:59:41 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 06 Feb 2015 19:59:41 +0100 Subject: [gnutls-devel] OCSP RFC6961 for web servers In-Reply-To: <2668814.a2D8eeEQTQ@blitz-lx> References: <6442791.4l3za9Y0AT@blitz-lx> <4437284.SB786FOXHf@blitz-lx> <1423219319.2046.5.camel@gnutls.org> <2668814.a2D8eeEQTQ@blitz-lx> Message-ID: <1423249181.7657.3.camel@gnutls.org> On Fri, 2015-02-06 at 15:16 +0100, Tim Ruehsen wrote: > > That could be an option. In that case it will be challenging to make the > > merged file correspond to the certificate chain (e.g., response 0 > > correspond to cert 0 ...). A simpler approach may be to do something > > like: > > $ ocsptool --ask-multi mychain.pem --outfile multi.ocsp > I admit, I have no idea how to create a cert chain PEM file. I have not much > knowledge of web server administration. A certificate chain is on its simplest form a certificate and its CA combined. For this particular purpose merely executing gnutls-cli --print-cert on any server would give you a chain. > And I have not enough knowledge of > the GnuTLS API (and/or data structure) to play around with 'cert chain' files. They are nothing more than a list of certificates. Nothing special about it. You could use helper functions like gnutls_x509_crt_list_import2 to help importing them, but that's all. regards, Nikos From andreas at enge.fr Sat Feb 7 16:34:06 2015 From: andreas at enge.fr (Andreas Enge) Date: Sat, 7 Feb 2015 16:34:06 +0100 Subject: [gnutls-devel] Trust store from environment variable Message-ID: <20150207153406.GA7383@debian> Hello, in GNU Guix, we currently compile GnuTLS with --with-default-trust-store-dir=/etc/ssl/certs However, with per user installation, it would be desirable if each user could define his own trust store, via an environment variable, for instance. Does this sound like a reasonable option? Some care would be needed to handle applications that are setuid root, for instance. Andreas From INVALID.NOREPLY at gnu.org Sun Feb 8 00:09:37 2015 From: INVALID.NOREPLY at gnu.org (Cedric) Date: Sat, 07 Feb 2015 23:09:37 +0000 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile Message-ID: <20150207-230936.sv80668.38050@savannah.gnu.org> URL: Summary: GnuTLS added autogen dependency pulls in Scheme/Guile Project: GnuTLS Submitted by: manday Submitted on: Sat 07 Feb 2015 11:09:36 PM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: As of somewhere between v2 and v3, GnuTLS starts to depend on autogen. It would be much desired if that dependency could be avoided, since (considering autotools is a questionable buildchain to choose for new projects these days) this comes with a dependency on Guile/Scheme. It would be nice if whatever is the reason for that new dependency could be solved by simpler means. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From bruce.korb at gmail.com Sun Feb 8 01:18:40 2015 From: bruce.korb at gmail.com (Bruce Korb) Date: Sat, 07 Feb 2015 16:18:40 -0800 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile In-Reply-To: <20150207-230936.sv80668.38050@savannah.gnu.org> References: <20150207-230936.sv80668.38050@savannah.gnu.org> Message-ID: <54D6AB60.1060005@gmail.com> On 02/07/15 15:09, Cedric wrote: > Details: > > As of somewhere between v2 and v3, GnuTLS starts to depend on autogen. It > would be much desired if that dependency could be avoided, since (considering > autotools is a questionable buildchain to choose for new projects these days) > this comes with a dependency on Guile/Scheme. > > It would be nice if whatever is the reason for that new dependency could be > solved by simpler means. Autotool use and autogen use are orthogonal. Using autogen does require Guile, but using autogen is only necessary if you are changing the options of some of the GnuTLS programs. The reasons for using it are many: http://www.gnu.org/software/autogen/manual/html_node/Features.htm From nmav at gnutls.org Sun Feb 8 10:18:18 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 08 Feb 2015 10:18:18 +0100 Subject: [gnutls-devel] Trust store from environment variable In-Reply-To: <20150207153406.GA7383@debian> References: <20150207153406.GA7383@debian> Message-ID: <1423387098.2022.1.camel@gnutls.org> On Sat, 2015-02-07 at 16:34 +0100, Andreas Enge wrote: > Hello, > > in GNU Guix, we currently compile GnuTLS with > --with-default-trust-store-dir=/etc/ssl/certs > However, with per user installation, it would be desirable if each user > could define his own trust store, via an environment variable, for instance. > Does this sound like a reasonable option? Some care would be needed to > handle applications that are setuid root, for instance. The loading of certificates from a system wide file or directory are legacy options, and they don't allow much space for improvement. The recommended way in a modern system is via the p11-kit trust module [0], which in addition to what you ask, it can allow users to also specify the purpose each CA certificate is trusted for. The p11-kit trust module is used in Fedora for few releases now, for both NSS and gnutls. regards, Nikos [0]. http://gnutls.org/manual/html_node/Verification-using-PKCS11.html From andreas at enge.fr Sun Feb 8 13:00:28 2015 From: andreas at enge.fr (Andreas Enge) Date: Sun, 8 Feb 2015 13:00:28 +0100 Subject: [gnutls-devel] Trust store from environment variable In-Reply-To: <1423387098.2022.1.camel@gnutls.org> References: <20150207153406.GA7383@debian> <1423387098.2022.1.camel@gnutls.org> Message-ID: <20150208120028.GA5557@debian> Thanks for your kind explanations! On Sun, Feb 08, 2015 at 10:18:18AM +0100, Nikos Mavrogiannopoulos wrote: > The loading of certificates from a system wide file or directory are > legacy options, and they don't allow much space for improvement. The > recommended way in a modern system is via the p11-kit trust module [0], > which in addition to what you ask, it can allow users to also specify > the purpose each CA certificate is trusted for. The p11-kit trust module > is used in Fedora for few releases now, for both NSS and gnutls. > [0]. http://gnutls.org/manual/html_node/Verification-using-PKCS11.html What I do not quite understand is how that applies to packagers for distributions. The documentation speaks about the C library interface. What about existing applications? Do they need to be patched to use this trust module? Or specially configured? Do you have a link how Fedora is handling this? Andreas From nmav at gnutls.org Sun Feb 8 14:14:50 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 08 Feb 2015 14:14:50 +0100 Subject: [gnutls-devel] Trust store from environment variable In-Reply-To: <20150208120028.GA5557@debian> References: <20150207153406.GA7383@debian> <1423387098.2022.1.camel@gnutls.org> <20150208120028.GA5557@debian> Message-ID: <1423401290.2022.3.camel@gnutls.org> On Sun, 2015-02-08 at 13:00 +0100, Andreas Enge wrote: > Thanks for your kind explanations! > > On Sun, Feb 08, 2015 at 10:18:18AM +0100, Nikos Mavrogiannopoulos wrote: > > The loading of certificates from a system wide file or directory are > > legacy options, and they don't allow much space for improvement. The > > recommended way in a modern system is via the p11-kit trust module [0], > > which in addition to what you ask, it can allow users to also specify > > the purpose each CA certificate is trusted for. The p11-kit trust module > > is used in Fedora for few releases now, for both NSS and gnutls. > > [0]. http://gnutls.org/manual/html_node/Verification-using-PKCS11.html > > What I do not quite understand is how that applies to packagers for > distributions. The documentation speaks about the C library interface. > What about existing applications? Do they need to be patched to use > this trust module? Indeed, such a section is currently missing from documentation. No applications would need to be patched for that, they should work out of the box. The Fedora change was at https://fedoraproject.org/wiki/Features/SharedSystemCertificates (note that it predates the pkcs11 trust module by gnutls and using the trust module is listed as a future goal) The process should be, (a) setup p11-kit, (b) setup p11-kit trust module, (c) configure gnutls with --with-default-trust-store-pkcs11="pkcs11:" and then all the modules marked as trusted in p11-kit configuration will be used by gnutls. The relevant packages in fedora are: http://pkgs.fedoraproject.org/cgit/p11-kit.git/ http://pkgs.fedoraproject.org/cgit/ca-certificates.git/ (the latter for update-ca-trust). regards, Nikos From andreas at enge.fr Sun Feb 8 14:25:34 2015 From: andreas at enge.fr (Andreas Enge) Date: Sun, 8 Feb 2015 14:25:34 +0100 Subject: [gnutls-devel] Trust store from environment variable In-Reply-To: <1423401290.2022.3.camel@gnutls.org> References: <20150207153406.GA7383@debian> <1423387098.2022.1.camel@gnutls.org> <20150208120028.GA5557@debian> <1423401290.2022.3.camel@gnutls.org> Message-ID: <20150208132534.GA19105@debian> Thanks again for the detailed information, we will have a look into it! All the best, Andreas From INVALID.NOREPLY at gnu.org Sun Feb 8 16:10:45 2015 From: INVALID.NOREPLY at gnu.org (Ludovic =?UTF-8?B?Q291cnTDqHM=?=) Date: Sun, 08 Feb 2015 15:10:45 +0000 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile In-Reply-To: <20150207-230936.sv80668.38050@savannah.gnu.org> References: <20150207-230936.sv80668.38050@savannah.gnu.org> Message-ID: <20150208-161045.sv15145.34662@savannah.gnu.org> Follow-up Comment #1, sr #108744 (project gnutls): GnuTLS does not depend on http://www.gnu.org/software/autogen/ if that's what you mean. GnuTLS has had an optional dependency on Guile for several years (for the Guile bindings), but it's optional. Ludo'. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Feb 8 21:12:39 2015 From: INVALID.NOREPLY at gnu.org (Cedric) Date: Sun, 08 Feb 2015 20:12:39 +0000 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile In-Reply-To: <20150208-161045.sv15145.34662@savannah.gnu.org> References: <20150207-230936.sv80668.38050@savannah.gnu.org> <20150208-161045.sv15145.34662@savannah.gnu.org> Message-ID: <20150208-201239.sv80668.65817@savannah.gnu.org> Follow-up Comment #2, sr #108744 (project gnutls): Turns out, the dependency on autogen is because Gentoo debundles libopts and therefore installs autogen to provide it. I guess this can be closed with the minor remark that it would be beneficial if GnuTLS had used an established, stand-alone config parser library rather than using autogen's internal libraries! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Feb 8 22:07:44 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 08 Feb 2015 21:07:44 +0000 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile In-Reply-To: <20150208-201239.sv80668.65817@savannah.gnu.org> References: <20150207-230936.sv80668.38050@savannah.gnu.org> <20150208-161045.sv15145.34662@savannah.gnu.org> <20150208-201239.sv80668.65817@savannah.gnu.org> Message-ID: <20150208-230744.sv707.20824@savannah.gnu.org> Update of sr #108744 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #3: libopts is a separate from autogen library in all distributions. You'd better file a bug in gentoo not to bundle it with autogen. There is nothing gnutls can do in that case. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From rj7252 at att.com Wed Feb 11 17:04:30 2015 From: rj7252 at att.com (JONES, BILL) Date: Wed, 11 Feb 2015 16:04:30 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> All, Which library is the version_to_entry function defined. It's used in many places in gnutls...not just related to openssl. gnutls/gnutls-3.3.11/lib/gnutls_dtls.c: v = version_to_entry(version); gnutls/gnutls-3.3.11/lib/gnutls_int.h: s->security_parameters.pversion = version_to_entry(v); gnutls/gnutls-3.3.11/lib/algorithms/protocols.c:const version_entry_st *version_to_entry(gnutls_protocol_t version) gnutls/gnutls-3.3.11/lib/gnutls_handshake.c: version_to_entry(_gnutls_version_max gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); gnutls/gnutls-3.3.11/lib/algorithms.h:const version_entry_st *version_to_entry(gnutls_protocol_t c); I used --disable-openssl-compatibility which was recommended in one thread...which allowed the "make" to work, but "make check" blows up now. Where does this function come from? Robert W. Jones (Bill) AT&T -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Feb 11 17:58:56 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Feb 2015 11:58:56 -0500 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: <87vbj8o04v.fsf@alice.fifthhorseman.net> On Wed 2015-02-11 11:04:30 -0500, JONES, BILL wrote: > Which library is the version_to_entry function defined. > > It's used in many places in gnutls...not just related to openssl. > > gnutls/gnutls-3.3.11/lib/gnutls_dtls.c: v = version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_int.h: s->security_parameters.pversion = version_to_entry(v); > gnutls/gnutls-3.3.11/lib/algorithms/protocols.c:const version_entry_st *version_to_entry(gnutls_protocol_t version) the function is defined here in lib/algorithms/protocols.c. > gnutls/gnutls-3.3.11/lib/gnutls_handshake.c: version_to_entry(_gnutls_version_max > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/algorithms.h:const version_entry_st *version_to_entry(gnutls_protocol_t c); the function is declared here in lib/algorithms/protocols.h If that's not what you're asking, can you clarify? are you running into specific problems? if so, can you show what the problems are specifically? --dkg From rj7252 at att.com Wed Feb 11 18:44:28 2015 From: rj7252 at att.com (JONES, BILL) Date: Wed, 11 Feb 2015 17:44:28 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <87vbj8o04v.fsf@alice.fifthhorseman.net> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CD1987@MISOUT7MSGUSRCD.ITServices.sbc.com> Daniel, Here is the original problem: Making all in extra^M make[2]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M Making all in includes^M make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra/includes'^M make[3]: Nothing to be done for `all'.^M make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra/includes'^M make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M CC gnutls_openssl.lo^M CC openssl_compat.lo^M CCLD libgnutls-openssl.la^M Undefined first referenced^M symbol in file^M nanosleep .libs/gnutls_openssl.o (symbol belongs to implicit dependency /usr/lib/librt.so.1)^M version_to_entry .libs/gnutls_openssl.o^M ld: fatal: symbol referencing errors. No output written to .libs/libgnutls-openssl.so.27.0.2^M make[3]: *** [libgnutls-openssl.la] Error 2^M make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M make[2]: *** [all-recursive] Error 1^M make[2]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M make[1]: *** [all-recursive] Error 1^M make[1]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11'^M make: *** [all] Error 2^M So one thread said...you don't need openssl support (and the question why not went unanswered), but the recommendation was to add "--disable-openssl-compatibility" So I did, and now here is the next problem: Making check in tests make[1]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' Making check in . make[2]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make mini-record-2 simple gc set_pkcs12_cred certder certuniqueid mpi certificate_set_x509_crl dn parse_ca moredn record-s izes hostname-check cve-2008-4989 pkcs12_s2k chainverify record-sizes-range crq_key_id x509sign-verify cve-2009-1415 cve-20 09-1416 crq_apis init_roundtrip pkcs12_s2k_pem dn2 mini-eagain nul-in-x509-names x509_altname pkcs12_encode mini-x509 mini- rehandshake rng-fork mini-eagain-dtls resume-dtls x509cert x509cert-tl infoaccess mini-dtls-hello-verify mini-tdb mini-dtls -rehandshake mini-alpn mini-dtls-large mini-termination mini-x509-cas mini-x509-2 pkcs12_simple mini-emsgsize-dtls chainver ify-unsorted mini-overhead mini-dtls-heartbeat mini-x509-callbacks key-openssl priorities mini-dtls-srtp rsa-encrypt-decryp t mini-loss-time mini-record mini-dtls-record mini-handshake-timeout mini-record-range mini-cert-status mini-rsa-psk global -init sec-params fips-test mini-global-load name-constraints x509-extensions long-session-id mini-x509-callbacks-intr crlve rify init_fds mini-rehandshake-2 ocsp openpgp-auth openpgp-auth2 openpgp-keyring pgps2kgnu x509self x509dn anonself pskse lf dhepskself resume setcredcrash openpgpself \ rfc2253-escape-test make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[3]: `mini-record-2' is up to date. make[3]: `simple' is up to date. CCLD gc Undefined first referenced symbol in file version_to_entry gc.o ld: fatal: symbol referencing errors. No output written to gc make[3]: *** [gc] Error 2 make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make: *** [check-recursive] Error 1 Here is the output from "make --recon check" make[2]: `mini-record-2' is up to date. make[2]: `simple' is up to date. rm -f gc echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc -no-install -R/appl/local-201501ss/lib -R/usr/lib -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la libutils.la -lsocket -lnsl -lnsl -lintl -lgen So what lib is missing version_to_entry?...and why? I expect that if this gets worked out, I can remove the "--disable-openssl-compatibility" *NOTE...maybe unrelated: I also found that the code the handle _Bool type was messed up: make[5]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/src/libopts'^M CC libopts_la-libopts.lo^M "/appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/compat/compat.h", line 188: invalid type combination^M "/appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/compat/compat.h", line 188: warning: typedef declares no type name^M cc: acomp failed for /appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/libopts.c^M and I fixed that by doing this: 1. Added local stdbool.h from gettext-0.19.4/gettext-runtime/gnulib-lib/stdbool.h to gnutls-3.3.11/src/libopts/compat/stdbool.h 2. In src/libopts/compat/compat.h and src/libopts/autoopts/options.h Changed: #ifdef HAVE_STDBOOL_H # include #else # include "stdbool.h" typedef enum { false = 0, true = 1 } _Bool; # define bool _Bool /* The other macros must be usable in preprocessor directives. */ # define false 0 # define true 1 #endif To: #ifdef HAVE_STDBOOL_H # include /* Only for C99 in Solaris */ #else # include "stdbool.h" /* does a better job of correctly defining _Bool depending on environment */ /* typedef enum { false = 0, true = 1 } _Bool; /*# define bool _Bool /* /* /* The other macros must be usable in preprocessor directives. */ /*# define false 0 /*# define true 1 */ #endif Hardware: Sun T5220 cc is: SolarisStudio12 Starting from just SolarisStudio12 plus current patches... I have these tools built, in this order: gnu/make-3.82 gnu/libsigsegv-2.10 gnu/m4-1.4.17 gnu/readline-6.3 gnupg/zlib-1.2.8 gnu/ncurses-5.9 sourceforge/pcre-8.36 gnu/libiconv-1.14 gnu/grep-2.19 sourceforge/expat-2.1.0 gnu/tar-1.28 gnu/texinfo-5.2 sourceforge/flex-2.5.39 gnu/bison-3.0.2 sourceforge/flex-2.5.39 gnu/gmp-6.0.0 mpfr.org/mpfr-3.1.2 gnu/mpc-1.0.2 gnu/pth-2.0.7 gnu/gzip-1.6 gnu/libunistring-0.9.4 gnu/libidn-1.29 gnu/libtasn1-4.2 tukaani/xz-5.2.0 gnu/sed-4.2.2 xmlsoft.org/libxml2-2.9.2 openssl/openssl-1.0.1j openldap.org/openldap-2.4.40 libssh2/libssh2-1.4.3 curl.haxx.se/curl-7.39.0 gnu/coreutils-8.23 gnu/gettext-0.19.4 gnu/gawk-4.1.1 sourceforge/tcl8.6.3 sourceforge/expect5.45 sourceforge/tk8.6.3 gnu/dejagnu-1.5.1 sourceware/libffi-3.2.1 gnu/nettle-2.7.1 pari.math.u-bordeaux.fr/pari-2.7.2 pkgconfig/pkg-config-0.28 gnome/glib-2.42.1 gnu/patch-2.6.1 gnu/autoconf-2.69 gnu/automake-1.14.1 gnu/libtool-2.4.4 ivmaisoft.com/libatomic_ops-7.4.2 hboehm.info/gc-7.2f gnu/guile-2.0.11 Tried this package (autogen-5.18.4), but it does not pass tests because it's not properly finding libintl_gettext during linking...so this was skipped. Currently building: gnutls/gnutls-3.3.11 Need this to move on to other tools. Robert W. Jones (Bill) AT&T -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Wednesday, February 11, 2015 11:59 AM To: JONES, BILL; bugs at gnutls.org Subject: Re: [gnutls-devel] Missing function. Where is version_to_entry defined? On Wed 2015-02-11 11:04:30 -0500, JONES, BILL wrote: > Which library is the version_to_entry function defined. > > It's used in many places in gnutls...not just related to openssl. > > gnutls/gnutls-3.3.11/lib/gnutls_dtls.c: v = version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_int.h: s->security_parameters.pversion = version_to_entry(v); > gnutls/gnutls-3.3.11/lib/algorithms/protocols.c:const version_entry_st *version_to_entry(gnutls_protocol_t version) the function is defined here in lib/algorithms/protocols.c. > gnutls/gnutls-3.3.11/lib/gnutls_handshake.c: version_to_entry(_gnutls_version_max > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/algorithms.h:const version_entry_st *version_to_entry(gnutls_protocol_t c); the function is declared here in lib/algorithms/protocols.h If that's not what you're asking, can you clarify? are you running into specific problems? if so, can you show what the problems are specifically? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rj7252 at att.com Wed Feb 11 19:22:17 2015 From: rj7252 at att.com (JONES, BILL) Date: Wed, 11 Feb 2015 18:22:17 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CD1B2B@MISOUT7MSGUSRCD.ITServices.sbc.com> Daniel, nm -v ../lib/.libs/libgnutls.so shows: [296] | 1790680| 128|FUNC |LOCL |2 |10 |version_to_entry Bill From: JONES, BILL Sent: Wednesday, February 11, 2015 12:44 PM To: 'Daniel Kahn Gillmor'; bugs at gnutls.org Subject: RE: [gnutls-devel] Missing function. Where is version_to_entry defined? Daniel, Here is the original problem: Making all in extra^M make[2]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M Making all in includes^M make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra/includes'^M make[3]: Nothing to be done for `all'.^M make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra/includes'^M make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M CC gnutls_openssl.lo^M CC openssl_compat.lo^M CCLD libgnutls-openssl.la^M Undefined first referenced^M symbol in file^M nanosleep .libs/gnutls_openssl.o (symbol belongs to implicit dependency /usr/lib/librt.so.1)^M version_to_entry .libs/gnutls_openssl.o^M ld: fatal: symbol referencing errors. No output written to .libs/libgnutls-openssl.so.27.0.2^M make[3]: *** [libgnutls-openssl.la] Error 2^M make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M make[2]: *** [all-recursive] Error 1^M make[2]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M make[1]: *** [all-recursive] Error 1^M make[1]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11'^M make: *** [all] Error 2^M So one thread said...you don't need openssl support (and the question why not went unanswered), but the recommendation was to add "--disable-openssl-compatibility" So I did, and now here is the next problem: Making check in tests make[1]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' Making check in . make[2]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make mini-record-2 simple gc set_pkcs12_cred certder certuniqueid mpi certificate_set_x509_crl dn parse_ca moredn record-s izes hostname-check cve-2008-4989 pkcs12_s2k chainverify record-sizes-range crq_key_id x509sign-verify cve-2009-1415 cve-20 09-1416 crq_apis init_roundtrip pkcs12_s2k_pem dn2 mini-eagain nul-in-x509-names x509_altname pkcs12_encode mini-x509 mini- rehandshake rng-fork mini-eagain-dtls resume-dtls x509cert x509cert-tl infoaccess mini-dtls-hello-verify mini-tdb mini-dtls -rehandshake mini-alpn mini-dtls-large mini-termination mini-x509-cas mini-x509-2 pkcs12_simple mini-emsgsize-dtls chainver ify-unsorted mini-overhead mini-dtls-heartbeat mini-x509-callbacks key-openssl priorities mini-dtls-srtp rsa-encrypt-decryp t mini-loss-time mini-record mini-dtls-record mini-handshake-timeout mini-record-range mini-cert-status mini-rsa-psk global -init sec-params fips-test mini-global-load name-constraints x509-extensions long-session-id mini-x509-callbacks-intr crlve rify init_fds mini-rehandshake-2 ocsp openpgp-auth openpgp-auth2 openpgp-keyring pgps2kgnu x509self x509dn anonself pskse lf dhepskself resume setcredcrash openpgpself \ rfc2253-escape-test make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[3]: `mini-record-2' is up to date. make[3]: `simple' is up to date. CCLD gc Undefined first referenced symbol in file version_to_entry gc.o ld: fatal: symbol referencing errors. No output written to gc make[3]: *** [gc] Error 2 make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make: *** [check-recursive] Error 1 Here is the output from "make --recon check" make[2]: `mini-record-2' is up to date. make[2]: `simple' is up to date. rm -f gc echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc -no-install -R/appl/local-201501ss/lib -R/usr/lib -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la libutils.la -lsocket -lnsl -lnsl -lintl -lgen So what lib is missing version_to_entry?...and why? I expect that if this gets worked out, I can remove the "--disable-openssl-compatibility" *NOTE...maybe unrelated: I also found that the code the handle _Bool type was messed up: make[5]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/src/libopts'^M CC libopts_la-libopts.lo^M "/appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/compat/compat.h", line 188: invalid type combination^M "/appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/compat/compat.h", line 188: warning: typedef declares no type name^M cc: acomp failed for /appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/libopts.c^M and I fixed that by doing this: 1. Added local stdbool.h from gettext-0.19.4/gettext-runtime/gnulib-lib/stdbool.h to gnutls-3.3.11/src/libopts/compat/stdbool.h 2. In src/libopts/compat/compat.h and src/libopts/autoopts/options.h Changed: #ifdef HAVE_STDBOOL_H # include #else # include "stdbool.h" typedef enum { false = 0, true = 1 } _Bool; # define bool _Bool /* The other macros must be usable in preprocessor directives. */ # define false 0 # define true 1 #endif To: #ifdef HAVE_STDBOOL_H # include /* Only for C99 in Solaris */ #else # include "stdbool.h" /* does a better job of correctly defining _Bool depending on environment */ /* typedef enum { false = 0, true = 1 } _Bool; /*# define bool _Bool /* /* /* The other macros must be usable in preprocessor directives. */ /*# define false 0 /*# define true 1 */ #endif Hardware: Sun T5220 cc is: SolarisStudio12 Starting from just SolarisStudio12 plus current patches... I have these tools built, in this order: gnu/make-3.82 gnu/libsigsegv-2.10 gnu/m4-1.4.17 gnu/readline-6.3 gnupg/zlib-1.2.8 gnu/ncurses-5.9 sourceforge/pcre-8.36 gnu/libiconv-1.14 gnu/grep-2.19 sourceforge/expat-2.1.0 gnu/tar-1.28 gnu/texinfo-5.2 sourceforge/flex-2.5.39 gnu/bison-3.0.2 sourceforge/flex-2.5.39 gnu/gmp-6.0.0 mpfr.org/mpfr-3.1.2 gnu/mpc-1.0.2 gnu/pth-2.0.7 gnu/gzip-1.6 gnu/libunistring-0.9.4 gnu/libidn-1.29 gnu/libtasn1-4.2 tukaani/xz-5.2.0 gnu/sed-4.2.2 xmlsoft.org/libxml2-2.9.2 openssl/openssl-1.0.1j openldap.org/openldap-2.4.40 libssh2/libssh2-1.4.3 curl.haxx.se/curl-7.39.0 gnu/coreutils-8.23 gnu/gettext-0.19.4 gnu/gawk-4.1.1 sourceforge/tcl8.6.3 sourceforge/expect5.45 sourceforge/tk8.6.3 gnu/dejagnu-1.5.1 sourceware/libffi-3.2.1 gnu/nettle-2.7.1 pari.math.u-bordeaux.fr/pari-2.7.2 pkgconfig/pkg-config-0.28 gnome/glib-2.42.1 gnu/patch-2.6.1 gnu/autoconf-2.69 gnu/automake-1.14.1 gnu/libtool-2.4.4 ivmaisoft.com/libatomic_ops-7.4.2 hboehm.info/gc-7.2f gnu/guile-2.0.11 Tried this package (autogen-5.18.4), but it does not pass tests because it's not properly finding libintl_gettext during linking...so this was skipped. Currently building: gnutls/gnutls-3.3.11 Need this to move on to other tools. Robert W. Jones (Bill) AT&T -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Wednesday, February 11, 2015 11:59 AM To: JONES, BILL; bugs at gnutls.org Subject: Re: [gnutls-devel] Missing function. Where is version_to_entry defined? On Wed 2015-02-11 11:04:30 -0500, JONES, BILL wrote: > Which library is the version_to_entry function defined. > > It's used in many places in gnutls...not just related to openssl. > > gnutls/gnutls-3.3.11/lib/gnutls_dtls.c: v = version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_int.h: s->security_parameters.pversion = version_to_entry(v); > gnutls/gnutls-3.3.11/lib/algorithms/protocols.c:const version_entry_st *version_to_entry(gnutls_protocol_t version) the function is defined here in lib/algorithms/protocols.c. > gnutls/gnutls-3.3.11/lib/gnutls_handshake.c: version_to_entry(_gnutls_version_max > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/algorithms.h:const version_entry_st *version_to_entry(gnutls_protocol_t c); the function is declared here in lib/algorithms/protocols.h If that's not what you're asking, can you clarify? are you running into specific problems? if so, can you show what the problems are specifically? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rj7252 at att.com Thu Feb 12 09:59:54 2015 From: rj7252 at att.com (JONES, BILL) Date: Thu, 12 Feb 2015 08:59:54 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> GNUTLS Team, So I did some digging around... as previously stated, make --recon check produces this link command: echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc -no-install -R/appl/local-201501ss/lib -R/usr/lib -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la libutils.la -lsocket -lnsl -lnsl -lintl -lgen If I add "../lib/algorithms/libgnutls_alg.la" to it link so: echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc -no-install -R/appl/local-201501ss/lib -R/usr/lib -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la ../lib/algorithms/libgnutls_alg.la libutils.la -lsocket -lnsl -lnsl -lintl -lgen gc now compiles. So the original question was, what library is "version_to_entry" defined in... Answer: libgnutls_alg.a Next question: What is missing in the Makefile to not include this in the CCLD for the "gc" test? Additionally, why isn't this included in the list of libs for libgnutls-openssl.la Robert W. Jones (Bill) AT&T From: JONES, BILL Sent: Wednesday, February 11, 2015 1:22 PM To: 'Daniel Kahn Gillmor'; 'bugs at gnutls.org' Subject: RE: [gnutls-devel] Missing function. Where is version_to_entry defined? Daniel, nm -v ../lib/.libs/libgnutls.so shows: [296] | 1790680| 128|FUNC |LOCL |2 |10 |version_to_entry Bill From: JONES, BILL Sent: Wednesday, February 11, 2015 12:44 PM To: 'Daniel Kahn Gillmor'; bugs at gnutls.org Subject: RE: [gnutls-devel] Missing function. Where is version_to_entry defined? Daniel, Here is the original problem: Making all in extra^M make[2]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M Making all in includes^M make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra/includes'^M make[3]: Nothing to be done for `all'.^M make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra/includes'^M make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M CC gnutls_openssl.lo^M CC openssl_compat.lo^M CCLD libgnutls-openssl.la^M Undefined first referenced^M symbol in file^M nanosleep .libs/gnutls_openssl.o (symbol belongs to implicit dependency /usr/lib/librt.so.1)^M version_to_entry .libs/gnutls_openssl.o^M ld: fatal: symbol referencing errors. No output written to .libs/libgnutls-openssl.so.27.0.2^M make[3]: *** [libgnutls-openssl.la] Error 2^M make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M make[2]: *** [all-recursive] Error 1^M make[2]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/extra'^M make[1]: *** [all-recursive] Error 1^M make[1]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11'^M make: *** [all] Error 2^M So one thread said...you don't need openssl support (and the question why not went unanswered), but the recommendation was to add "--disable-openssl-compatibility" So I did, and now here is the next problem: Making check in tests make[1]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' Making check in . make[2]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make mini-record-2 simple gc set_pkcs12_cred certder certuniqueid mpi certificate_set_x509_crl dn parse_ca moredn record-s izes hostname-check cve-2008-4989 pkcs12_s2k chainverify record-sizes-range crq_key_id x509sign-verify cve-2009-1415 cve-20 09-1416 crq_apis init_roundtrip pkcs12_s2k_pem dn2 mini-eagain nul-in-x509-names x509_altname pkcs12_encode mini-x509 mini- rehandshake rng-fork mini-eagain-dtls resume-dtls x509cert x509cert-tl infoaccess mini-dtls-hello-verify mini-tdb mini-dtls -rehandshake mini-alpn mini-dtls-large mini-termination mini-x509-cas mini-x509-2 pkcs12_simple mini-emsgsize-dtls chainver ify-unsorted mini-overhead mini-dtls-heartbeat mini-x509-callbacks key-openssl priorities mini-dtls-srtp rsa-encrypt-decryp t mini-loss-time mini-record mini-dtls-record mini-handshake-timeout mini-record-range mini-cert-status mini-rsa-psk global -init sec-params fips-test mini-global-load name-constraints x509-extensions long-session-id mini-x509-callbacks-intr crlve rify init_fds mini-rehandshake-2 ocsp openpgp-auth openpgp-auth2 openpgp-keyring pgps2kgnu x509self x509dn anonself pskse lf dhepskself resume setcredcrash openpgpself \ rfc2253-escape-test make[3]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[3]: `mini-record-2' is up to date. make[3]: `simple' is up to date. CCLD gc Undefined first referenced symbol in file version_to_entry gc.o ld: fatal: symbol referencing errors. No output written to gc make[3]: *** [gc] Error 2 make[3]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/appl/local_build/build-ss/gnutls-3.3.11/tests' make: *** [check-recursive] Error 1 Here is the output from "make --recon check" make[2]: `mini-record-2' is up to date. make[2]: `simple' is up to date. rm -f gc echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc -no-install -R/appl/local-201501ss/lib -R/usr/lib -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la libutils.la -lsocket -lnsl -lnsl -lintl -lgen So what lib is missing version_to_entry?...and why? I expect that if this gets worked out, I can remove the "--disable-openssl-compatibility" *NOTE...maybe unrelated: I also found that the code the handle _Bool type was messed up: make[5]: Entering directory `/appl/local_build/build-ss/gnutls-3.3.11/src/libopts'^M CC libopts_la-libopts.lo^M "/appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/compat/compat.h", line 188: invalid type combination^M "/appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/compat/compat.h", line 188: warning: typedef declares no type name^M cc: acomp failed for /appl/local_build/src/gnutls/gnutls-3.3.11/src/libopts/libopts.c^M and I fixed that by doing this: 1. Added local stdbool.h from gettext-0.19.4/gettext-runtime/gnulib-lib/stdbool.h to gnutls-3.3.11/src/libopts/compat/stdbool.h 2. In src/libopts/compat/compat.h and src/libopts/autoopts/options.h Changed: #ifdef HAVE_STDBOOL_H # include #else # include "stdbool.h" typedef enum { false = 0, true = 1 } _Bool; # define bool _Bool /* The other macros must be usable in preprocessor directives. */ # define false 0 # define true 1 #endif To: #ifdef HAVE_STDBOOL_H # include /* Only for C99 in Solaris */ #else # include "stdbool.h" /* does a better job of correctly defining _Bool depending on environment */ /* typedef enum { false = 0, true = 1 } _Bool; /*# define bool _Bool /* /* /* The other macros must be usable in preprocessor directives. */ /*# define false 0 /*# define true 1 */ #endif Hardware: Sun T5220 cc is: SolarisStudio12 Starting from just SolarisStudio12 plus current patches... I have these tools built, in this order: gnu/make-3.82 gnu/libsigsegv-2.10 gnu/m4-1.4.17 gnu/readline-6.3 gnupg/zlib-1.2.8 gnu/ncurses-5.9 sourceforge/pcre-8.36 gnu/libiconv-1.14 gnu/grep-2.19 sourceforge/expat-2.1.0 gnu/tar-1.28 gnu/texinfo-5.2 sourceforge/flex-2.5.39 gnu/bison-3.0.2 sourceforge/flex-2.5.39 gnu/gmp-6.0.0 mpfr.org/mpfr-3.1.2 gnu/mpc-1.0.2 gnu/pth-2.0.7 gnu/gzip-1.6 gnu/libunistring-0.9.4 gnu/libidn-1.29 gnu/libtasn1-4.2 tukaani/xz-5.2.0 gnu/sed-4.2.2 xmlsoft.org/libxml2-2.9.2 openssl/openssl-1.0.1j openldap.org/openldap-2.4.40 libssh2/libssh2-1.4.3 curl.haxx.se/curl-7.39.0 gnu/coreutils-8.23 gnu/gettext-0.19.4 gnu/gawk-4.1.1 sourceforge/tcl8.6.3 sourceforge/expect5.45 sourceforge/tk8.6.3 gnu/dejagnu-1.5.1 sourceware/libffi-3.2.1 gnu/nettle-2.7.1 pari.math.u-bordeaux.fr/pari-2.7.2 pkgconfig/pkg-config-0.28 gnome/glib-2.42.1 gnu/patch-2.6.1 gnu/autoconf-2.69 gnu/automake-1.14.1 gnu/libtool-2.4.4 ivmaisoft.com/libatomic_ops-7.4.2 hboehm.info/gc-7.2f gnu/guile-2.0.11 Tried this package (autogen-5.18.4), but it does not pass tests because it's not properly finding libintl_gettext during linking...so this was skipped. Currently building: gnutls/gnutls-3.3.11 Need this to move on to other tools. Robert W. Jones (Bill) AT&T -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Wednesday, February 11, 2015 11:59 AM To: JONES, BILL; bugs at gnutls.org Subject: Re: [gnutls-devel] Missing function. Where is version_to_entry defined? On Wed 2015-02-11 11:04:30 -0500, JONES, BILL wrote: > Which library is the version_to_entry function defined. > > It's used in many places in gnutls...not just related to openssl. > > gnutls/gnutls-3.3.11/lib/gnutls_dtls.c: v = version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_int.h: s->security_parameters.pversion = version_to_entry(v); > gnutls/gnutls-3.3.11/lib/algorithms/protocols.c:const version_entry_st *version_to_entry(gnutls_protocol_t version) the function is defined here in lib/algorithms/protocols.c. > gnutls/gnutls-3.3.11/lib/gnutls_handshake.c: version_to_entry(_gnutls_version_max > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/gnutls_session_pack.c: version_to_entry(version); > gnutls/gnutls-3.3.11/lib/algorithms.h:const version_entry_st *version_to_entry(gnutls_protocol_t c); the function is declared here in lib/algorithms/protocols.h If that's not what you're asking, can you clarify? are you running into specific problems? if so, can you show what the problems are specifically? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Feb 12 13:00:46 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 12 Feb 2015 13:00:46 +0100 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: On Thu, Feb 12, 2015 at 9:59 AM, JONES, BILL wrote: > GNUTLS Team, > So I did some digging around... > as previously stated, make --recon check produces this link command: > > echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc > -no-install -R/appl/local-201501ss/lib -R/usr/lib > -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib > -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la > libutils.la -lsocket -lnsl -lnsl -lintl -lgen > If I add "../lib/algorithms/libgnutls_alg.la" to it link so: > echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc > -no-install -R/appl/local-201501ss/lib -R/usr/lib > -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib > -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la > ../lib/algorithms/libgnutls_alg.la libutils.la -lsocket -lnsl -lnsl -lintl > -lgen You shouldn't need to add libgnutls_alg.la there. libgnutls_alg.la is part of libgnutls.la. You may be hitting a libtool bug for the platform you are. From INVALID.NOREPLY at gnu.org Sat Feb 14 10:19:26 2015 From: INVALID.NOREPLY at gnu.org (Cedric) Date: Sat, 14 Feb 2015 09:19:26 +0000 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile In-Reply-To: <20150208-230744.sv707.20824@savannah.gnu.org> References: <20150207-230936.sv80668.38050@savannah.gnu.org> <20150208-161045.sv15145.34662@savannah.gnu.org> <20150208-201239.sv80668.65817@savannah.gnu.org> <20150208-230744.sv707.20824@savannah.gnu.org> Message-ID: <20150214-091926.sv80668.1247@savannah.gnu.org> Follow-up Comment #4, sr #108744 (project gnutls): I'm just relaying second-hand information here, but according to the discussion of this issue on the Gentoo bugtracker[1], libopts is not inherently separate from autogen. libopts is, indeed, part of the autogen package and whatever else may be shipped on other distros is a downstream split of the two. [1] https://bugs.gentoo.org/show_bug.cgi?id=498324 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Feb 14 10:27:59 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 14 Feb 2015 09:27:59 +0000 Subject: [gnutls-devel] [sr #108744] GnuTLS added autogen dependency pulls in Scheme/Guile In-Reply-To: <20150214-091926.sv80668.1247@savannah.gnu.org> References: <20150207-230936.sv80668.38050@savannah.gnu.org> <20150208-161045.sv15145.34662@savannah.gnu.org> <20150208-201239.sv80668.65817@savannah.gnu.org> <20150208-230744.sv707.20824@savannah.gnu.org> <20150214-091926.sv80668.1247@savannah.gnu.org> Message-ID: <20150214-112759.sv707.50526@savannah.gnu.org> Follow-up Comment #5, sr #108744 (project gnutls): I don't quite follow the issues raised there, because it seems to be related to how are packages made in gentoo. libopts is a separate package of autogen. Autogen even puts the libopts tarball in /usr/share/autogen/libopts-*.tar.gz. In any case, libopts is an optional dependency of gnutls. You can always compile without it. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From tim.kosse at filezilla-project.org Sat Feb 14 16:31:47 2015 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Sat, 14 Feb 2015 16:31:47 +0100 Subject: [gnutls-devel] Patch: AES-NI not used for GCM on 32bit x86 Message-ID: <54DF6A63.5070300@filezilla-project.org> Hi, GnuTLS has the assembly code to accelerate AES-GCM using the AES-NI instruction set on both IA-32 and x86-64. In contrast, support for PCLMUL with AES-GCM is only implemented for x86-64. There's a misplaced #ifdef ASM_X86_64 in lib/accelerated/x86/x86-common.c around the check for pclmul, effectively disabling AES-NI for AES-GCM on IA-32 builds. The attached patch (tested against 3.3.12) moves the else block out of the #ifdef so that AES-NI is used to accelerate AES-GCM on IA-32 builds. Using this patch I get around 15%-20% higher throughput when using the AES-256-GCM cipher. Regards, Tim Kosse -------------- next part -------------- A non-text attachment was scrubbed... Name: gcm_aesni.patch Type: text/x-patch Size: 401 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sat Feb 14 18:02:59 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 14 Feb 2015 18:02:59 +0100 Subject: [gnutls-devel] Patch: AES-NI not used for GCM on 32bit x86 In-Reply-To: <54DF6A63.5070300@filezilla-project.org> References: <54DF6A63.5070300@filezilla-project.org> Message-ID: <1423933379.30407.0.camel@gnutls.org> On Sat, 2015-02-14 at 16:31 +0100, Tim Kosse wrote: > Hi, > GnuTLS has the assembly code to accelerate AES-GCM using the AES-NI > instruction set on both IA-32 and x86-64. In contrast, support for > PCLMUL with AES-GCM is only implemented for x86-64. > There's a misplaced #ifdef ASM_X86_64 in > lib/accelerated/x86/x86-common.c around the check for pclmul, > effectively disabling AES-NI for AES-GCM on IA-32 builds. > The attached patch (tested against 3.3.12) moves the else block out of > the #ifdef so that AES-NI is used to accelerate AES-GCM on IA-32 builds. Thanks. Applied. From rj7252 at att.com Mon Feb 16 14:51:17 2015 From: rj7252 at att.com (JONES, BILL) Date: Mon, 16 Feb 2015 13:51:17 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CEA45E@MISOUT7MSGUSRCD.ITServices.sbc.com> OK, so I looked into this. While building libgnutls.so.28.41.3 I see that libtool is building a .exp file to be fed to cc -M {file}.exp. This is defining which symbols to be global vs local. I would expect this mapping to only apply to .o files being included in the archive, but it's changing functions in the .a files like libgnutls_alg.a that are GLOB to LOCL With -M $ nm .libs/libgnutls.so.28.41.3 | grep version_to [296] | 1068728| 128|FUNC |LOCL |2 |10 |version_to_entry Without -M $ nm .libs/libgnutls.so.28.41.3.save | grep version_to [15274] | 1822032| 128|FUNC |GLOB |0 |9 |version_to_entry While removing the -M from the compile line fixes this issue, I am not sure what other issues it may generate. The same method was used for libgnutls.a and it seems to have worked: $ nm .libs/libgnutls.a | grep version_to | grep -v UNDEF [97] | 6448| 128|FUNC |GLOB |0 |2 |version_to_entry Why not just convert the .a to a .so directly instead of rebuilding it from scratch...which didn't work. Here is the "cc" line that builds on Solaris10 with solarisstudio12. (I formatted it for readability) and tested both with and without the -M. Just removing the -M fixed the linking problems. All the tests that ran passed. SRP tests then ran into an undefined symbol. See the bottom of this message. cc -G \ -z defs \ -M libgnutls.so.28.41.3.exp \ -h libgnutls.so.28 \ -R/appl/local-201501ss/lib \ -L/appl/local-201501ss/lib \ -o .libs/libgnutls.so.28.41.3 \ .libs/gnutls_range.o \ .libs/gnutls_record.o \ .libs/gnutls_compress.o \ .libs/debug.o \ .libs/gnutls_cipher.o \ .libs/gnutls_mbuffers.o \ .libs/gnutls_buffers.o \ .libs/gnutls_handshake.o \ .libs/gnutls_num.o \ .libs/gnutls_errors.o \ .libs/gnutls_dh.o \ .libs/gnutls_kx.o \ .libs/gnutls_priority.o \ .libs/gnutls_hash_int.o \ .libs/gnutls_cipher_int.o \ .libs/gnutls_session.o \ .libs/gnutls_db.o \ .libs/x509_b64.o \ .libs/gnutls_extensions.o \ .libs/gnutls_auth.o \ .libs/gnutls_v2_compat.o \ .libs/gnutls_datum.o \ .libs/gnutls_session_pack.o \ .libs/gnutls_mpi.o \ .libs/gnutls_pk.o \ .libs/gnutls_cert.o \ .libs/gnutls_global.o \ .libs/gnutls_constate.o \ .libs/gnutls_anon_cred.o \ .libs/pkix_asn1_tab.o \ .libs/gnutls_asn1_tab.o \ .libs/gnutls_mem.o \ .libs/gnutls_ui.o \ .libs/vasprintf.o \ .libs/gnutls_sig.o \ .libs/gnutls_ecc.o \ .libs/gnutls_alert.o \ .libs/gnutls_privkey_raw.o \ .libs/system.o \ .libs/gnutls_str.o \ .libs/gnutls_state.o \ .libs/gnutls_x509.o \ .libs/gnutls_rsa_export.o \ .libs/gnutls_helper.o \ .libs/gnutls_supplemental.o \ .libs/random.o \ .libs/crypto-api.o \ .libs/gnutls_privkey.o \ .libs/gnutls_pcert.o \ .libs/gnutls_pubkey.o \ .libs/locks.o \ .libs/gnutls_dtls.o \ .libs/system_override.o \ .libs/crypto-backend.o \ .libs/verify-tofu.o \ .libs/pin.o \ .libs/tpm.o \ .libs/fips.o \ .libs/safe-memset.o \ .libs/inet_pton.o \ .libs/gnutls_srp.o \ .libs/gnutls_psk.o \ -z allextract \ ../gl/.libs/libgnu.a \ x509/.libs/libgnutls_x509.a \ ext/.libs/libgnutls_ext.a \ auth/.libs/libgnutls_auth.a \ algorithms/.libs/libgnutls_alg.a \ extras/.libs/libgnutls_extras.a \ accelerated/.libs/libaccelerated.a \ openpgp/.libs/libgnutls_openpgp.a \ opencdk/.libs/libminiopencdk.a \ nettle/.libs/libcrypto.a \ -z defaultextract \ -lz \ -lc \ -lnsl \ -lsocket \ -lrt \ -lnettle \ -lhogweed \ -lgen \ -lc \ /appl/local-201501ss/lib/libiconv.so \ /appl/local-201501ss/lib/libintl.so \ /appl/local-201501ss/lib/libtasn1.so \ /appl/local-201501ss/lib/libgmp.so Here is the "srp" issue: Making check in srp make[2]: Entering directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' make mini-srp make[3]: Entering directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' CC mini-srp.o "/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c", line 202: warning: implicit function declaration: kill "/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c", line 274: undefined symbol: AF_LOCAL cc: acomp failed for /appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c make[3]: *** [mini-srp.o] Error 2 make[3]: Leaving directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests' make: *** [check-recursive] Error 1 On Solaris, AF_UNIX is defined and the CODE should be checking for this. Some parts of gnutls ARE checking: from lib/nettle/egd.c #ifdef AF_UNIX #define LOCAL_SOCKET_TYPE AF_UNIX #else #define LOCAL_SOCKET_TYPE AF_LOCAL #endif I changed tests/srp/mini-srp.c tests/dtls/dtls-stress.c to use the same setup as in egd.c. Can THIS at least be fixed in the code base? Also there are a lot of these warnings around...in the entire package... "/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c", line 208: warning: implicit function declaration: kill This is resulting from a missing "#include " in many files. -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Thursday, February 12, 2015 7:01 AM To: JONES, BILL Cc: Daniel Kahn Gillmor; bugs at gnutls.org Subject: Re: [gnutls-devel] Missing function. Where is version_to_entry defined? On Thu, Feb 12, 2015 at 9:59 AM, JONES, BILL wrote: > GNUTLS Team, > So I did some digging around... > as previously stated, make --recon check produces this link command: > > echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc > -no-install -R/appl/local-201501ss/lib -R/usr/lib > -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib > -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la > libutils.la -lsocket -lnsl -lnsl -lintl -lgen > If I add "../lib/algorithms/libgnutls_alg.la" to it link so: > echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc > -no-install -R/appl/local-201501ss/lib -R/usr/lib > -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib > -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la > ../lib/algorithms/libgnutls_alg.la libutils.la -lsocket -lnsl -lnsl -lintl > -lgen You shouldn't need to add libgnutls_alg.la there. libgnutls_alg.la is part of libgnutls.la. You may be hitting a libtool bug for the platform you are. From rj7252 at att.com Mon Feb 16 18:04:49 2015 From: rj7252 at att.com (JONES, BILL) Date: Mon, 16 Feb 2015 17:04:49 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CEA8D5@MISOUT7MSGUSRCD.ITServices.sbc.com> Here are the full list of files missing "#include " "gnutls-3.3.11/tests/resume-dtls.c", line 336: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-dtls-hello-verify.c", line 170: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-dtls-rehandshake.c", line 223: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-alpn.c", line 163: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-dtls-large.c", line 151: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-dtls-heartbeat.c", line 208: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-dtls-srtp.c", line 187: warning: implicit function declaration: kill "gnutls-3.3.11/tests/mini-dtls-record.c", line 280: warning: implicit function declaration: kill "gnutls-3.3.11/tests/srp/mini-srp.c", line 202: warning: implicit function declaration: kill "gnutls-3.3.11/tests/resume.c", line 336: warning: implicit function declaration: kill Here are other warnings showing up: "gnutls-3.3.11/lib/x509/pkcs12_encr.c", line 140: warning: enum type mismatch: arg #1 rc = _gnutls_hash_fast(me->id, hash, mac_len, hash); should this be: rc = _gnutls_hash_fast((gnutls_digest_algorithm_t)me->id, hash, mac_len, hash); "gnutls-3.3.11/lib/system.c", line 684: warning: argument #2 is incompatible with prototype: prototype: pointer to pointer to const char : "/appl/local-201501ss/include/iconv.h", line 83 argument : pointer to pointer to char "gnutls-3.3.11/src/certtool-cfg.c", line 1104: warning: shift count negative or too big: >> 32 "gnutls-3.3.11/src/certtool.c", line 1131: warning: integer overflow detected: op "<<" -----Original Message----- From: JONES, BILL Sent: Monday, February 16, 2015 8:51 AM To: 'Nikos Mavrogiannopoulos' Cc: bugs at gnutls.org Subject: RE: [gnutls-devel] Missing function. Where is version_to_entry defined? OK, so I looked into this. While building libgnutls.so.28.41.3 I see that libtool is building a .exp file to be fed to cc -M {file}.exp. This is defining which symbols to be global vs local. I would expect this mapping to only apply to .o files being included in the archive, but it's changing functions in the .a files like libgnutls_alg.a that are GLOB to LOCL With -M $ nm .libs/libgnutls.so.28.41.3 | grep version_to [296] | 1068728| 128|FUNC |LOCL |2 |10 |version_to_entry Without -M $ nm .libs/libgnutls.so.28.41.3.save | grep version_to [15274] | 1822032| 128|FUNC |GLOB |0 |9 |version_to_entry While removing the -M from the compile line fixes this issue, I am not sure what other issues it may generate. The same method was used for libgnutls.a and it seems to have worked: $ nm .libs/libgnutls.a | grep version_to | grep -v UNDEF [97] | 6448| 128|FUNC |GLOB |0 |2 |version_to_entry Why not just convert the .a to a .so directly instead of rebuilding it from scratch...which didn't work. Here is the "cc" line that builds on Solaris10 with solarisstudio12. (I formatted it for readability) and tested both with and without the -M. Just removing the -M fixed the linking problems. All the tests that ran passed. SRP tests then ran into an undefined symbol. See the bottom of this message. cc -G \ -z defs \ -M libgnutls.so.28.41.3.exp \ -h libgnutls.so.28 \ -R/appl/local-201501ss/lib \ -L/appl/local-201501ss/lib \ -o .libs/libgnutls.so.28.41.3 \ .libs/gnutls_range.o \ .libs/gnutls_record.o \ .libs/gnutls_compress.o \ .libs/debug.o \ .libs/gnutls_cipher.o \ .libs/gnutls_mbuffers.o \ .libs/gnutls_buffers.o \ .libs/gnutls_handshake.o \ .libs/gnutls_num.o \ .libs/gnutls_errors.o \ .libs/gnutls_dh.o \ .libs/gnutls_kx.o \ .libs/gnutls_priority.o \ .libs/gnutls_hash_int.o \ .libs/gnutls_cipher_int.o \ .libs/gnutls_session.o \ .libs/gnutls_db.o \ .libs/x509_b64.o \ .libs/gnutls_extensions.o \ .libs/gnutls_auth.o \ .libs/gnutls_v2_compat.o \ .libs/gnutls_datum.o \ .libs/gnutls_session_pack.o \ .libs/gnutls_mpi.o \ .libs/gnutls_pk.o \ .libs/gnutls_cert.o \ .libs/gnutls_global.o \ .libs/gnutls_constate.o \ .libs/gnutls_anon_cred.o \ .libs/pkix_asn1_tab.o \ .libs/gnutls_asn1_tab.o \ .libs/gnutls_mem.o \ .libs/gnutls_ui.o \ .libs/vasprintf.o \ .libs/gnutls_sig.o \ .libs/gnutls_ecc.o \ .libs/gnutls_alert.o \ .libs/gnutls_privkey_raw.o \ .libs/system.o \ .libs/gnutls_str.o \ .libs/gnutls_state.o \ .libs/gnutls_x509.o \ .libs/gnutls_rsa_export.o \ .libs/gnutls_helper.o \ .libs/gnutls_supplemental.o \ .libs/random.o \ .libs/crypto-api.o \ .libs/gnutls_privkey.o \ .libs/gnutls_pcert.o \ .libs/gnutls_pubkey.o \ .libs/locks.o \ .libs/gnutls_dtls.o \ .libs/system_override.o \ .libs/crypto-backend.o \ .libs/verify-tofu.o \ .libs/pin.o \ .libs/tpm.o \ .libs/fips.o \ .libs/safe-memset.o \ .libs/inet_pton.o \ .libs/gnutls_srp.o \ .libs/gnutls_psk.o \ -z allextract \ ../gl/.libs/libgnu.a \ x509/.libs/libgnutls_x509.a \ ext/.libs/libgnutls_ext.a \ auth/.libs/libgnutls_auth.a \ algorithms/.libs/libgnutls_alg.a \ extras/.libs/libgnutls_extras.a \ accelerated/.libs/libaccelerated.a \ openpgp/.libs/libgnutls_openpgp.a \ opencdk/.libs/libminiopencdk.a \ nettle/.libs/libcrypto.a \ -z defaultextract \ -lz \ -lc \ -lnsl \ -lsocket \ -lrt \ -lnettle \ -lhogweed \ -lgen \ -lc \ /appl/local-201501ss/lib/libiconv.so \ /appl/local-201501ss/lib/libintl.so \ /appl/local-201501ss/lib/libtasn1.so \ /appl/local-201501ss/lib/libgmp.so Here is the "srp" issue: Making check in srp make[2]: Entering directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' make mini-srp make[3]: Entering directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' CC mini-srp.o "/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c", line 202: warning: implicit function declaration: kill "/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c", line 274: undefined symbol: AF_LOCAL cc: acomp failed for /appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c make[3]: *** [mini-srp.o] Error 2 make[3]: Leaving directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests/srp' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/appl/archives/local_build/build-ss/gnutls-3.3.11/tests' make: *** [check-recursive] Error 1 On Solaris, AF_UNIX is defined and the CODE should be checking for this. Some parts of gnutls ARE checking: from lib/nettle/egd.c #ifdef AF_UNIX #define LOCAL_SOCKET_TYPE AF_UNIX #else #define LOCAL_SOCKET_TYPE AF_LOCAL #endif I changed tests/srp/mini-srp.c tests/dtls/dtls-stress.c to use the same setup as in egd.c. Can THIS at least be fixed in the code base? Also there are a lot of these warnings around...in the entire package... "/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/tests/srp/mini-srp.c", line 208: warning: implicit function declaration: kill This is resulting from a missing "#include " in many files. -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Thursday, February 12, 2015 7:01 AM To: JONES, BILL Cc: Daniel Kahn Gillmor; bugs at gnutls.org Subject: Re: [gnutls-devel] Missing function. Where is version_to_entry defined? On Thu, Feb 12, 2015 at 9:59 AM, JONES, BILL wrote: > GNUTLS Team, > So I did some digging around... > as previously stated, make --recon check produces this link command: > > echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc > -no-install -R/appl/local-201501ss/lib -R/usr/lib > -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib > -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la > libutils.la -lsocket -lnsl -lnsl -lintl -lgen > If I add "../lib/algorithms/libgnutls_alg.la" to it link so: > echo " CCLD " gc;/bin/bash ../libtool --silent --tag=CC --mode=link cc > -no-install -R/appl/local-201501ss/lib -R/usr/lib > -L/appl/local-201501ss/lib -L/opt/solarisstudio12.3/lib > -L/opt/solarisstudio12.3/lib -o gc gc.o ../lib/libgnutls.la ../gl/libgnu.la > ../lib/algorithms/libgnutls_alg.la libutils.la -lsocket -lnsl -lnsl -lintl > -lgen You shouldn't need to add libgnutls_alg.la there. libgnutls_alg.la is part of libgnutls.la. You may be hitting a libtool bug for the platform you are. From nmav at gnutls.org Mon Feb 16 23:18:53 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Feb 2015 23:18:53 +0100 Subject: [gnutls-devel] SSL Handhake Error In-Reply-To: <1424061906658.1411@fiport.com> References: <1424061906658.1411@fiport.com> Message-ID: <1424125133.6363.6.camel@gnutls.org> On Mon, 2015-02-16 at 04:45 +0000, Sunil Chowgale wrote: > ??Hi All, > The URL : https://www.uasecho.com/Account/SignIn which is site for > "University Accounting Services LLC - Loan" is failing to load in the > Webkit. > It throws SSL Handshake error > This error is thrown even when we set the SSL Handshake environment > settings as below > G_TLS_GNUTLS_PRIORITY :: NORMAL:%COMPAT:%LATEST_RECORD_VERSION:! VERS-SSL3.0 Please update your mailing list address. The old list at gnu.org is no longer used. To the point, which version of gnutls is that? I have no issue connecting to it with gnutls-cli and the default priority string, or the one you provided above. regards, Nikos From nmav at gnutls.org Wed Feb 18 22:51:15 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Feb 2015 22:51:15 +0100 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <2B72DD7087E4A24A895A948352DA2F9217CEA45E@MISOUT7MSGUSRCD.ITServices.sbc.com> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> <2B72DD7087E4A24A895A948352DA2F9217CEA45E@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: <1424296275.3853.6.camel@gnutls.org> On Mon, 2015-02-16 at 13:51 +0000, JONES, BILL wrote: > OK, so I looked into this. > While building libgnutls.so.28.41.3 I see that libtool is building a .exp file to be fed to cc -M {file}.exp. > This is defining which symbols to be global vs local. I would expect this mapping to only apply to .o files being included in the archive, but it's changing functions in the .a files like libgnutls_alg.a that are GLOB to LOCL > With -M > $ nm .libs/libgnutls.so.28.41.3 | grep version_to > [296] | 1068728| 128|FUNC |LOCL |2 |10 |version_to_entry > Without -M > $ nm .libs/libgnutls.so.28.41.3.save | grep version_to > [15274] | 1822032| 128|FUNC |GLOB |0 |9 |version_to_entry > While removing the -M from the compile line fixes this issue, I am not sure what other issues it may generate. I cannot help with that at all. I'd suggest to ask in a libtool related list. > On Solaris, AF_UNIX is defined and the CODE should be checking for this. Some parts of gnutls ARE checking: > from lib/nettle/egd.c > #ifdef AF_UNIX > #define LOCAL_SOCKET_TYPE AF_UNIX > #else > #define LOCAL_SOCKET_TYPE AF_LOCAL > #endif > I changed tests/srp/mini-srp.c tests/dtls/dtls-stress.c to use the same setup as in egd.c. Can THIS at least be fixed in the code base? If you have a fix I'll apply it. regards, Nikos From nmav at gnutls.org Wed Feb 18 23:09:27 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Feb 2015 23:09:27 +0100 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <2B72DD7087E4A24A895A948352DA2F9217CEA8D5@MISOUT7MSGUSRCD.ITServices.sbc.com> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> <2B72DD7087E4A24A895A948352DA2F9217CEA8D5@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: <1424297367.3853.8.camel@gnutls.org> On Mon, 2015-02-16 at 17:04 +0000, JONES, BILL wrote: > Here are other warnings showing up: > "gnutls-3.3.11/lib/x509/pkcs12_encr.c", line 140: warning: enum type mismatch: arg #1 > rc = _gnutls_hash_fast(me->id, hash, mac_len, > hash); > should this be: > rc = _gnutls_hash_fast((gnutls_digest_algorithm_t)me->id, hash, mac_len, > hash); Applied this cast in master. > "gnutls-3.3.11/lib/system.c", line 684: warning: argument #2 is incompatible with prototype: > prototype: pointer to pointer to const char : "/appl/local-201501ss/include/iconv.h", line 83 > argument : pointer to pointer to char I don't see anything const in the posix definition of this function. > gnutls-3.3.11/src/certtool-cfg.c", line 1104: warning: shift count negative or too big: >> 32 Not sure what is the issue there. The integer shifted is a 64-bit one. > "gnutls-3.3.11/src/certtool.c", line 1131: warning: integer overflow detected: op "<<" I've added an explicit cast to unsigned int in the macro. Should solve that. regards, Nikos From rj7252 at att.com Thu Feb 19 00:53:37 2015 From: rj7252 at att.com (JONES, BILL) Date: Wed, 18 Feb 2015 23:53:37 +0000 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <1424297367.3853.8.camel@gnutls.org> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> <2B72DD7087E4A24A895A948352DA2F9217CEA8D5@MISOUT7MSGUSRCD.ITServices.sbc.com> <1424297367.3853.8.camel@gnutls.org> Message-ID: <2B72DD7087E4A24A895A948352DA2F9217CF0715@MISOUT7MSGUSRCD.ITServices.sbc.com> Nikos, Thanks for looking at these. >> "gnutls-3.3.11/lib/system.c", line 684: warning: argument #2 is incompatible with prototype: >> prototype: pointer to pointer to const char : "/appl/local-201501ss/include/iconv.h", line 83 >> argument : pointer to pointer to char > >I don't see anything const in the posix definition of this function. In gnu/libiconv-1.14/include/iconv.h, I see: extern LIBICONV_DLL_EXPORTED size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); which translates to line 83 in the resulting iconv.h extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); If this is wrong, then your suggesting that the libiconv team needs to fix this? >> gnutls-3.3.11/src/certtool-cfg.c", line 1104: warning: shift count negative or too big: >> 32 > >Not sure what is the issue there. The integer shifted is a 64-bit one. So the line is, default_serial[0] = default_serial_int >> 32; where default_serial is 32bits and default_serial_int is 64bits. unsigned long default_serial_int; uint32_t default_serial[2]; Is it being upset about the size of default_serial? Bill -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Wednesday, February 18, 2015 5:09 PM To: JONES, BILL Cc: bugs at gnutls.org Subject: Re: [gnutls-devel] Missing function. Where is version_to_entry defined? On Mon, 2015-02-16 at 17:04 +0000, JONES, BILL wrote: > Here are other warnings showing up: > "gnutls-3.3.11/lib/x509/pkcs12_encr.c", line 140: warning: enum type mismatch: arg #1 > rc = _gnutls_hash_fast(me->id, hash, mac_len, > hash); > should this be: > rc = _gnutls_hash_fast((gnutls_digest_algorithm_t)me->id, hash, mac_len, > hash); Applied this cast in master. > "gnutls-3.3.11/lib/system.c", line 684: warning: argument #2 is incompatible with prototype: > prototype: pointer to pointer to const char : "/appl/local-201501ss/include/iconv.h", line 83 > argument : pointer to pointer to char I don't see anything const in the posix definition of this function. > gnutls-3.3.11/src/certtool-cfg.c", line 1104: warning: shift count negative or too big: >> 32 Not sure what is the issue there. The integer shifted is a 64-bit one. > "gnutls-3.3.11/src/certtool.c", line 1131: warning: integer overflow detected: op "<<" I've added an explicit cast to unsigned int in the macro. Should solve that. regards, Nikos From nmav at gnutls.org Fri Feb 20 09:52:28 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Feb 2015 09:52:28 +0100 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: <2B72DD7087E4A24A895A948352DA2F9217CF0715@MISOUT7MSGUSRCD.ITServices.sbc.com> References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <87vbj8o04v.fsf@alice.fifthhorseman.net> <2B72DD7087E4A24A895A948352DA2F9217CDCF0A@MISOUT7MSGUSRCD.ITServices.sbc.com> <2B72DD7087E4A24A895A948352DA2F9217CEA8D5@MISOUT7MSGUSRCD.ITServices.sbc.com> <1424297367.3853.8.camel@gnutls.org> <2B72DD7087E4A24A895A948352DA2F9217CF0715@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: On Thu, Feb 19, 2015 at 12:53 AM, JONES, BILL wrote: >>> "gnutls-3.3.11/lib/system.c", line 684: warning: argument #2 is incompatible with prototype: >>> prototype: pointer to pointer to const char : "/appl/local-201501ss/include/iconv.h", line 83 >>> argument : pointer to pointer to char >>I don't see anything const in the posix definition of this function. > In gnu/libiconv-1.14/include/iconv.h, I see: > extern LIBICONV_DLL_EXPORTED size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); > which translates to line 83 in the resulting iconv.h > extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); > If this is wrong, then your suggesting that the libiconv team needs to fix this? In glibc's iconv there no const either. However, I don't see why the compiler needs to warn on that anyway. >>> gnutls-3.3.11/src/certtool-cfg.c", line 1104: warning: shift count negative or too big: >> 32 >>Not sure what is the issue there. The integer shifted is a 64-bit one. > So the line is, > default_serial[0] = default_serial_int >> 32; > where default_serial is 32bits and default_serial_int is 64bits. > unsigned long default_serial_int; > uint32_t default_serial[2]; > Is it being upset about the size of default_serial? It's a strange warning. I'd expect the shift to be evaluated first. If you cast to default_serial[0] = (int64_t)(default_serial_int >> 32), does it still output a warning? regards, Nikos From tobias-lists at 23.gs Fri Feb 20 12:46:42 2015 From: tobias-lists at 23.gs (Tobias Gruetzmacher) Date: Fri, 20 Feb 2015 12:46:42 +0100 Subject: [gnutls-devel] Stray ltmain.sh may break builds Message-ID: <20150220114642.GA7348@23.gs> Hi, there seem to be two copies of ltmain.sh in the release tarballs, which upsets some build environments, like MXE, when doing autoreconf with a different libtool version. The easiest fix is to remove ltmain.sh from the root of the tarball, since there is another copy in build-aux. (See https://github.com/mxe/mxe/issues/602 for a bug report about this) Regards, Tobias -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Digital signature URL: From nmav at gnutls.org Fri Feb 20 17:13:26 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Feb 2015 17:13:26 +0100 Subject: [gnutls-devel] Stray ltmain.sh may break builds In-Reply-To: <20150220114642.GA7348@23.gs> References: <20150220114642.GA7348@23.gs> Message-ID: On Fri, Feb 20, 2015 at 12:46 PM, Tobias Gruetzmacher wrote: > Hi, > there seem to be two copies of ltmain.sh in the release tarballs, which > upsets some build environments, like MXE, when doing autoreconf with a > different libtool version. The easiest fix is to remove ltmain.sh from > the root of the tarball, since there is another copy in build-aux. Thanks. Done in master branch. regards, Nikos From nmav at gnutls.org Wed Feb 25 22:57:46 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 25 Feb 2015 22:57:46 +0100 Subject: [gnutls-devel] gnutls 3.3.13 Message-ID: <1424901466.2020.1.camel@gnutls.org> Hello, I've just released gnutls 3.3.13. This is a bug-fix release on the current stable branch. Among other issues it adds a certificate algorithm consistency check in X.509 certificates. That's is a low severity issue affecting all previous versions, and although there no known attacks, it is recommended to upgrade to this version. * Version 3.3.13 (released 2015-02-25) ** libgnutls: Enable AESNI in GCM on x86 ** libgnutls: Fixes in DTLS message handling ** libgnutls: Check certificate algorithm consistency, i.e., check whether the signatureAlgorithm field matches the signature field inside TBSCertificate. ** gnutls-cli: Fixes in OCSP verification. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.tar.lz.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 Andris.Mednis at zabbix.com Thu Feb 26 12:13:41 2015 From: Andris.Mednis at zabbix.com (Andris Mednis) Date: Thu, 26 Feb 2015 13:13:41 +0200 Subject: [gnutls-devel] Small typo in doc: GNUTLS_GOT_APPLICATION_DATA Message-ID: <54EEFFE5.9080904@zabbix.com> Hello! In http://gnutls.org/manual/gnutls.html section "6.6 TLS handshake" in description of function "gnutls_handshake()" GNUTLS_GOT_APPLICATION_DATA should be corrected to GNUTLS_E_GOT_APPLICATION_DATA. Best regards Andris Mednis Zabbix developer From nmav at gnutls.org Thu Feb 26 13:09:14 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 26 Feb 2015 13:09:14 +0100 Subject: [gnutls-devel] Small typo in doc: GNUTLS_GOT_APPLICATION_DATA In-Reply-To: <54EEFFE5.9080904@zabbix.com> References: <54EEFFE5.9080904@zabbix.com> Message-ID: On Thu, Feb 26, 2015 at 12:13 PM, Andris Mednis wrote: > Hello! > In http://gnutls.org/manual/gnutls.html > section "6.6 TLS handshake" in description of function "gnutls_handshake()" > GNUTLS_GOT_APPLICATION_DATA should be corrected to > GNUTLS_E_GOT_APPLICATION_DATA. Thanks, fixed in master. regards, Nikos From tim.ruehsen at gmx.de Thu Feb 26 20:10:47 2015 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Thu, 26 Feb 2015 20:10:47 +0100 Subject: [gnutls-devel] Missing function. Where is version_to_entry defined? In-Reply-To: References: <2B72DD7087E4A24A895A948352DA2F9217CD16C8@MISOUT7MSGUSRCD.ITServices.sbc.com> <2B72DD7087E4A24A895A948352DA2F9217CF0715@MISOUT7MSGUSRCD.ITServices.sbc.com> Message-ID: <2796187.OoKi7hoALe@debian> Am Freitag, 20. Februar 2015, 09:52:28 schrieb Nikos Mavrogiannopoulos: > On Thu, Feb 19, 2015 at 12:53 AM, JONES, BILL wrote: > >>> "gnutls-3.3.11/lib/system.c", line 684: warning: argument #2 is incompatible with prototype: > >>> prototype: pointer to pointer to const char : > >>> "/appl/local-201501ss/include/iconv.h", line 83 argument : > >>> pointer to pointer to char > >> > >>I don't see anything const in the posix definition of this function. > >> > > In gnu/libiconv-1.14/include/iconv.h, I see: > > extern LIBICONV_DLL_EXPORTED size_t iconv (iconv_t cd, const char* * > > inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); which > > translates to line 83 in the resulting iconv.h > > extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, > > char* * outbuf, size_t *outbytesleft); If this is wrong, then your > > suggesting that the libiconv team needs to fix this? > In glibc's iconv there no const either. However, I don't see why the > compiler needs to warn on that anyway. :-) Lol, I just got an email... (I commented that 'missing' gcc 'feature' in 2012) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49748 Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From a.radke at arcor.de Thu Feb 26 20:23:55 2015 From: a.radke at arcor.de (Andreas Radke) Date: Thu, 26 Feb 2015 20:23:55 +0100 Subject: [gnutls-devel] gnutls 3.3.13 In-Reply-To: <1424901466.2020.1.camel@gnutls.org> References: <1424901466.2020.1.camel@gnutls.org> Message-ID: <20150226202355.5f096e39@workstation64.home> Test suite is broken in parallel builds with this release now in Archlinux. Running make -j1 check makes it pass all test. PASS: openpgp-keyring.scm PASS: srp-base64.scm ../../build-aux/test-driver: line 107: 5427 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: x509-auth.scm PASS: openpgp-auth.scm make[5]: Entering directory '/build/gnutls/src/gnutls-3.3.13/guile/tests' make[5]: Nothing to be done for 'all'. make[5]: Leaving directory '/build/gnutls/src/gnutls-3.3.13/guile/tests' ============================================================================ Testsuite summary for GnuTLS 3.3.13 ============================================================================ # TOTAL: 11 # PASS: 10 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See guile/tests/test-suite.log Please report to bugs at gnutls.org ============================================================================ Makefile:1481: recipe for target 'test-suite.log' failed make[4]: *** [test-suite.log] Error 1 make[4]: Leaving directory '/build/gnutls/src/gnutls-3.3.13/guile/tests' Makefile:1587: recipe for target 'check-TESTS' failed make[3]: *** [check-TESTS] Error 2 -Andy Archlinux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: Digitale Signatur von OpenPGP URL: From nmav at gnutls.org Fri Feb 27 12:58:01 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 27 Feb 2015 12:58:01 +0100 Subject: [gnutls-devel] gnutls 3.3.13 In-Reply-To: <20150226202355.5f096e39@workstation64.home> References: <1424901466.2020.1.camel@gnutls.org> <20150226202355.5f096e39@workstation64.home> Message-ID: On Thu, Feb 26, 2015 at 8:23 PM, Andreas Radke wrote: > Test suite is broken in parallel builds with this release now in > Archlinux. Running make -j1 check makes it pass all test. > PASS: openpgp-keyring.scm > PASS: srp-base64.scm > ../../build-aux/test-driver: line 107: 5427 Segmentation fault > (core dumped) "$@" > $log_file 2>&1 FAIL: x509-auth.scm > PASS: openpgp-auth.scm > make[5]: Entering directory > '/build/gnutls/src/gnutls-3.3.13/guile/tests' make[5]: Nothing to be > done for 'all'. make[5]: Leaving directory > '/build/gnutls/src/gnutls-3.3.13/guile/tests' Thanks, adding Ludo in CC. regards, Nikos From jericho at attrition.org Fri Feb 27 18:53:24 2015 From: jericho at attrition.org (jericho) Date: Fri, 27 Feb 2015 11:53:24 -0600 (CST) Subject: [gnutls-devel] serious bug in web site Message-ID: http://www.gnutls.org/security.html On 2015/02/25 a new advisory appears, SA-2015-1, that is a cut/paste copy of SA-2014-5 and has no CVE. On 2015/02/27 SA-2015-1 disappears without any indication as to why, or explanation if it was a mistake. So on a Wednesday you say "there is a vulnerability" in a pretty important library, then on Friday you say "just kidding" ... maybe. This is not responsible disclosure [1]1 and represents a serious flaw in your disclosure process. Please be more transparent and clear with your users. jericho OSVDB.org [1] Yes, 'responsible' is usually a bad term when talking 'coordinated' disclosure, but is very applicable to this situation. From nmav at gnutls.org Fri Feb 27 20:08:45 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 27 Feb 2015 20:08:45 +0100 Subject: [gnutls-devel] serious bug in web site In-Reply-To: References: Message-ID: <1425064125.24384.3.camel@gnutls.org> On Fri, 2015-02-27 at 11:53 -0600, jericho wrote: > http://www.gnutls.org/security.html > > On 2015/02/25 a new advisory appears, SA-2015-1, that is a cut/paste copy > of SA-2014-5 and has no CVE. > On 2015/02/27 SA-2015-1 disappears without any indication as to why, or > explanation if it was a mistake. Why would there be an explanation? It was clearly a copy-paste error, and SA-2014-5 appeared with a new date. As soon as I was made aware of the issue the false entry was removed. If you volunteer to maintain the web site in a "responsible" way as you suggest, I'm glad for your offer. regards, Nikos From jericho at attrition.org Fri Feb 27 20:23:17 2015 From: jericho at attrition.org (jericho) Date: Fri, 27 Feb 2015 13:23:17 -0600 (CST) Subject: [gnutls-devel] serious bug in web site In-Reply-To: <1425064125.24384.3.camel@gnutls.org> References: <1425064125.24384.3.camel@gnutls.org> Message-ID: On Fri, 27 Feb 2015, Nikos Mavrogiannopoulos wrote: : On Fri, 2015-02-27 at 11:53 -0600, jericho wrote: : > http://www.gnutls.org/security.html : > : > On 2015/02/25 a new advisory appears, SA-2015-1, that is a cut/paste copy : > of SA-2014-5 and has no CVE. : > On 2015/02/27 SA-2015-1 disappears without any indication as to why, or : > explanation if it was a mistake. : : Why would there be an explanation? It was clearly a copy-paste error, : and SA-2014-5 appeared with a new date. Actually, no. First, the advisories are not dated at all, which is also annoying for those who track disclosures. Second, given the time between 2014-5 and the appearance of 2015-1, it left people guessing if it is a pure copy/paste error, meaning there is no new issue, or if there IS a new issue and the description was not properly updated. The lack of a CVE supported the idea that there was a new issue, along with a post to gnutls-help announcing a new release that fixed a certificate processing issue that could constitute a vulnerability [1]. This is very clearly confusing to the end user responsible for maintaining a secure network. Adding a note somewhere on the page explaining that the 2015-02-25 appearance of SA-2015-1 was a mistake easily clarifies this issue to anyone wondering. Thanks, Brian [1] http://lists.gnutls.org/pipermail/gnutls-help/2015-February/003764.html From ludo at gnu.org Fri Feb 27 21:40:46 2015 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 27 Feb 2015 21:40:46 +0100 Subject: [gnutls-devel] gnutls 3.3.13 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 27 Feb 2015 12:58:01 +0100") References: <1424901466.2020.1.camel@gnutls.org> <20150226202355.5f096e39@workstation64.home> Message-ID: <87mw3zkrzl.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: >> ../../build-aux/test-driver: line 107: 5427 Segmentation fault >> (core dumped) "$@" > $log_file 2>&1 FAIL: x509-auth.scm I can?t reproduce it here. >From the guile/tests directory, could you run: ulimit -c unlimited while make check TESTS=x509-auth.scm ; do : ; done gdb `which guile` core and then send the output ?bt full? in GDB? What Guile version and platform is it? TIA, Ludo?.