Secure authentication method needed

[stoney95]

I would like to use uv to install dependencies from a private artifactory repository. Authentication for the private repository works with username and password. I would also like to store the index-url in the pyproject.toml. This simplifies the usage of uv for every team-member. The current minimal config looks like the following:

version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.11"
dependencies = []

[tool.uv]
index-url = "https://artifactory.company.com/pypi/simple"
native-tls = true
keyring-provider = "subprocess"

The documentation for authentication lists these options:

• The URL, e.g., https://<user>:<password>@<hostname>/...
• A .netrc configuration file
• A keyring provider (requires opt-in)

The first option is not possible, as the credentials would be shared via git. Using .netrc is only partially possible as it poses a security risk by storing credentials in plain text. I tried this option nonetheless and it worked. But I would like to avoid it due to the plain-text password.
The thrid option does not work. I will describe in detail, what I tried and where it failed.

1. pip install keyring
2. keyring set artifactory.company.com my_username and entering the credentials as prompted
3. running uv add <any-package> with the configuration from above failed with

hint: An index URL (https://artifactory.company.com/pypi/simple) could not be queried due to a lack
      of valid authentication credentials (401 Unauthorized).

I changed the configuration value for index-url to https://my_username@artifactory.company.com/pypi/simple. By this uv reads the credentials from keyring. As this stores the username in the pyproject.toml the approach does not work. Every team-member uses their own credentials to authenticate with the private artifactory.

• uv version: uv 0.4.25 (97eb6ab4a 2024-10-21)
• uv platform: Windows 11

If uv should work with the plain index-url (no username) and keyring, I would like to report this as a bug. In case it doesn't, I would like to request a secure methode for storing credentials while preserving a transferable uv configuration.

[charliermarsh]

Keyring alway require a username. If you name your index, you can provide credentials for your index via environment variables and store them however you want:

[[tool.uv.index]]
name = "company"
url = "https://artifactory.company.com/pypi/simple"
default = true

Then you can specify a username with UV_INDEX_COMPANY_USERNAME and a password with UV_INDEX_COMPANY_PASSWORD. See: https://docs.astral.sh/uv/configuration/indexes/#providing-credentials.

[stoney95]

@charliermarsh, thanks for pointing out the solution using environment variables.

Do you currently plan to provide a solution similar to poetry config http-basic? This uses keyring under the hood, but stores which username to use for each index on the user-level.

Using your example, I would propose the following workflow:

1. Define the index (making this possible via cli, e.g. uv index add ... would be nice to have)

[[tool.uv.index]]
name = "company"
url = "https://artifactory.company.com/pypi/simple"
default = true

2. Define credentials with uv index config company "my_username". This will prompt for the password. The username is stored in $XDG_CONFIG/uv/uv.toml, e.g.

[index.company]
username = "my_username"

The password is stored with keyring.

Setting this config up once, makes it possible to run uv add <package>. Which is then pointing to the right index and using credentials automatically

[ljtruong]

Thought this might help. I've made a hacky way to work as a "config" to set the environment variables to authenticate for private pypi repo. My company uses aws so the tokens are short lived, so it's safe to do.

For more info, you would replace PASSWORD with the CodeArtifact auth command to retrieve the password token automatically and set the new credentials when it expires.

#set_credentials.sh
if [ ! -f ~/.uv ]; then
  touch ~/.uv
fi

update_credentials() {
    local PASSWORD="updated_password"
    # Set UV_INDEX_INTERNAL_COMPANY_PASSWORD in the ~/.uv file
    if grep -q "^export UV_INDEX_INTERNAL_COMPANY_PASSWORD=" ~/.uv; then
      # Use sed to replace the value with the local $PASSWORD variable
      sed -i '' "s/^export UV_INDEX_INTERNAL_COMPANY_PASSWORD=.*/export UV_INDEX_INTERNAL_COMPANY_PASSWORD=${PASSWORD}/" ~/.uv
    else
      # Append the line with $PASSWORD if it doesn't already exist
      echo "export UV_INDEX_INTERNAL_COMPANY_USERNAME=aws" >> ~/.uv
      echo "export UV_INDEX_INTERNAL_COMPANY_PASSWORD=${PASSWORD}" >> ~/.uv
    fi
}
update_credentials
source ~/.uv

Run this using

source set_credentials.sh

[zanieb]

Do you currently plan to provide a solution similar to poetry config http-basic? This uses keyring under the hood, but stores which username to use for each index on the user-level.

Yeah I'm interested in this, but we'll need to switch from the Python keyring library to something more robust and Rust native which will take time.

[ThomasHezard]

Hello,

I run into the same kind of question: What is the best way of authenticate on private indexes with uv?
If I understand well, the recommended solution today is to use the UV_INDEX_XXX env variables.
However, this is not a very practical solution as .env file is not supported by uv sync, which means we have to set numerous specific variables for uv.

I ended up using the same "hacky" (or at least non-standard) solution as described here, with a set_env.sh script in my repo setting the UV_INDEX_XXX env variables to the appropriate values on both devs and CI machines.

In my case, I see two solutions which would be less "hacky" and much more practical:

• accepting .env file in the uv sync command,
• or interpreting env variables in pyproject.toml.

Do you have any of these two planned or do you have something else to recommend?

Thank you 🙏

[zanieb]

accepting .env file in the uv sync command,

Why not activate your .env file with another tool like direnv? Why is it uv's job to read configuration from that file?

interpreting env variables in pyproject.toml

Wouldn't you still need to set the variables? Isn't that part of the complaint?

I believe you can also configure your credentials in the uv.toml, if you prefer.

[ThomasHezard]

interpreting env variables in pyproject.toml

Wouldn't you still need to set the variables? Isn't that part of the complaint?

I believe you can also configure your credentials in the uv.toml, if you prefer.

The thing that makes it a bit more complicated with uv for me (and my team) is that uv has a strict convention about the env variable names for authentification. With other tools allowing using env variables directly in config files, we can easily have a universal configuration across tools that work on both devs and CI machines with simple setup, which is quiet convenient.

accepting .env file in the uv sync command,

Why not activate your .env file with another tool like direnv? Why is it uv's job to read configuration from that file?

I must admit I am not familiar with direnv as I never needed it. It may be a very good solution indeed, I'll have a deeper look at it.

Thank you for the answer 🙏

[zanieb]

With other tools allowing using env variables directly in config files, we can easily have a universal configuration across tools that work on both devs and CI machines with simple setup, which is quiet convenient.

Can you share some example tools? I'd like to look at their approaches.

[ThomasHezard]

Can you share some example tools? I'd like to look at their approaches.

First, I need to say that I don't come from the Python world, I only started using Python at production scale quite recently. My programming background is mostly C++ and iOS/Android development, some UNIX system administration, Docker and k8s deployment, and Matlab quite some time ago.

I used quite a lot of different tools for configuration, environment management, compilation, testing, packaging or deployment, and most of them support reading environment variables within their "configuration files" (or equivalent).
A few examples:

• bundler in gemfiles,
• fastlane and other Ruby-based tools,
• cmake and gradle,
• I'm pretty sure Conan and Bazel support env variables one way or another but I'm not very familiar with these,
• Docker in Dockerfiles and at runtime,
• make in makefiles,
• in Python, I have used setuptools with setup.py, which is native python giving you the ability to use os.environ,
• gitlab CI yaml
• helm charts for k8s

Many of these tools support env variables the same way you use it in shell: $MY_ENV_VAR.
The ENV['MY_ENV_VAR'] syntax is also present in several of these tools and I'm pretty sure I've seen it in other contexts. cmake has it a bit different with $ENV{MY_ENV_VAR}.

Hope this helps :)

