<div><div>I also like the concept of .libprc. But if we think about it within the current state of configuration: let's say the user doesn't want to specify a CRL file, even in the default location (~/.postgresql/root.crl), we, as the client-side of PostgreSQL, have no right to refuse a connection to the database server. In that case, would it be correct to log that the user didn't specify a CRL file (even in (~/.postgresql/root.crl))?</div><div>The idea of the patch is to ensure that the client-side performs stricter configuration checking for CRL files than it currently does.</div><div> </div><div>--</div><div>Michael</div></div><div><br /></div><div><br /></div><div>----------------</div>
<div>Кому: Михаил Купцов (mr(dot)cuptsov2018(at)yandex(dot)ru);<br /></div>
<div>Копия: pgsql-hackers(at)lists(dot)postgresql(dot)org;<br /></div>
<div>Тема: Changing client-side behavior regarding Certificate Revocation Lists (CRL);<br /></div>
<div>25.08.2026, 15:08, "Daniel Gustafsson" <daniel(at)yesql(dot)se>:<br /></div>
<blockquote><blockquote class="210e7a848e8fcb45wmi-quote"> On 24 Aug 2026, at 17:34, Михаил Купцов <<a href="mailto:mr(dot)cuptsov2018(at)yandex(dot)ru">mr(dot)cuptsov2018(at)yandex(dot)ru</a>> wrote:<br /></blockquote><p><br /></p><blockquote class="210e7a848e8fcb45wmi-quote"> I would like to propose a different approach regarding the client side behavior<br /> in terms of working with the list of revoked certificates. The problem that<br /> was discovered is that if a user, using psql, accidentally specifies an<br /> incorrect path to a crl file or crl directory, the client part of Postgres<br /> ignores the user's error and connects the client to the database whose<br /> certificate the client would, in theory, want to check whether the database<br /> server certificate has been revoked.<br /></blockquote><p><br /><br />I'm sympathetic to the idea of helping the user detect misconfiguration.<br />However, I wonder how common it is to have a "local default" filename<br />configured in apps which may or may not be present. If those users all of a<br />sudden cannot connect after an upgrade then we didn't really improve anything.<br /><br />Also, with this patch, users who have placed their CRL to match the default CRL<br />file location (~/.postgresql/root.crl) won't get an error if that file is<br />missing even if their intention was to use that file.<br /><br />I think a stricter CRL policy would need another trigger.<br /><br /></p><span class="f55bbb4eeef208e8wmi-sign">-- <br />Daniel Gustafsson<br /></span></blockquote>