Date: Mon, 13 May 2019 21:15:52 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 237757] www/nginx-devel: OCSP stapling broken with security/libressl 2.9.1 Message-ID: <bug-237757-7788-VR68JAMkSZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237757-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-237757-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237757 --- Comment #8 from Elias Ohm <info@eliasohm.de> --- But for the nginx part they really should fix that. It's not that they need such fallback within their own code and not that th= ere is no more approriate way to handle that is not available using official documented interfaces. If they account for the interface enhancment and evolution in the one place they should do it in the other places also. And even if they expect they could get an pre-populated context from Plugins which may still use the old extra vars instead of the more appropriate new certificate chain (which I did not checked to be honest), it's much better = then to expect the plugins to deliver the contexed with the newer structure, implementing an expolicit fallback to the extra chain (recognising the issue and can report warnings about legacy plugins that should better be updated = and such). For builders that want to build nginx against a non default lib they eighth= er could provide some configuration - or the builders would be in the Duty to = deal with that (so define SSL_CTX_get_extra_chain_certs_only to point to SSL_CTX_get_extra_chain_certs). For the LibreSSL it would at least be a possibly breaking Change for applications that expect exactly the LibreSSL interface and rely on getting extra chain from the context never returns the chain of the current certificate. Thought there are probably not too many applications affected by that. Anyway that is the exact explanation for the issue. And for me a patch to nginx is more approriate. Best at upstream nginx or if they deny for any (for me not realy understandable reason) as a local fix t= o be able to build with libressl, if someone insits to do so. Of course if they would change LibreSSL that would solve the specific issue reported here eighter. (While it's unlilkely that there are too many simili= ar cases like this around that would Profit from that, I assume.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237757-7788-VR68JAMkSZ>