At the moment we use

AKIAIOSFODNN7EXAMPLE

and

wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

as example access&secret keys respectively, throughout the documentation, Everything Bagel, etc. If we replaced these with

AKIA-EXAMPLE-KEY

and

EXAMPLE-SECRET

it would make documentation more accessible by being more readable (the brain doesn't have to grok a bunch of random chars to realise it's just a dummy placeholder). More accessible == easier for users to get to grips with lakeFS and the samples and documentation. Before I do a PR with a global search & replace for formal review, I wanted to check if there were any immediate objections or gotchas to consider ? thanks 🙂

No objections, just wanted to add that these were chosen since they are the values AWS uses in their examples (try googling them). So the idea was to emphasize that you can use lakeFS creds just like S3 creds.

that's useful context, thanks @Itai Admi

just need to make sure that whatever we do doesnt get flagged by our automated scanning (or aws’ or github’s)

To add to what @Itai Admi said... We allow many more characters in our AWS-style access keys. In fact you can use anything or almost anything there, even though we will not generate everything possible. When testing I sometimes use "foo" and "bar", which definitely won't work on AWS. However some tools may enforce "correct" access keys. Rather than figure out which to do, we go with the crowd

yeah, i suggested

AKIA-EXAMPLE-KEY

after something (lakeFS, perhaps) flagged that

EXAMPLE-KEY

alone was not a valid access key

Unfortunately this AWS blog casually gives rules for access key IDs that do not match your proposal, see the section "Finding hard-coded credentials in your code". Now it's not saying one should use apply these times to validate access keys, but the threat of some tool deciding to enforce made-up rules about what makes an access key "moral" or whatever is at least a bit scary. I'd prefer to keep using these AWS monstrosities.

Also, not sure it's necessarily always more readable: it makes sense for the examples to look like the actual credentials we generate. Moreover, these credentials are used for our S3-compatible API. That is, they can be given as input to AWS clients so maybe it makes sense for them to also look like AWS credentials.