UV 0.2.29 Permission error #5448
Comments
|
Thanks for the report! We will investigate. Are you using native TLS? |
|
Can this be reproduced in a Docker image? |
Yes, I'm using native TLS, set in the env var. |
|
|
This is probably an error reading the certificates from your system, presumably caused by a change in one of our dependencies. You may want to try |
This would be super useful, especially if we need to file an issue upstream. |
|
This is probably rustls/rustls-native-certs#116. |
|
Apparently this is a sign of real problem though. The subsequent PR just surfaces more context in the error, so I suspect there is an actual permissions mismatch at play in your setup: rustls/rustls-native-certs#117 |
|
Here you have the RUST_LOG=trace output: |
|
I'm attaching the same output with uv 0.2.28 (same machine and env, with version specified). It still works. |
|
The DOCKERFILE: The error: To confirm the certificate was well installed: In another run, I removed the custom certificate (rebuild the image without the COPY), but curl fails of course: But uv installs rich fine: uv0.2.29-install-with-non-trusted-certificate.txt To confirm company CA is being added by the proxy, I got the certificate chain with where ISINFRA is my self-signed certificate. In the original Dockerfile, if I swap uv with version 0.2.28, it works fine. 0.2.28 also installs when the certificate is not added to the chain (accepts a self-signed certificate, even if not added to CA trust), but I think this is another issue. |
|
Hmm, could you share the permissions on |
|
Only root can read and write, no permission to all other users. The certificate is concatenated in a larger certificates file by ubuntu… I don’t think applications should have access to it directly, I maybe wrong.Envoyé de mon iPhoneLe 26 juil. 2024 à 16:50, Charlie Marsh ***@***.***> a écrit :
Hmm, could you share the permissions on ROOT_CRT.crt? Like ls -l? I'm trying to reproduce myself.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
The |
|
Yes, just to add the ca to the chain.Envoyé de mon iPhoneLe 26 juil. 2024 à 17:49, Charlie Marsh ***@***.***> a écrit :
The .crt file is just a public key though, right?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
What's the actual linux permissions of the file? Output should look like this Are the permissions Mainly for clarification, when you say |
|
For what it's worth, I just tried it with a Trace Info
Note, assuming Changing the dockerfile a bit might help FROM ubuntu:22.04
RUN apt update -y
RUN apt install -y ca-certificates
COPY ROOT_CRT.crt /usr/local/share/ca-certificates/ROOT_CRT.crt
RUN chmod +r /usr/local/share/ca-certificates/ROOT_CRT.crt ######## DOES ADDING THIS LINE HELP?
RUN /usr/sbin/update-ca-certificates
RUN apt install python3.11 python3.11-venv wget curl -y
RUN useradd -ms /bin/bash vuser
USER vuser
WORKDIR /home/vuser
ENV REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
ENV UV_NATIVE_TLS=1
ENV RUST_LOG=trace
ENV RUST_BACKTRACE=full
RUN python3.11 -m venv venv
RUN venv/bin/python -m pip install uv==0.2.29 |
|
Thx. I’m on vacations and I won’t have access to the machine until Thursday. I will retest with the new permission.Any reason why uv is the only software to complain? and why it was working until 0.2.28?Regarding the other problem, the self signed certificate that is accepted with the ca installed. Should I open another ticket?Envoyé de mon iPhoneLe 27 juil. 2024 à 02:37, samypr100 ***@***.***> a écrit :
For what it's worth, I just tried it with a -rw------- root root CA file under a different user and got the same backtrace. I get it on 0.2.28 as well as 0.2.30. Maybe it's a docker caching issue?
Trace Info
DEBUG uv 0.2.30
DEBUG Searching for Python interpreter in system path
TRACE Querying interpreter executable at /home/uv/.venv/bin/python3
DEBUG Found cpython-3.12.4-linux-x86_64-gnu at /home/uv/.venv/bin/python3 (virtual environment)
DEBUG Using Python 3.12.4 environment at .venv/bin/python3
TRACE Checking lock for .venv
DEBUG Acquired lock for .venv
DEBUG At least one requirement is not satisfied: flask
DEBUG Using request timeout of 30s
thread 'main' panicked at crates/uv-client/src/base_client.rs:178:33:
Failed to build HTTP client: reqwest::Error { kind: Builder, source: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } }
stack backtrace:
0: 0x556a84e726e5 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1e1a1972118942ad
1: 0x556a84ea2e8b - core::fmt::write::hc090a2ffd6b28c4a
2: 0x556a84e6e02f - std::io::Write::write_fmt::h8898bac6ff039a23
3: 0x556a84e724be - std::sys_common::backtrace::print::ha96650907276675e
4: 0x556a84e73fb9 - std::panicking::default_hook::{{closure}}::h215c2a0a8346e0e0
5: 0x556a84e73cfd - std::panicking::default_hook::h207342be97478370
6: 0x556a84e74453 - std::panicking::rust_panic_with_hook::hac8bdceee1e4fe2c
7: 0x556a84e74334 - std::panicking::begin_panic_handler::{{closure}}::h00d785e82757ce3c
8: 0x556a84e72ba9 - std::sys_common::backtrace::__rust_end_short_backtrace::h1628d957bcd06996
9: 0x556a84e74067 - rust_begin_unwind
10: 0x556a83afa603 - core::panicking::panic_fmt::hdc63834ffaaefae5
11: 0x556a83afaab6 - core::result::unwrap_failed::h82b551e0ff2b2176
12: 0x556a8491bbe6 - uv_client::base_client::BaseClientBuilder::build::hf9452ebf93eb5c9c
13: 0x556a8492b985 - uv_client::registry_client::RegistryClientBuilder::build::hc78f5b25152dc124
14: 0x556a83cdd652 - uv::commands::pip::install::pip_install::{{closure}}::h351b868011709273
15: 0x556a83cba532 - uv::run::{{closure}}::{{closure}}::hccd2d4da1bad7d73
16: 0x556a83d5fcb9 - <core::pin::Pin as core::future::future::Future>::poll::he22f133412905bcb
17: 0x556a83ecad56 - tokio::runtime::runtime::Runtime::block_on::h3dfc693dcf47d351
18: 0x556a83e7ccc3 - uv::main::h0e39d6aa198686e0
19: 0x556a83f3b439 - uv::main::hfdc0b65da80c1fb9
20: 0x556a83e7fc73 - std::sys_common::backtrace::__rust_begin_short_backtrace::h4c344b210e6c1d1d
21: 0x556a84212d49 - std::rt::lang_start::{{closure}}::h5d4ffc2485b0fefc
22: 0x556a84e63300 - std::rt::lang_start_internal::h3ed4fe7b2f419135
23: 0x556a83f3b465 - main
24: 0x7f25b4c72d90 -
25: 0x7f25b4c72e40 - __libc_start_main
26: 0x556a83afad69 -
27: 0x0 -
Note, assuming /usr/local/share/ca-certificates/ROOT_CRT.crt is just a chain of public certficates (no private keys), it is okay to be readable by everyone the same way /etc/ssl/certs/ca-certificates.crt normally is.
Changing the dockerfile a bit might help
FROM ubuntu:22.04
RUN apt update -y
RUN apt install -y ca-certificates
COPY ROOT_CRT.crt /usr/local/share/ca-certificates/ROOT_CRT.crt
RUN chmod +r /usr/local/share/ca-certificates/ROOT_CRT.crt ######## DOES ADDING THIS LINE HELP?
RUN /usr/sbin/update-ca-certificates
RUN apt install python3.11 python3.11-venv wget curl -y
RUN useradd -ms /bin/bash vuser
USER vuser
WORKDIR /home/vuser
ENV REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
ENV UV_NATIVE_TLS=1
ENV RUST_LOG=trace
ENV RUST_BACKTRACE=full
RUN python3.11 -m venv venv
RUN venv/bin/python -m pip install uv==0.2.29
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Yes, as mentioned above there was a change in rustls-native-certs: rustls/rustls-native-certs#116. The issue suggests that the library is correct to raise the error in this case though I'm not familiar enough with TLS to know if that's the case. I'll \cc @djc for visibility. |
|
Somehow I'm not able to reproduce with that Dockerfile. |
|
@charliermarsh here's a self-contained reproduceable Dockefile FROM ubuntu:24.04
RUN apt update -y
RUN apt install -y ca-certificates curl
# Add dummy cert (to simulate permission issue)
RUN curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
RUN chmod +x mkcert-v*-linux-amd64
RUN cp mkcert-v*-linux-amd64 /usr/local/bin/mkcert
RUN mkcert example.org
RUN chmod 600 example.org.pem && mv example.org.pem ROOT_CRT.crt
# Previous dockerfile
RUN cp ROOT_CRT.crt /usr/local/share/ca-certificates/ROOT_CRT.crt
RUN /usr/sbin/update-ca-certificates
RUN apt install python3.12 python3.12-venv wget curl -y
RUN useradd -ms /bin/bash vuser
USER vuser
WORKDIR /home/vuser
ENV REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
ENV UV_NATIVE_TLS=1
ENV RUST_LOG=trace
ENV RUST_BACKTRACE=full
RUN python3.12 -m venv venv
RUN venv/bin/python -m pip install uv==0.2.30
RUN RUST_LOG=trace venv/bin/uv venv
# This below will panic, comment it out if you'd like to succesfully build it
RUN RUST_LOG=trace venv/bin/uv pip install rich -vvv |
Since this uses |
Yes, I believe the issue is that there's still a symlink to You can arguably get around the issue with not setting Otherwise, generally another easy way to sort-off reproduce is generating a dummy cert, locking it down, and running a command that uses it like below:
But this example doesn't capture the nuance that's ocurring with |
|
Indeed, thank you for the write-up and the MRE! |
|
I confirm the problem is fixed if I chmod 644 the certificate file. Regarding the other issue: Tested with uv 0.2.29 and uv 0.2.30: Log attached Expected result: |
|
@charliermarsh thanks for tagging me on the issue. We changed rustls-native-certs in 0.7.1 to make it inspect more potential locations for roots to include, so it is finding more places and, in order to read the certificate from those places, obviously the current user needs to have read privileges on those certificate files. I'm still a little confused on the use of (Currently on vacation so a little slower to respond than usual.) |
|
Thanks @djc. If // Configure TLS.
let client_core = if self.native_tls || ssl_cert_file_exists {
client_core.tls_built_in_native_certs(true)
} else {
client_core.tls_built_in_webpki_certs(true)
};Which, IIUC, is based on the |
|
Right. IMO the environment variable name is a little unfortunate since it confuses the TLS implementation crate (native-tls is still used by many in the Rust world) with the source of trust roots (the crate name is rustls-native-certs and reqwest chose to name the feature Not sure what else I can contribute here, sounds like the uv team has things under control? In the future, could also consider using the rustls-platform-verifier crate which might be more robust on platforms like Windows, macOS (and derivatives) and Android, but that will do the same thing here. This is currently not natively supported within reqwest, but you can pass it a preconfigured TLS config to make it work. |
I'm using uv with tox to build multiple versions of the same packet on Ubuntu Linux 22.04 LTS.
The tox.ini works well with uv 0.2.28, but starts to fail with 0.2.29.
Changing back to uv 0.2.28 fixes the problem:
The command that causes the error:
any uv pip install that tries to download a new file.
The error happens when uv is called inside tox and also in the command line with the virtual environment active.
The error happens when UV decides to download a package. I have the same error when the environment is empty or when it already has some installed packages.
Environment
The package name makes no difference, having the same errors with numpy and pandas.
The text was updated successfully, but these errors were encountered: