-
Notifications
You must be signed in to change notification settings - Fork 19
Search only canonical paths on FreeBSD #39
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
base: main
Are you sure you want to change the base?
Conversation
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 Differential Revision: https://reviews.freebsd.org/D53489
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…store uv uses openssl_probe::probe() transitively which unfortunately discovers the wrong truststore sources resulting in certificate validation errors even if certctl(8) manages everything nicely. The selected provider might be OpenSSL from the system, vendored OpenSSL, rustls or maybe something else. Note: uv still requires you to use --native-tls or UV_NATIVE_TLS=1 Approved by: yuri (maintainer), mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4
…store uv uses openssl_probe::probe() transitively which unfortunately discovers the wrong truststore sources resulting in certificate validation errors even if certctl(8) manages everything nicely. The selected provider might be OpenSSL from the system, vendored OpenSSL, rustls or maybe something else. Note: uv still requires you to use --native-tls or UV_NATIVE_TLS=1 Approved by: yuri (maintainer), mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53490
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…store uv uses openssl_probe::probe() transitively which unfortunately discovers the wrong truststore sources resulting in certificate validation errors even if certctl(8) manages everything nicely. The selected provider might be OpenSSL from the system, vendored OpenSSL, rustls or maybe something else. Note: uv still requires you to use --native-tls or UV_NATIVE_TLS=1 Approved by: yuri (maintainer), mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53490
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…store uv uses openssl_probe::probe() transitively which unfortunately discovers the wrong truststore sources resulting in certificate validation errors even if certctl(8) manages everything nicely. The selected provider might be OpenSSL from the system, vendored OpenSSL, rustls or maybe something else. Note: uv still requires you to use --native-tls or UV_NATIVE_TLS=1 Approved by: yuri (maintainer), mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53490
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…store uv uses openssl_probe::probe() transitively which unfortunately discovers the wrong truststore sources resulting in certificate validation errors even if certctl(8) manages everything nicely. The selected provider might be OpenSSL from the system, vendored OpenSSL, rustls or maybe something else. Note: uv still requires you to use --native-tls or UV_NATIVE_TLS=1 Approved by: yuri (maintainer), mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53490
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to "duplicate" as much API as you've done here -- we can probably scope it down a fair bit. For example, we could name the slice within candidate_cert_dirs() and use a different defintion for FreeBSD.
Is the main issue that prevents it from working right today the different order?
|
Note: it's better not to refer to GitHub entities (whether users or PRs) in commit messages, as they will generate a lot of backreferences (as can be seen above). Instead, suggest linking to the PR in the upstream PR description. |
I see, I did it not purpose not to nag people, but to establish context between upstream and downstream. I want tracebility for all participants. |
Yes, at the end it boils down to order and a narrower list. If the wrong one comes first your actual store is never seen. This is why I have done a new method, we can add the |
603a14a to
759f848
Compare
|
Here is a patch which uses The problem I have is that is is basically incompatible with the |
FreeBSD contains a canonical certstore managed by certctl(8) located in the base system (/etc/ssl), search there first. Alternatively, a user can populate a custom store in distbase (/usr/local/etc/ssl) with certctl(8) which shall be queried if the former does not exist. At last, there is a store for OpenSSL from the ports (/usr/local/openssl) outside of certctl(8)'s reach. This fixes rustls#20 and fixes rustls#37
759f848 to
c020650
Compare
| "CARootCertificates.pem", | ||
| "tls-ca-bundle.pem", | ||
| ]; | ||
| #[cfg(target_os = "freebsd")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you actually need these? Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily, it just reduces the list because the other files will never exist by default with the other dirs I have supplied. "ca-root-nss.crt" is missing. I can it and collapse the list.
Sake of completeness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you know they will never exist? Aren't users allowed to put stuff there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory you are right, but
- vast majority will use certlctl(8)
- outside of depicted default paths you can always resort to the env vars (home grown)
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
…ric one Previously, git2-rs was modified, but the actual issue lies in openssl-probe which has been modified to accomondate FreeBSD system default truststore. This change supersedes 0780826. Approved by: mikael (rust maintainer) Obtained from: rustls/openssl-probe#39 MFH: 2025Q4 Differential Revision: https://reviews.freebsd.org/D53489
FreeBSD contains a canonical certstore managed by certctl(8) located in the base system (/etc/ssl), search there first. Alternatively, a user can populate a custom store in distbase (/usr/local/etc/ssl) with certctl(8) which shall be queried if the former does not exist. At last, there is a store for OpenSSL from the ports (/usr/local/openssl) outside of certctl(8)'s reach.
This fixes #20 and fixes #37
FreeBSD port maintainer here.
Solution approach: Instead of trying to shuffle around the actual arrays and causing regressions in other places I can never test I have intentionally introduced
#cfgwhich I know for sure works on FreeBSD throughout the bank. I have patched rust-1.90.0 and uv-0.9.6 which both include openssl-probe-0.1.6 and built both in a jail.Verification in a standalone application while removing and adding potential candidates:
Running against publically available servers as well as in-house with enterprise CA structure.
uv initially:
cargo after patch:
uv after patch:
Temporary downstream patches for the FreeBSD ports system: freebsd/freebsd-ports@main...michael-o:freebsd-ports:openssl-probe-freebsd
FreeBSD ports which will potentially benefit from in the long run:
Note: I am not a Rust developer at all. If you know this can be done more elegently, please tell!
@emaste @MikaelUrankar @dag-erling