astral-sh
regression: authentication stopped working in uv 0.1.36
Hello,
Authentication stopped working in uv 0.1.36, it's no longer able to install packages that requires authentication.
For context, we use a netrc to set credentials to access artifactory. Artifactory, nexus, and probably all the hosted equivalent in azure/aws/google do permissions depending on the user.
- When a query to the index doesn't have credentials, it can only view and list packages and versions that are "public".
- When a query to the index has credentials, it will also be able to list and view packages and versions that are accessible to these credentials.
The index can have very fine grained permissions. The doom of my existence is packages that changed in permissions, getting reassigned to some organizations or becoming publicly visible to the whole company or not.
By the way if you have logic to do a first query to "test" the index and only do a second query with credentials on 401/403, this doesn't actually work because the first query will succeed but return (incomplete) content with only packages that are accessible without credentials. All queries must be authenticated.
DEBUG LOGS:
[root@f93fa297ed91 default-venv]# uv --version
uv 0.1.35
[root@f93fa297ed91 default-venv]# NETRC=~/.pypinetrc uv pip install --dry-run --native-tls --index-url https://example.com/artifactory/api/pypi/internalrepo-311/simple/ mypackage --no-deps --no-cache
Resolved 1 package in 632ms
Would download 1 package
Would install 1 package
+ mypackage==202405300929
[root@f93fa297ed91 default-venv]# uv --version
uv 0.1.36
[root@f93fa297ed91 default-venv]#
[root@f93fa297ed91 default-venv]#
[root@f93fa297ed91 default-venv]# NETRC=~/.pypinetrc uv pip install --dry-run --native-tls --index-url https://example.com/artifactory/api/pypi/internalrepo-311/simple/ mypackage --no-deps --no-cache
Resolved 1 package in 451ms
Would download 1 package
Would install 1 package
+ mypackage==202003180941
this one is a package that was previously publicly accessible in the repo and became restricted at some point.
the version 2020 is the last that was published and is accessible without authentication. uv can only see and install that one, which implies it did not pass credentials when making HTTP queries to the index.
I suspected a caching issue but setting --no-cache doesn't help. I think authentication is not passed at all.
Thoughts?
Can you include the logs with the verbose flag on the latest version?
Sorry, can you run again with RUST_LOG=trace and --verbose? I forgot the auth logging is at the tracing level.
I think we didn't used to "try the request before adding auth", but we had to change it to do that for some reason? And that it matches pip? I can't remember the details. Zanie would know when they're back from vacation.
Submitting the debug logs with trace. Sorry for delay.
Note I am just sending the top of the logs, should be enough for this bug. The full log is very long and not sure the content is safe to share online.
on buggy version 0.1.42
on previous version that worked 0.1.33
You can see uv is making unauthenticated requests in the more recent versions. It shouldn't make unauthenticated requests when authentication is configured.
For more info, there are a few ways to pass authentication I can think of:
- can pass credentials with a netrc file, it only supports granularity at the domain level. I think credentials should always be passed to all requests to that domain.
example netrc file
machine pypi.example.com
login login
password password
- can pass credentials directly in the url like
--index-url https://login:[email protected]. That's granularity at the index level. It's possible to have different credentials for different indexes on the same domain. I think credentials should always be passed to all requests to that index.
Sorry you're having problems with this! Apparently it's very very hard to satisfy all of the desired authentication schemes. I'll look into this we'll need to be very careful not to break the things we fixed in #3130.
Hi! totally understand this "Apparently it's very very hard to satisfy all of the desired authentication schemes". So just wanted to ask if you were able to find a way for this, but totally understand it might not be simple. Is there any extra information we could provide to help?
I think this is mostly a matter of doing something like #4583 so we can use credentials more aggressively.