2021-10-19 20:11:42 +02:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# Makefile for sslfiles
|
|
|
|
|
#
|
|
|
|
|
# The SSL test files are completely disjoint from the rest of the build; they
|
|
|
|
|
# don't rely on other targets or on Makefile.global. Since these recipes rely
|
|
|
|
|
# on some default Make behavior that's disabled in the main build tree, such
|
|
|
|
|
# as intermediate cleanup, they've been moved into their own separate file.
|
|
|
|
|
# The main Makefile in this directory defers to this helper file when
|
|
|
|
|
# building the sslfiles-related targets.
|
|
|
|
|
#
|
2023-01-02 21:00:37 +01:00
|
|
|
# Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2021-10-19 20:11:42 +02:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
#
|
|
|
|
|
# src/test/ssl/sslfiles.mk
|
|
|
|
|
#
|
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# To add a new server or client certificate, add a new <name>.config file in
|
|
|
|
|
# the conf/ directory, then add <name> to either SERVERS or CLIENTS below. A
|
|
|
|
|
# key/certificate pair will be generated for you, signed by the appropriate CA.
|
|
|
|
|
#
|
|
|
|
|
SERVERS := server-cn-and-alt-names \
|
2022-04-01 15:41:44 +02:00
|
|
|
server-cn-and-ip-alt-names \
|
2021-10-19 20:11:42 +02:00
|
|
|
server-cn-only \
|
2022-04-01 15:41:44 +02:00
|
|
|
server-ip-alt-names \
|
2022-04-01 14:06:23 +02:00
|
|
|
server-ip-cn-only \
|
2022-04-01 15:41:44 +02:00
|
|
|
server-ip-cn-and-alt-names \
|
|
|
|
|
server-ip-cn-and-dns-alt-names \
|
2022-04-01 14:06:23 +02:00
|
|
|
server-ip-in-dnsname \
|
2021-10-19 20:11:42 +02:00
|
|
|
server-single-alt-name \
|
|
|
|
|
server-multiple-alt-names \
|
|
|
|
|
server-no-names \
|
|
|
|
|
server-revoked
|
2022-09-13 16:10:50 +02:00
|
|
|
CLIENTS := client client-dn client-revoked client_ext client-long \
|
|
|
|
|
client-revoked-utf8
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
#
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
# To add a new non-standard certificate, add it to SPECIAL_CERTS and then add
|
|
|
|
|
# a recipe for creating it to the "Special-case certificates" section below.
|
2021-10-19 20:11:42 +02:00
|
|
|
#
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
SPECIAL_CERTS := ssl/server-rsapss.crt
|
|
|
|
|
|
|
|
|
|
# Likewise for non-standard keys
|
2021-10-19 20:11:42 +02:00
|
|
|
SPECIAL_KEYS := ssl/server-password.key \
|
|
|
|
|
ssl/client-der.key \
|
|
|
|
|
ssl/client-encrypted-pem.key \
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
ssl/client-encrypted-der.key \
|
|
|
|
|
ssl/server-rsapss.key
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# These files are just concatenations of other files. You can add new ones to
|
|
|
|
|
# COMBINATIONS here, then declare the constituent files as dependencies in the
|
|
|
|
|
# "Combined files" section below.
|
|
|
|
|
#
|
|
|
|
|
COMBINATIONS := \
|
|
|
|
|
ssl/both-cas-1.crt \
|
|
|
|
|
ssl/both-cas-2.crt \
|
|
|
|
|
ssl/root+server_ca.crt \
|
|
|
|
|
ssl/root+server.crl \
|
|
|
|
|
ssl/root+client_ca.crt \
|
|
|
|
|
ssl/root+client.crl \
|
2023-04-05 23:22:17 +02:00
|
|
|
ssl/client+client_ca.crt \
|
|
|
|
|
ssl/server-cn-only+server_ca.crt
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
CERTIFICATES := root_ca server_ca client_ca $(SERVERS) $(CLIENTS)
|
|
|
|
|
STANDARD_CERTS := $(CERTIFICATES:%=ssl/%.crt)
|
|
|
|
|
STANDARD_KEYS := $(CERTIFICATES:%=ssl/%.key)
|
|
|
|
|
CRLS := ssl/root.crl \
|
|
|
|
|
ssl/client.crl \
|
|
|
|
|
ssl/server.crl
|
|
|
|
|
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
SSLFILES := \
|
|
|
|
|
$(STANDARD_CERTS) \
|
|
|
|
|
$(STANDARD_KEYS) \
|
|
|
|
|
$(SPECIAL_CERTS) \
|
|
|
|
|
$(SPECIAL_KEYS) \
|
|
|
|
|
$(COMBINATIONS) \
|
|
|
|
|
$(CRLS)
|
2021-10-19 20:11:42 +02:00
|
|
|
SSLDIRS := ssl/client-crldir \
|
|
|
|
|
ssl/server-crldir \
|
|
|
|
|
ssl/root+client-crldir \
|
|
|
|
|
ssl/root+server-crldir
|
|
|
|
|
|
|
|
|
|
# This target re-generates all the key and certificate files. Usually we just
|
|
|
|
|
# use the ones that are committed to the tree without rebuilding them.
|
|
|
|
|
#
|
|
|
|
|
.PHONY: sslfiles
|
|
|
|
|
sslfiles: $(SSLFILES) $(SSLDIRS)
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Special-case certificates
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
# Root CA is self-signed.
|
|
|
|
|
ssl/root_ca.crt: ssl/root_ca.key conf/root_ca.config
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) req -new -x509 -config conf/root_ca.config -days 10000 -key $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
# Certificate using RSA-PSS algorithm. Also self-signed.
|
|
|
|
|
ssl/server-rsapss.crt: ssl/server-rsapss.key conf/server-rsapss.config
|
|
|
|
|
$(OPENSSL) req -new -x509 -config conf/server-rsapss.config -key $< -out $@
|
|
|
|
|
|
2021-10-19 20:11:42 +02:00
|
|
|
#
|
|
|
|
|
# Special-case keys
|
|
|
|
|
#
|
|
|
|
|
# All targets here are contained in $(SPECIAL_KEYS).
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
# Password-protected version of server-cn-only.key
|
|
|
|
|
ssl/server-password.key: ssl/server-cn-only.key
|
2023-08-22 09:26:36 +02:00
|
|
|
$(OPENSSL) pkey -aes256 -in $< -out $@ -passout 'pass:secret1'
|
2021-10-19 20:11:42 +02:00
|
|
|
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
# Key that uses the RSA-PSS algorithm
|
|
|
|
|
ssl/server-rsapss.key:
|
|
|
|
|
$(OPENSSL) genpkey -algorithm rsa-pss -out $@
|
|
|
|
|
|
2021-10-19 20:11:42 +02:00
|
|
|
# DER-encoded version of client.key
|
|
|
|
|
ssl/client-der.key: ssl/client.key
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) rsa -in $< -outform DER -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
# Convert client.key to encrypted PEM (X.509 text) and DER (X.509 ASN.1)
|
|
|
|
|
# formats to test libpq's support for the sslpassword= option.
|
|
|
|
|
ssl/client-encrypted-pem.key: ssl/client.key
|
2023-08-22 09:26:36 +02:00
|
|
|
$(OPENSSL) pkey -in $< -outform PEM -aes128 -passout 'pass:dUmmyP^#+' -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
# TODO Explicitly choosing -aes128 generates a key unusable to PostgreSQL with
|
|
|
|
|
# OpenSSL 3.0.0, so fall back on the default for now.
|
|
|
|
|
ssl/client-encrypted-der.key: ssl/client.key
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) rsa -in $< -outform DER -passout 'pass:dUmmyP^#+' -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Combined files
|
|
|
|
|
#
|
|
|
|
|
# All targets in $(COMBINATIONS) share a single recipe; just declare the
|
|
|
|
|
# necessary dependencies and they'll be smashed together.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
# Root certificate file that contains both CA certificates, for testing
|
|
|
|
|
# that multiple certificates can be used.
|
|
|
|
|
ssl/both-cas-1.crt: ssl/root_ca.crt ssl/client_ca.crt ssl/server_ca.crt
|
|
|
|
|
|
|
|
|
|
# The same, but the certs are in different order
|
|
|
|
|
ssl/both-cas-2.crt: ssl/root_ca.crt ssl/server_ca.crt ssl/client_ca.crt
|
|
|
|
|
|
|
|
|
|
# A root certificate file for the client, to validate server certs.
|
|
|
|
|
ssl/root+server_ca.crt: ssl/root_ca.crt ssl/server_ca.crt
|
|
|
|
|
|
|
|
|
|
# and for the server, to validate client certs
|
|
|
|
|
ssl/root+client_ca.crt: ssl/root_ca.crt ssl/client_ca.crt
|
|
|
|
|
|
|
|
|
|
# and for the client, to present to the server
|
|
|
|
|
ssl/client+client_ca.crt: ssl/client.crt ssl/client_ca.crt
|
|
|
|
|
|
2023-04-05 23:22:17 +02:00
|
|
|
# for the server, to present to a client that only knows the root
|
|
|
|
|
ssl/server-cn-only+server_ca.crt: ssl/server-cn-only.crt ssl/server_ca.crt
|
|
|
|
|
|
2021-10-19 20:11:42 +02:00
|
|
|
# If a CRL is used, OpenSSL requires a CRL file for *all* the CAs in the
|
|
|
|
|
# chain, even if some of them are empty.
|
|
|
|
|
ssl/root+server.crl: ssl/root.crl ssl/server.crl
|
|
|
|
|
ssl/root+client.crl: ssl/root.crl ssl/client.crl
|
|
|
|
|
|
|
|
|
|
$(COMBINATIONS):
|
|
|
|
|
cat $^ > $@
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Standard keys
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
$(STANDARD_KEYS):
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) genrsa -out $@ 2048
|
2021-10-19 20:11:42 +02:00
|
|
|
chmod 0600 $@
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Standard certificates
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
CA_CERTS := ssl/server_ca.crt ssl/client_ca.crt
|
|
|
|
|
SERVER_CERTS := $(SERVERS:%=ssl/%.crt)
|
|
|
|
|
CLIENT_CERTS := $(CLIENTS:%=ssl/%.crt)
|
|
|
|
|
|
|
|
|
|
# See the "CA State" section below.
|
|
|
|
|
root_ca_state_files := ssl/root_ca-certindex ssl/root_ca-certindex.attr ssl/root_ca.srl
|
|
|
|
|
server_ca_state_files := ssl/server_ca-certindex ssl/server_ca-certindex.attr ssl/server_ca.srl
|
|
|
|
|
client_ca_state_files := ssl/client_ca-certindex ssl/client_ca-certindex.attr ssl/client_ca.srl
|
|
|
|
|
|
|
|
|
|
# These are the workhorse recipes. `openssl ca` can't be safely run from
|
|
|
|
|
# parallel processes, so we must mark the entire Makefile .NOTPARALLEL.
|
|
|
|
|
.NOTPARALLEL:
|
|
|
|
|
$(CA_CERTS): ssl/%.crt: ssl/%.csr conf/%.config conf/cas.config ssl/root_ca.crt | ssl/new_certs_dir $(root_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -batch -config conf/cas.config -name root_ca -notext -in $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
$(SERVER_CERTS): ssl/%.crt: ssl/%.csr conf/%.config conf/cas.config ssl/server_ca.crt | ssl/new_certs_dir $(server_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -batch -config conf/cas.config -name server_ca -notext -in $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
$(CLIENT_CERTS): ssl/%.crt: ssl/%.csr conf/%.config conf/cas.config ssl/client_ca.crt | ssl/new_certs_dir $(client_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -batch -config conf/cas.config -name client_ca -notext -in $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
# The CSRs don't need to persist after a build.
|
|
|
|
|
.INTERMEDIATE: $(CERTIFICATES:%=ssl/%.csr)
|
|
|
|
|
ssl/%.csr: ssl/%.key conf/%.config
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) req -new -utf8 -key $< -out $@ -config conf/$*.config
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# CA State
|
|
|
|
|
#
|
|
|
|
|
# All of these are intended to be order-only dependencies; additionally, the
|
|
|
|
|
# pattern recipes are marked as explicit intermediates. The goal is for Make to
|
|
|
|
|
# create the state files once for each CA, allow them to accumulate whatever
|
|
|
|
|
# state is needed, and then automatically remove them at the end of the run.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
.INTERMEDIATE: $(root_ca_state_files) $(server_ca_state_files) $(client_ca_state_files)
|
|
|
|
|
|
|
|
|
|
# OpenSSL requires a directory to put all generated certificates in. We don't
|
|
|
|
|
# use this for anything, but we need a location.
|
|
|
|
|
ssl/new_certs_dir:
|
|
|
|
|
mkdir $@
|
|
|
|
|
|
|
|
|
|
ssl/%-certindex:
|
|
|
|
|
touch $@
|
|
|
|
|
|
|
|
|
|
ssl/%-certindex.attr:
|
|
|
|
|
echo "unique_subject=no" > $@
|
|
|
|
|
|
|
|
|
|
# The first serial number for each CA is based on the current timestamp, to
|
|
|
|
|
# avoid collisions across Make runs.
|
|
|
|
|
ssl/%.srl:
|
|
|
|
|
date +%Y%m%d%H%M%S00 > $@
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# CRLs
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
ssl/root.crl: ssl/root_ca.crt | $(root_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -config conf/cas.config -name root_ca -gencrl -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
ssl/server.crl: ssl/server-revoked.crt ssl/server_ca.crt | $(server_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -config conf/cas.config -name server_ca -revoke $<
|
|
|
|
|
$(OPENSSL) ca -config conf/cas.config -name server_ca -gencrl -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
2022-09-13 16:10:50 +02:00
|
|
|
ssl/client.crl: ssl/client-revoked.crt ssl/client-revoked-utf8.crt ssl/client_ca.crt | $(client_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -config conf/cas.config -name client_ca -revoke ssl/client-revoked.crt
|
|
|
|
|
$(OPENSSL) ca -config conf/cas.config -name client_ca -revoke ssl/client-revoked-utf8.crt
|
|
|
|
|
$(OPENSSL) ca -config conf/cas.config -name client_ca -gencrl -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# CRL hash directories
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
ssl/root+server-crldir: ssl/server.crl ssl/root.crl
|
|
|
|
|
ssl/root+client-crldir: ssl/client.crl ssl/root.crl
|
|
|
|
|
ssl/server-crldir: ssl/server.crl
|
|
|
|
|
ssl/client-crldir: ssl/client.crl
|
|
|
|
|
|
2022-10-20 21:01:05 +02:00
|
|
|
crlhashfile = $(shell $(OPENSSL) crl -hash -noout -in $(1)).r0
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
|
ssl/%-crldir:
|
|
|
|
|
mkdir -p $@
|
|
|
|
|
rm -f $@/*.r0
|
|
|
|
|
$(foreach crl,$^,cp $(crl) $@/$(call crlhashfile,$(crl)) &&) true
|
|
|
|
|
touch $@
|
|
|
|
|
|
|
|
|
|
.PHONY: sslfiles-clean
|
|
|
|
|
sslfiles-clean:
|
|
|
|
|
rm -f $(SSLFILES) ssl/*.old ssl/*.csr ssl/*.srl ssl/*-certindex*
|
|
|
|
|
rm -rf $(SSLDIRS) ssl/new_certs_dir
|
|
|
|
|
|
|
|
|
|
# The difference between the below clean targets and sslfiles-clean is that the
|
|
|
|
|
# clean targets will be run during a "standard" recursive clean run from the
|
|
|
|
|
# main build tree. The sslfiles-clean target must be run explicitly from this
|
|
|
|
|
# directory.
|
Remove distprep
A PostgreSQL release tarball contains a number of prebuilt files, in
particular files produced by bison, flex, perl, and well as html and
man documentation. We have done this consistent with established
practice at the time to not require these tools for building from a
tarball. Some of these tools were hard to get, or get the right
version of, from time to time, and shipping the prebuilt output was a
convenience to users.
Now this has at least two problems:
One, we have to make the build system(s) work in two modes: Building
from a git checkout and building from a tarball. This is pretty
complicated, but it works so far for autoconf/make. It does not
currently work for meson; you can currently only build with meson from
a git checkout. Making meson builds work from a tarball seems very
difficult or impossible. One particular problem is that since meson
requires a separate build directory, we cannot make the build update
files like gram.h in the source tree. So if you were to build from a
tarball and update gram.y, you will have a gram.h in the source tree
and one in the build tree, but the way things work is that the
compiler will always use the one in the source tree. So you cannot,
for example, make any gram.y changes when building from a tarball.
This seems impossible to fix in a non-horrible way.
Second, there is increased interest nowadays in precisely tracking the
origin of software. We can reasonably track contributions into the
git tree, and users can reasonably track the path from a tarball to
packages and downloads and installs. But what happens between the git
tree and the tarball is obscure and in some cases non-reproducible.
The solution for both of these issues is to get rid of the step that
adds prebuilt files to the tarball. The tarball now only contains
what is in the git tree (*). Getting the additional build
dependencies is no longer a problem nowadays, and the complications to
keep these dual build modes working are significant. And of course we
want to get the meson build system working universally.
This commit removes the make distprep target altogether. The make
dist target continues to do its job, it just doesn't call distprep
anymore.
(*) - The tarball also contains the INSTALL file that is built at make
dist time, but not by distprep. This is unchanged for now.
The make maintainer-clean target, whose job it is to remove the
prebuilt files in addition to what make distclean does, is now just an
alias to make distprep. (In practice, it is probably obsolete given
that git clean is available.)
The following programs are now hard build requirements in configure
(they were already required by meson.build):
- bison
- flex
- perl
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2023-11-06 14:51:52 +01:00
|
|
|
.PHONY: clean distclean
|
|
|
|
|
clean distclean:
|
2021-10-19 20:11:42 +02:00
|
|
|
rm -rf ssl/*.old ssl/new_certs_dir ssl/client*_tmp.key
|
