Re: Is it worth accepting multiple CRLs?

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: sfrost(at)snowman(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is it worth accepting multiple CRLs?
Date: 2021-02-18 07:24:23
Message-ID: 554b446f-a210-cadc-24a1-079d88872468@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-02-17 05:05, Kyotaro Horiguchi wrote:
> The commit fe61df7f82 shot down this.
>
> This patch allows a new GUC ssl_crl_dir and a new libpq connection
> option sslcrldir to specify CRL directory, which stores multiple files
> that contains one CRL. With that method server loads only CRLs for the
> CA of the certificate being validated.
>
> Along with rebasing, the documentation is slightly reworded.

Committed this.

I changed the documentation a bit. Instead of having a separate section
describing the CRL options, I put that information directly into the
libpq and GUC sections. Some of the information, such as that the
directory files are loaded on demand, isn't so obviously useful in the
libpq case, so I found that a bit confusing. Also, I got the impression
that the hashed directory format is sort of internal to OpenSSL, and
there are several versions of that format, so I didn't want to copy over
the description of these internals. Instead, I referred to the openssl
rehash/c_rehash commands for information. If we get support for
non-OpenSSL providers, we'll probably have to revisit this.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2021-02-18 07:26:58 Re: adding wait_start column to pg_locks
Previous Message Michael Paquier 2021-02-18 07:15:44 Re: pg_collation_actual_version() ERROR: cache lookup failed for collation 123