Date: Mon, 13 May 2019 20:41: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-imrAN2dkNy@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 #7 from Elias Ohm <info@eliasohm.de> --- Sure it would be fine if LibreSSL would provide same Interface as OpenSSL. Not sure why this differs, so not I cannot say whether it's a bug or just t= he design of the library. It could be a matter of improving security or applying some best practices,= or just "laziness" (or beeing short on time or such) that they did it differen= tly. Of course it would be fine to be 100% interchangable from interface and functionality, but don't know whether they want that. For me personally it sounds reasonable to make a function called "SSL_CTX_get_extra_chain_certs" to only get the extra chain and not falling back to some other chain (which could be not what is wanted from plain word= ing of the function). Would it be the other way round, yes. (Having a SSL_CTX_get_extra_chain_cer= ts and a SSL_CTX_get_extra_chain_certs_or_chain.) For OpenSSL this has historical reasons, first implementing a convenience function or (more or less undocumented) interface for the chain certificate= s at a time where the per certificate chain where not available. Afterwards, yes, for compatibility of 3rd party library code that expects t= he function to just return the chain from the usual location it's nice to prov= ide such a fallback to not break them all or force the applications to itself s= tick on the extra-chain (and only working with libs that do so). Otherwise I assume they would have called the differently to have the funct= ion Name doing what it says in both cases on not just in the new one added for proper Access to the extra vars (and exactly them and not the one or the other). Where on the other Hand thats not really fine - yes and leads to such behav= iour the nginx devs Show (it's still working, so why adjust code). --=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-imrAN2dkNy>