Re: svn commit: r1896361 - /httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c
Le 07/01/2022 à 14:13, Ruediger Pluem a écrit : On 12/24/21 2:49 PM, jaillet...@apache.org wrote: Author: jailletc36 Date: Fri Dec 24 13:49:35 2021 New Revision: 1896361 URL: http://svn.apache.org/viewvc?rev=1896361=rev Log: Close a file handle in case of error in ct_static_scts() PR 65760 Modified: httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c Modified: httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c?rev=1896361=1896360=1896361=diff == --- httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c (original) +++ httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c Fri Dec 24 13:49:35 2021 @@ -2967,6 +2967,7 @@ static const char *ct_static_scts(cmd_pa cert = PEM_read_X509(pemfile, NULL, NULL, NULL); if (!cert) { +fclose(pemfile); Couldn't we just move that before the if and remove the previously existing call? Regards Rüdiger Hi, if you mean something like: https://github.com/tititiou36/httpd/commit/1348607c00ba58ce371f2f8ecb08abf610227043 Yes, this is just fine for me. CJ
Re: svn commit: r1896361 - /httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c
On 12/24/21 2:49 PM, jaillet...@apache.org wrote: > Author: jailletc36 > Date: Fri Dec 24 13:49:35 2021 > New Revision: 1896361 > > URL: http://svn.apache.org/viewvc?rev=1896361=rev > Log: > Close a file handle in case of error in ct_static_scts() > > PR 65760 > > Modified: > httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c > > Modified: httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c?rev=1896361=1896360=1896361=diff > == > --- httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c (original) > +++ httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c Fri Dec 24 13:49:35 2021 > @@ -2967,6 +2967,7 @@ static const char *ct_static_scts(cmd_pa > > cert = PEM_read_X509(pemfile, NULL, NULL, NULL); > if (!cert) { > +fclose(pemfile); Couldn't we just move that before the if and remove the previously existing call? Regards Rüdiger
TLS neverbleed design
A nice new year to everyone! I was looking at the design of https://github.com/h2o/neverbleed which - loads TLS private keys in a separate process - creates EVP_PKEY instances that in the sign callback call into the separate process to create the TLS handshake signature This is surprisingly simple. With a little overhead, it keeps the keys in a separate address space, inaccessible to any exploits in the traffic serving workers. I wonder if it is worthwhile to add something similar to our server. Kind Regards, Stefan