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.

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.

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.

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.

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.

The script aims to ease the process of fetching amber into any Linux environment. This version only fetches the latest one.

The script has been tested in Alpinelinux.

From last year, sodiumoxide has been unmaintained and there is a RUSTSEC advisory filed that has deprecated it's usage: https://rustsec.org/advisories/RUSTSEC-2021-0137.html

Also the original author of the crate has archived the repository.

This PR switches to use the crate crypto_box which is a pure Rust compatibility layer for Nacl libraries. I also had to use some other crates for computing SHA, hex decoding etc.

Summary of the changes:

• cargo update all crates. The most important one being clap.
• Upgrade toolchain to 1.64 and do relevant clippy changes.
• Some changes to github actions and toml file to speed up CI

amber is display secret key to console when execute amber init. But, I think there are times when want not to display secret to console.

So, add --only-secret-key option and use the following:

amber init --only-secret-key | pbcopy

Summary of the updates:

• Clap v3 has been released and this PR updates to use it. I did a cargo upgrade to update all the other dependencies, but if you prefer me just updraing clap, I can go ahead and do that.
• Use assert_cmd for testing cli. This gives a cargo_bin method which is more convenient for integration tests rather than doing cargo run.

This PR makes amber searches the parent directory for the amber.yaml file if amber.yaml isn't present in the current working directory.

This check is only done when no explicit amber-yaml is specificed via --amber-yaml option or via the environment variable (unless the specified value matches the default amber.yaml value)

Fixes #21

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.

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: https://github.com/fpco/amber/blob/65e6c6ec8ee0669df71b9b56e6e3ab924e0d3fc2/src/config.rs#L109 after altering SecretRaw structure to include environment.

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

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.