Re: [PATCH] add ssl_protocols configuration option
От | Alex Shulgin |
---|---|
Тема | Re: [PATCH] add ssl_protocols configuration option |
Дата | |
Msg-id | 87ioiburu8.fsf@commandprompt.com обсуждение исходный текст |
Ответ на | [PATCH] add ssl_protocols configuration option (Dag-Erling Smørgrav <des@des.no>) |
Ответы |
Re: [PATCH] add ssl_protocols configuration option
Re: [PATCH] add ssl_protocols configuration option |
Список | pgsql-hackers |
Dag-Erling Smørgrav <des@des.no> writes: > > The attached patches add an ssl_protocols configuration option which > control which versions of SSL or TLS the server will use. The syntax is > similar to Apache's SSLProtocols directive, except that the list is > colon-separated instead of whitespace-separated, although that is easy > to change if it proves unpopular. Hello, Here is my review of the patch against master branch: * The patch applies and compiles cleanly, except for sgml docs: postgres.xml:66141: element varlistentry: validity error : Element varlistentry content does not follow the DTD, expecting (term+ , listitem), got (term indexterm listitem) </para></listitem></varlistentry><varlistentry ^ The fix is to move <indexterm> under the <term> tag in the material added to config.sgml by the patch. * The patch works as advertised, though the only way to verify that connections made with the protocol disabled by the GUCare indeed rejected is to edit fe-secure-openssl.c to only allow specific TLS versions. Adding configuration on the libpqside as suggested in the original discussion might help here. * The code allows specifying SSLv2 and SSLv3 in the GUC, but removes them forcibly after parsing the complete string (a warningis issued). Should we also add a note about this to the documentation? * In case the list of allowed protocols comes empty a FATAL error message is logged: "could not set the protocol list (novalid protocols available)". I think it's worth changing that to "could not set SSL protocol list..." All other relatederror/warning logs include "SSL". * The added code follows conventions and looks good to me. I didn't spot any problems in the parser. I've tried a gooddeal of different values and all seem to be parsed correctly. I would try to apply patches for older branches if there is consensus that we really need this patch and we want to back-patch it. Thanks. -- Alex
В списке pgsql-hackers по дате отправления: