Would make amber easier to consume in the GitHub ecosystem (without requiring any changes to amber)

A developer using Github actions would not need to worry about how to install amber e.g. https://github.com/chrisjsimpson/amber-secrets-ci-example/blob/9854d92efd11bccb1919f8f74e9a38e5cbec6cd0/.github/workflows/production.yml#L19-L22 would be abstracted away.

Have some experience with this.

Since the tool is used in CI steps, the user would need to install amber into their building environment / container. A simple script that always pull the latest release (better if major version can be set and fixed) would be helpful.

Often while using amber locally, I want to copy certain secrets to the clipboard. I'm imagining a interface like this for this feature:

USAGE:
    amber clipboard <key> --amber-yaml <amber-yaml>

Additionally, I can volunteer to implement this if there is no objections.

Could the encrypt subcommand take the secret value from stdin? This would help prevent raw secrets from being saved in shell history, for example.

BTW, this is a very cool project! It hits a lot of sweet spots for in-repo secret storage.

I created an AUR (Arch User Repository) package for amber: https://aur.archlinux.org/packages/amber-secrets/

I called it amber-secrets as there is already a package called amber (the Crystal web-framework). It also depends on the system libsodium instead of statically linking its own copy.

Anyway, just passing on the info to let you know it's out there. Not sure if it's worth mentioning in the install section of the README or not.

"print all of the secrets" actually prints shell commands.

For example user story: As a user I can specify an environment name of my choosing whilst storing a secret, perhaps with a default. When accesing a secret, the default environment is used.

e.g. Interface

(base) (environment)$ ./amber --verbose encrypt 
error: The following required arguments were not provided:
    <ENVIRONMENT>
    <KEY>

USAGE:
    amber encrypt [OPTIONS] <ENVIRONMENT> <KEY> [VALUE]

For more information try --help
(base) (environment)$ ./amber --verbose encrypt staging API_KEY secret
[2022-01-01T22:16:45Z DEBUG amber] Cmd { opt: Opt { verbose: true, amber_yaml: None, unmasked: false }, sub: Encrypt { environment: "staging", key: "API_KEY", value: Some("secret") } }
[2022-01-01T22:16:45Z DEBUG amber::cli] Checking if file "amber.yaml" exists
[2022-01-01T22:16:45Z INFO  amber::config] New value matches old value, doing nothing
(base) (environment)$ 

Possible structure: (Note the additon of "environment")

---
file_format_version: 2
public_key: 7801a1206e8e339c396a990bdd758dcccce9d1e8846b3a08b8329d3925adf801
secrets:
  - name: API_KEY
    environment: staging
    sha256: 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
    cipher: 104b00746ab5a029ee6c693e33d6cee116163b695d5ed685e1e8428984f5105012e3741ec89d4e944c4f02209762f11f69f6eed17be7
  - name: API_KEY
    environment: production
    sha256: 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
    cipher: 104b00746ab5a029ee6c693e33d6cee116163b695d5ed685e1e8428984f5105012e3741ec89d4e944c4f02209762f11f69f6eed17be7

Motivations

• Secrets may change between environments (e.g. testing, staging etc )
• Whilst it is possible to achieve managing different environment secrets with amber (potentially by managing amber.yaml in a different repo per environment, this undermines the goal to track the changes in values over time.

Considerations

• To store envrionment name per secret not elsewhere
• Provide a default environment name, or none
• This would/could be a breaking change to the file format so may require a bump of FILE_FORMAT_VERSION

I've coded an intial attempt at this to demonstrate the idea and will push, though a complete implementation is missing since I'm new to Rust. I specifically got stuck at:

I hope the code tempts someone or someone can point me in a better direction.

Provide capability to access the private key from a cloud provider, such as AWS or Azure.

1. Having an IAM role only for CI/CD.
2. At starting of the job, create some AWS secrets from Amber. Restrict them for CI/CD role.
3. Running Terraform (using data to reference to the secrets).
4. Succeeded or not, remove all secrets from AWS.

Hence we do not have AWS secrets for long term, and we do not have secret texts in Terraform artifacts.

Right now amber by default checks amber.yaml in the directory where
the command is being executed.

I think it might be convenient if it searches it's parent directory
too. I found that this could be convenient in one of the recent
projects I integrated amber with.

So I think for finding the amber.yaml, we can slightly change it to
accommodate something like this:

• check if the passed location (either default or explicitly passed value) of file exists and use that if found.
• If not, traverse your parent directory to see if it exists

I would be happy to implement it in the coming days, if you aren't
opposed to it.