[farndt]

Do you currently plan to provide a solution similar to poetry config http-basic? This uses keyring under the hood, but stores which username to use for each index on the user-level.

Yeah I'm interested in this, but we'll need to switch from the Python keyring library to something more robust and Rust native which will take time.

Would keyring-rs be an option: https://docs.rs/keyring/latest/keyring/ to speed up transition?

[zanieb]

Yeah we'd probably use that, though I haven't audited it.

Thanks @ThomasHezard !

[farndt]

I would suggest the following implementation for Keyring:

1. define index in pyproject.toml

[[tool.uv.index]]
name = “service-name”
url = “https://artifactory.company.com/*/simple”

2. keyring set artifactory.company.com my_username -> enter password

3. uv reads username and password using Keyring get_credentials service-name

This would allow teams to use keyring without making changes to pyproject.toml. Due to lack of encryption and simple logging it should be avoided to use environment variables as storage for credentials.

This approach could be quickly implemented temporarily with keyring as a Python package. When switching to Keyring-RS at a later date, the process would not need to change.

[stoney95]

@zanieb, what are your concerns about keyring-rs? I would be interested to contribute the keyring credentials feature and would like to understand the constraints

@farndt, can you share some documentation about get_credentials without a username? afaik, you need a service and a username to reference keyring entries.

[zanieb]

No concerns; we just audit new dependencies for trustworthiness, correctness, etc.

Feel free to contribute support if you're interested. I think the first step is to have --keyring-provider <something> use the crate as a backend?