The cli should respect XDG spec for config and credential file storage

[jasonkarns]

The XDG spec defines where config files and credential files should be placed.

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Instead of writing to $HOME, the aws config directory should be $XDG_CONFIG_HOME/aws. (And $XDG_DATA_HOME/aws/ for creds)

[stealthycoin]

I'll mark this as a feature request. It will require some discussion.

[qrevel]

It should also respect the XDG cache folder when assuming role.

[ASayre]

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

This entry can specifically be found on UserVoice at: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168373-the-cli-should-respect-xdg-spec-for-config-and-cre

[jamesls]

Based on community feedback, we have decided to return feature requests to GitHub issues.

[pierreprinetti]

Hi there. Any news on this one?

[ainola]

Yeah, this isn't so much a 'feature request' as a bug report. the XDG spec has been defined and adopted for some number of years now.

[lhanson]

AWS team: is this a feature you'd consider merging if somebody contributed the code?

[arturtamborski]

Here's a workaround until someone sends a patch:

export AWS_CONFIG_FILE="$XDG_CONFIG_HOME/aws/config"
export AWS_CLI_HISTORY_FILE="$XDG_DATA_HOME/aws/history"
export AWS_CREDENTIALS_FILE="$XDG_DATA_HOME/aws/credentials"
export AWS_WEB_IDENTITY_TOKEN_FILE="$XDG_DATA_HOME/aws/token"
export AWS_SHARED_CREDENTIALS_FILE="$XDG_DATA_HOME/aws/shared-credentials"

For some reason terraform doesn't like the AWS_WEB_IDENTITY_TOKEN_FILE variable, causing it to throw this: WebIdentityErr: role ARN is not set - so you'd better not export it if not necessary.

[sherabi]

It's almost end of 2019, sad to see that the XDG settings are not being recognized on a more wide basis across applications.

[lhanson]

Not to mention the fact that it's very discouraging to anyone potentially motivated to offer a patch when there are PRs sitting dormant for years providing things as simple as documentation improvements.

[timkrueger]

Should the credentials really stored in $XDG_CONFIG_HOME/aws?

There are much users which makes usage of dotfiles repositories. Normally the $XDG_CONFIG_HOME is included in this repository.

Maybe the credentials should be stored in $XDG_DATA_HOME/aws?

[Pablo1107]

Should the credentials really stored in $XDG_CONFIG_HOME/aws?

There are much users which makes usage of dotfiles repositories. Normally the $XDG_CONFIG_HOME is included in this repository.

Maybe the credentials should be stored in $XDG_DATA_HOME/aws?

I agree, many users include the whole $XDG_CONFIG_HOME folder in their dotfiles repo, so this would cause problems. But your recommended directory is very appropriate.

Is there any updates on this feature request?

[WhyNotHugo]

Should the credentials really stored in $XDG_CONFIG_HOME/aws?

In all honesty, credentials should not be stored in a plain-text file in a well-known location really. You might want to consider something like aws-vault.

I'm not against opposed to using $XDG_DATA_HOME though, just mentioning alternative solutions for this specific scenario.

[kdaily]

I've seen a few more requests for this change. While I do not disagree with this convention, this would be a big breaking change to many users who rely on the current configuration settings. In order to make this work, this convention would need to be adhered to by all AWS SDKs and tools. Because of this, I'm going to move this issue to the AWS SDK issue tracking repository at https://github.com/aws/aws-sdk.

[jasonkarns]

This is still an issue. What's worse, there doesn't seem to be an environment variable for configuring ~/.aws/sso/cache/. So there isn't even a workaround for users logging in with SSO.

[eggbean]

I have a couple of dozen configurations in my dotfiles and aws-cli and terraform.d are the only ones that don't comply with the XDG specification.

[devnoot]

Still an issue in 2022

[eggbean]

@devnoot You can actually do this by adding these variables to your .bashrc.

export AWS_SHARED_CREDENTIALS_FILE="$XDG_CONFIG_HOME"/aws/credentials
export AWS_CONFIG_FILE="$XDG_CONFIG_HOME"/aws/config

