Backend Ignores `boto3` Default Credential Lookup Mechanism

[nickbanqora]

I put one possible solution in here:

https://github.com/jmkeyes/keyrings.codeartifact/pull/7/files

[jmkeyes]

Thanks for opening this issue! I think you may have found a bug or at least counter-intuitive behaviour.

The documentation for boto3 indicates that it should look for credentials by searching for the first match in a list of locations (emphasis mine):

Boto3 will look in several locations when searching for credentials. The mechanism in which Boto3 looks for credentials is to search through a list of possible locations and stop as soon as it finds credentials. The order in which Boto3 searches for credentials is:

1. Passing credentials as parameters in the boto3.client() method
2. Passing credentials as parameters when creating a Session object
3. Environment variables
4. Assume role provider
5. Assume role with web identity provider
6. AWS IAM Identity Center credential provider
7. Shared credential file (~/.aws/credentials)
8. AWS config file (~/.aws/config)
9. Boto2 config file (/etc/boto.cfg and ~/.boto)
10. Container credential provider
11. Instance metadata service on an Amazon EC2 instance that has an IAM role configured.

When creating a Session object, the current code sets both aws_access_key_id and aws_secret_access_key if those same keys are set within a matching configuration section:

        # Create session with any supplied configuration.
        session = boto3.Session(
            region_name=region,
            profile_name=config.get("profile_name"),
            aws_access_key_id=config.get("aws_access_key_id"),
            aws_secret_access_key=config.get("aws_secret_access_key"),
        )

If those keys are not available in a matching configuration section, then value of both aws_access_key_id and aws_secret_access_key will evaluate to None which in turn should cause boto3 to search for credentials through the built-in credential lookup mechanism.

In short, setting those keys in keyringrc.cfg prevents boto3 from using environment variables to look up credentials, the ability to assume a role (ref: #6) with the assume role provider, and other mechanisms built in to the library.

This also suggests a workaround: if you remove the aws_access_key_id and aws_secret_access_key keys from matching sections in the keyringrc.cfg then the boto3 library will use it's own configuration lookup mechanism to find environment variables as expected.

An ideal solution for this bug would augment the boto3 configuration search mechanism and explicitly add our credential source somewhere in the list of locations it searches. For example, it's not immediately obvious that environment variables specified on the command line are will be ignored if there's a matching set of access/secret keys in keyringrc.cfg.

[nickbanqora]

FYI I think I've managed to solve my issue (original pr not required), as you rightly pointed out we shouldn't need to get the aws profile in the code - maybe this will be useful for someone using latest uv

export AWS_PROFILE=myprofilename

publish side pyproject.toml:

[tool.uv]
publish-url = "https://aws@myurl.amazonaws.com/pypi/myrepo/"
keyring-provider = "subprocess"

uv publish

consume side:

[[tool.uv.index]]
name = "codeartifact"
url = "https://aws@myurl.amazonaws.com/pypi/myrepo/"

[tool.uv]
keyring-provider = "subprocess"

uv add mypackage

[nickbanqora]

And the corresponding github action as this took me a bit of messing around and I couldn't find a good guide anywhwere :) assuming this package is in dev dependencies and the role has the right permissions - activating the venv is important

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        id: aws-credentials
        with:
          aws-region: "myregion"
          role-to-assume: "myrole"
      
      - name: Install uv
        uses: astral-sh/setup-uv@v5

      - name: Publish Package
        run: |
          uv sync --dev
          source .venv/bin/activate
          uv build
          uv publish

[TiansuYu]

@nickbanqora @jmkeyes I have raised a PR #24 intending to fix this, could you please so kind to have a look?