forked from postgres/postgres
-
Notifications
You must be signed in to change notification settings - Fork 0
2021 08 10 gustafsson patch #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
kevinburke
wants to merge
10
commits into
master
Choose a base branch
from
2021-08-10-gustafsson-patch
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit contains the frontend and backend portion of TLS support in libpq to allow encrypted connections using NSS. The implementation is done as a drop-in replacement for the OpenSSL support and leverages the same internal API for abstracting library specific details. A new GUC, ssl_database, is used to identify the NSS database used for the serverside certificates and keys. The existing certificate and key GUCs are used for providing certificate and key nicknames. Client side there is a new connection parameter, cert_database, to identify the client cert and key. All existing sslmodes are supported in the same way as with OpenSSL. Authors: Daniel Gustafsson, Andrew Dunstan, Jacob Champion Reviewed-by: Michael Paquier
The SSL testharness was fully tied to OpenSSL in the way the server was set up and reconfigured. This refactors the SSLServer module into a SSL library agnostic SSL/Server module which in turn use SSL/Backend/<lib> modules for the implementation details. No changes are done to the actual tests, this only change how setup and teardown is performed.
This adds the SSL/Backend/NSS which implements the setup and teardown required as well as adds the NSS configuration to the existing tests. The OpenSSL testfiles are reused by repackaging them into NSS databases in order for the tests to be cross-library. Additional testfiles are generated by using only the NSS toolchain as well as rudimentary tests using these.
...in a similar manner to command_like(), to catch notices-as-errors coming from NSS.
This adds support for using the RNG in libnss as a backend for pg_strong_random.
Basic documentation of the new API (keypass hooks) as well as config parameters and installation. Additionally there is a section on how to create certificate and keys using the NSS toolchain.
This extends pgcrypto to be able to use libnss as a cryptographic backend for pgcrypto much like how OpenSSL is a supported backend. Blowfish is not a supported cipher in NSS, so the implementation falls back on the built-in BF code to be compatible in terms of cipher support.
Since sslinfo to a large extent uses the be_tls_* API this mostly disables functionality which currently is OpenSSL specific.
This adds support for using libnss as a crypto backend for the built- in cryptohash support. Much of this code is similar to the pgcrypto support.
Finally this adds the infrastructure to build a postgres installation with libnss support.
kevinburke
pushed a commit
that referenced
this pull request
Sep 14, 2021
Currently the pc files use hard coded paths for "includedir" and "libdir." Example: Cflags: -I/usr/include Libs: -L/usr/lib -lpq This is not very fortunate when cross compiling inside a buildroot, where the includes and libs are inside a staging directory, because this introduces host paths into the build: checking for pkg-config... /builder/shared-workdir/build/sdk/staging_dir/host/bin/pkg-config checking for PostgreSQL libraries via pkg_config... -L/usr/lib <---- This commit addresses this by doing the following two things: 1. Instead of hard coding the paths in "Cflags" and "Libs" "${includedir}" and "${libdir}" are used. Note: these variables can be overriden on the pkg-config command line ("--define-variable=libdir=/some/path"). 2. Add the variables "prefix" and "exec_prefix". If "includedir" and/or "libdir" are using these then construct them accordingly. This is done because buildroots (for instance OpenWrt) tend to rename the real pkg-config and call it indirectly from a script that sets "prefix", "exec_prefix" and "bindir", like so: pkg-config.real --define-variable=prefix=${STAGING_PREFIX} \ --define-variable=exec_prefix=${STAGING_PREFIX} \ --define-variable=bindir=${STAGING_PREFIX}/bin $@ Example #1: user calls ./configure with "--libdir=/some/lib" and "--includedir=/some/include": prefix=/usr/local/pgsql exec_prefix=${prefix} libdir=/some/lib includedir=/some/include Name: libpq Description: PostgreSQL libpq library Url: http://www.postgresql.org/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm Example #2: user calls ./configure with no arguments: prefix=/usr/local/pgsql exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libpq Description: PostgreSQL libpq library Url: http://www.postgresql.org/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm Like this the paths can be forced into the staging directory when using a buildroot setup: checking for pkg-config... /home/sk/tmp/openwrt/staging_dir/host/bin/pkg-config checking for PostgreSQL libraries via pkg_config... -L/home/sk/tmp/openwrt/staging_dir/target-mips_24kc_musl/usr/lib Author: Sebastian Kemper <[email protected]> Co-authored-by: Peter Eisentraut <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/20200305213827.GA25135%40darth.lan
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.