ref: https://wiki.archlinux.org/title/XDG_Base_Directory

[devnoot]

That gets it closer but the cli still creates cache files in $HOME/.aws instead of $XDG_CACHE_HOME

[lhanson]

It's nice that a workaround of setting AWS-specific environment variables almost achieves the desired effect, but a major part of following the specification is that I don't have to explicitly tell each application in its own particular dialect where I want my stuff.

[billwanjohi]

Anyone know how to get the AWS_SHARED_CREDENTIALS_FILE and AWS_CONFIG_FILE variables to be respected in zsh? I plopped them in ~/.zshenv and they're available in my environment, but (unlike in bash) aws-cli seems to ignore them.

[tjnycum]

It's nice that a workaround of setting AWS-specific environment variables almost achieves the desired effect, but a major part of following the specification is that I don't have to explicitly tell each application in its own particular dialect where I want my stuff.

Indeed. It merely moves the clutter from the home directory to the shell environment.

[kittydoor]

Will a PR for this be considered, with the precedence of, use first found:

• $XDG_CONFIG_HOME/aws/
• ~/.config/aws/
• ~/.aws
• if none found, create 1st option

And similar approaches for the other sections such as credentials and other files mentioned above.

A clear answer on this is important so that someone can actually put in the effort and this is eventually merged and this issue closed.

[eggbean]

I usually see those sort of locations the other way around in precedence. I think that makes sense as it would be less likely to confuse people who don't know about the XDG spec and are following older tutorials.

[YourFin]

@eggbean what tools are you referring to? Git, pip, and most other tools I know of use the order mentioned by kittydoor@.

[gui-don]

Hi 👋

I've seen a few more requests for this change. While I do not disagree with this convention, this would be a big breaking change to many users who rely on the current configuration settings. In order to make this work, this convention would need to be adhered to by all AWS SDKs and tools. Because of this, I'm going to move this issue to the AWS SDK issue tracking repository at https://github.com/aws/aws-sdk.

I’ve seen this argument many times for other apps and I fail to understand the reasoning. It’s always possible to default all undefined XDG_XXX variables to ~/ within your code. If you’re afraid people might have XDG_XXX env vars set and still use the default ~/.aws I suggest then to check whether the ~/.aws exists and continue using it while throwing a warning for a couple of years, while users without any ~/.aws directory can safely use XDG specifications.

[jasonkarns]

Still broken in aws-cli/2.13.29 (year 2023) even with the following aws-specific (and thus, contrary to the point of XDG) env vars:

$ echo $AWS_
$AWS_CLI_HISTORY_FILE         $AWS_CONFIG_FILE              $AWS_CREDENTIALS_FILE         $AWS_SHARED_CREDENTIALS_FILE  

$ tree .aws/
.aws/
├── cli
│   └── cache
│       ├── 1f89c34a90d78e0b17c2f9ed639ca62a1c04b4c7.json
│       └── 30f0208390c5c35c3391a99b4fe9feec19f1a053.json
├── config
└── sso
    └── cache
        ├── 3c66853f1eae43a523457fa74f2705d634cd1bcc.json
        ├── 7285882a013839b47c8f2c91fa6119b41638da91.json
        └── 8548b6f2619b21c5242e5238dad90f6016462a14.json

5 directories, 6 files

[tynan-delivrable]

This is still an issue. What's worse, there doesn't seem to be an environment variable for configuring ~/.aws/sso/cache/. So there isn't even a workaround for users logging in with SSO.

this is the most laughably infuriating aspect to this issue - despite the fact I've already got 4 (5!?) lines in my .bashrc dedicated to pulling aws cli into line, it's all for naught because apparently this is a "breaking change to many users who rely on the current configuration settings". My options now are splitting my aws folders across multiple directories or just sucking it up? Is that really where we've landed?

@gui-don is completely on the money and I couldn't agree more, there's multiple ways this could be handled gracefully for existing users, with hundreds of examples of implementations like this in the wild.