=== Applying patches on top of PostgreSQL commit ID 53a49365052026907afff7613929710d1e7f0da0 ===
/etc/rc.d/jail: WARNING: Per-jail configuration via jail_* variables  is obsolete.  Please consider migrating to /etc/jail.conf.
Fri Jan 31 20:39:25 UTC 2025
On branch cf/5088
nothing to commit, working tree clean
=== applying patch ./v1-0001-docs-improve-hostssl-related-descriptions-and-option.patch
Applied patch to 'doc/src/sgml/client-auth.sgml' with conflicts.
Applied patch to 'doc/src/sgml/runtime.sgml' cleanly.
U doc/src/sgml/client-auth.sgml
diff --cc doc/src/sgml/client-auth.sgml
index 782b49c85a,638c8e7057..0000000000
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@@ -673,41 -666,10 +675,48 @@@ include_dir         <replaceable>direct
        </para>
  
        <para>
++<<<<<<< ours
 +       In addition to the method-specific options listed below, there is a
 +       method-independent authentication option <literal>clientcert</literal>, which
 +       can be specified in any <literal>hostssl</literal> record.
 +       This option can be set to <literal>verify-ca</literal> or
 +       <literal>verify-full</literal>. Both options require the client
 +       to present a valid (trusted) SSL certificate, while
 +       <literal>verify-full</literal> additionally enforces that the
 +       <literal>cn</literal> (Common Name) in the certificate matches
 +       the username or an applicable mapping.
 +       This behavior is similar to the <literal>cert</literal> authentication
 +       method (see <xref linkend="auth-cert"/>) but enables pairing
 +       the verification of client certificates with any authentication
 +       method that supports <literal>hostssl</literal> entries.
 +      </para>
 +      <para>
 +       On any record using client certificate authentication (i.e. one
 +       using the <literal>cert</literal> authentication method or one
 +       using the <literal>clientcert</literal> option), you can specify
 +       which part of the client certificate credentials to match using
 +       the <literal>clientname</literal> option. This option can have one
 +       of two values. If you specify <literal>clientname=CN</literal>, which
 +       is the default, the username is matched against the certificate's
 +       <literal>Common Name (CN)</literal>. If instead you specify
 +       <literal>clientname=DN</literal> the username is matched against the
 +       entire <literal>Distinguished Name (DN)</literal> of the certificate.
 +       This option is probably best used in conjunction with a username map.
 +       The comparison is done with the <literal>DN</literal> in
 +       <ulink url="https://datatracker.ietf.org/doc/html/rfc2253">RFC 2253</ulink>
 +       format. To see the <literal>DN</literal> of a client certificate
 +       in this format, do
 +<programlisting>
 +openssl x509 -in myclient.crt -noout -subject -nameopt RFC2253 | sed "s/^subject=//"
 +</programlisting>
 +        Care needs to be taken when using this option, especially when using
 +        regular expression matching against the <literal>DN</literal>.
++=======
+        The <literal>hostssl</literal> connection type, in addition to allowing any
+        authentication-method-specific options, allows the
+        <literal>auth-options</literal> detailed in <xref linkend="auth-cert"/> for
+        the <literal>cert</literal> authentication method.
++>>>>>>> theirs
        </para>
       </listitem>
      </varlistentry>