Skip to content
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

Allow to build cargo-pgrx either with rustls (default) or native-tls #1448

Merged
merged 1 commit into from
Dec 27, 2023
Merged

Allow to build cargo-pgrx either with rustls (default) or native-tls #1448

merged 1 commit into from
Dec 27, 2023

Conversation

jirutka
Copy link
Contributor

@jirutka jirutka commented Dec 27, 2023

ureq defines default = ["tls", "gzip"], so "tls" feature (rustls) is currently always enabled even when native-tls is preferred, i.e. both rustls and native-tls is built if openssl headers are available and the user cannot opt-out from using rustls. This also disallows building cargo-pgrx on platforms not supported by the ring crate (dependency of rustls).

This should also solve #1430 if cargo-pgrx is built with --no-default-features --features native-tls.

Supersedes #1442

ureq defines `default = ["tls", "gzip"]`, so "tls" feature (rustls)
is currently always enabled even when native-tls is preferred, i.e. both
rustls and native-tls is built if openssl headers are available and the
user cannot opt-out from using rustls. This also disallows building
cargo-pgrx on platforms not supported by the ring crate (dependency of
rustls).

This should also solve #1430 if cargo-pgrx is built with
`--no-default-features --features native-tls`.
@workingjubilee
Copy link
Member

Ah, I see. That does make more sense. My apologies, I misapprehended what was being fixed due to the conversation drift.

@workingjubilee
Copy link
Member

Right, this seems fine, and any followup fixes we require (like the one for #1430 with rustls enabled, which I think is actually even easier than I thought, now that I look) are easier to do with the two features properly partitioned out. Thank you!

@workingjubilee workingjubilee merged commit 2990104 into pgcentralfoundation:develop Dec 27, 2023
8 checks passed
@jirutka jirutka deleted the fix-ureq-features-2 branch December 27, 2023 23:52
workingjubilee pushed a commit that referenced this pull request Jan 24, 2024
…1448)

ureq defines `default = ["tls", "gzip"]`, so "tls" feature (rustls) is
currently always enabled even when native-tls is preferred, i.e. both
rustls and native-tls is built if openssl headers are available and the
user cannot opt-out from using rustls. This also disallows building
cargo-pgrx on platforms not supported by the ring crate (dependency of
rustls).

This should also solve #1430 if `cargo-pgrx` is built with
`--no-default-features --features native-tls`.
workingjubilee added a commit that referenced this pull request Jan 25, 2024
The pgrx 0.11.3 release addresses a few UB risks in pgrx, updates its
dependencies on many points, and includes many additional headers. It
should also now be easier to use cargo-pgrx on more-complicated network
configurations.

## New Bindings!

New bindings added thanks to
- @burmecia in #1432
- @daamien in
  - #1431
  - #1485
- @rebasedming in #1486
- @usamoi in #1436
- @workingjubilee in
#1453

## "...wait, that's UB?"

Two UB fixes!
- Thanks to @Lokathor in
#1443
- Thanks to @usamoi in
#1466

## Ergonomics

- A better `ereport!` macro in
#1472

## Less transport-level security problems in cargo-pgrx

- We no longer secretly require rustls! Thanks to @jirutka in
#1448
- We now use native certs if possible, even with rustls, since
#1449

Together these should mean it's possible to actually use cargo-pgrx on
whatever your network configuration is, but you might have to use `cargo
install --no-default-features --features native-tls` to install with
native-tls (which, on Linux, means OpenSSL). By default, you will use
rustls.

## Many dependency updates

These address some largely-hypothetical security risks, but one is
particularly important: the bindgen update means we now should be
compatible with some aarch64 builds that might have failed.

- #1492
- #1493
- #1494
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants