envio-cli / envio

Envio is a modern and secure command-line tool that simplifies the management of environment variables

envio

A Modern And Secure CLI Tool For Managing Environment Variables

To see the GPG encryption demo go here

About

envio is an open source CLI tool that helps make managing environment variables a breeze. With envio, users can create encrypted profiles that contain a collection of environment variables associated with a specific project or use case. envio ensures security and simplifies the development process by allowing users to easily switch between profiles as needed and load them in their current terminal session for immediate use.

Some key features of envio include:

• Encrypted profiles through passphrase or GPG encryption
• Load profiles into your terminal sessions
• Persistent environment variables that are available in future sessions
• Run programs with your profiles
• Importing profiles stored on the internet into your local installation
• Exporting profiles to a file

Sound interesting? Check out the official website for more information such as how to install and use the tool on your machine.

envio currently supports Linux, MacOS and Windows

Contributors

Vojtch 📖

Erjan Kalybek 📖

Alexis Hildebrandt 💻

Contributing

Contributions to envio are always welcome! Please see the Contributing Guidelines for more information.

License

This project is licensed under the MIT and the Apache License

envio's Issues

Invalid setenv.sh generated

Hi there!

I started using envio for around 10 profiles and got this bug.

Describe the bug

Sometimes, calling envio load will alter setenv.sh in a way that the end of the file is invalid.
So when I reload my shell, an error pops out.

Example:

# file start skipped

    if [ $? -ne 0 ]; then
        echo "Failed to load environment variables from temp file"
        exit 1
    fi

    rm "$TMP_FILE"
fi
"
fi

To Reproduce
Steps to reproduce the behavior, without reloading my shell:

1. envio unload
2. envio load xxxxxxxxxxxxx
3. envio load yyyyyyyyyyyyyyyyyy
4. envio load xxxxxxxxxxxxx
5. setenv.sh has now invalid content at the end (" and fi)

Expected behavior
envio does generate a valid script on each load

Device (please complete the following information):

• OS: macOS 14.3.1 (23D60) on Apple M1 MacBook Air 2020
• Shell: GNU bash, version 3.2.57(1)-release (arm64-apple-darwin23)
• CLI Version: 0.5.1

Improve profile list display using comfy_table module

Currently, when the user lists their profiles using the command:
envio list profiles

The display is bland and unattractive. To improve the user experience, we will use the comfy_table module, which is already used for listing environment variables, to display the profiles in a more visually appealing way.

"envio version" should not fail if shell is not known

Describe the bug

I am creating a Clyde package for envio, but the package fails to build. This is because the package defines the command envio version as a test command for envio, but envio version fails with the following error message:

Creating config directory
Creating shellscript
Error: Could not get shell

After reading the code, I suspect this is because $SHELL is not defined on GitHub runners. In any case, a command to print the version should not need $SHELL to be set. It would also be a good practice if it did not write files to the user home directory.

To Reproduce
Steps to reproduce the behavior:

1. Start from a user who has never used envio (or rm -rf ~/.envio)
2. Unset $SHELL
3. Run envio version

Expected behavior

envio version should print the program version, ideally without creating any files.

Device (please complete the following information):

• OS: Ubuntu 22.04
• Shell: /bin/sh
• CLI Version: 0.5.1

Updated README

The commit 5ed5602 added a new banner to the project README that promotes a non-technical cause unrelated to the project.

The wording of the banner states "We stand […]" and among other folks I am listed by name in the Contributors section in the README, which is likely to be understood that the We in the banner includes all Contributors.

Yet, I was not asked whether I agree to be associated with said cause. Understanding the world is complex and controversial I'd much prefer for projects I contribute to stay clear from non-technical topics.

Do think it would be possible for you to show your support for the cause outside of this project?

If not, how can the README or banner be updated to not misrepresent folks, like me, who wish to keep politics and other societal topics out of their open source work due to the often divisive and heated nature?

Add GPG support

Currently, envio allows users to encrypt and decrypt profiles using custom encryption keys. However, some users may prefer to use GPG encryption instead.

I propose that we add support for GPG encryption and decryption alongside custom encryption keys. This will allow users to choose the encryption method that best suits their needs.

This feature will improve the flexibility and usability of envio and make it more accessible to users who prefer GPG encryption.

Remaining clear-text secrets in /tmp

Hi!

Describe the bug
setenv.sh generates a tmp file (using mktemp), clear text secrets are written here, the file is then sourced and deleted.

For some unknown reason, I have cumulated some non-deleted tmp files containing clear-text secrets from my profiles.

To Reproduce

I am not sure how to reproduce this issue. This could occur as my shell is stopped or crash between $TMP_FILE writing and rm "$TMP_FILE".

Expected behavior

Ideally, I would prefer that no file contains clear text secrets.

Device (please complete the following information):

• OS: macOS 14.3.1 (23D60) on Apple M1 MacBook Air 2020
• Shell: GNU bash, version 3.2.57(1)-release (arm64-apple-darwin23)
• CLI Version: 0.5.1

Feature: Launch command as positional argument

Feature
Setting the command as an option seems a bit weird when the command itself is the main part of the launch subcommand. Having to set it as a string can also be a bit of a pain.

I think handling the command as positional argument with last would be way more friendly. It should also be less error prone since clap takes care of the whitespaces and won't allow an empty command.

envio launch my_profile --command "cmd arg1 arg2 ..."
envio launch my_profile -- cmd arg1 arg2 ...

Compatibility
Using group would allow supporting both option as well as making them mutually exclusive, avoiding the need for a breaking change or a different subcommand. This would require to bump clap version at least to 4.1.14 but looking at the changelog it shouldn't be an issue since clap didn't change its MSRV until 4.4.0

...
    #[command(
        name = "launch",
        about = "Run a command with the environment variables from a profile",
        override_usage = "envio launch <PROFILE_NAME> <--command COMMAND | -- COMMAND>"
    )]
    Launch {
        #[arg(required = true)]
        profile_name: String,
        #[command(flatten)]
        command: LaunchCommandArg,
    },
...

#[derive(clap::Args, Debug)]
#[group(required = true, multiple = false)]
pub struct LaunchCommandArg {
    #[arg(long = "command", short = 'c')]
    argument: Option<String>,
    #[arg(last = true, required = true)]
    positional: Vec<String>,
}

Missing build dependencies throws errors

Describe the bug
Attempting to follow your install instructions produced errors stating I was missing binaries. I tried building from source and hit the same errors.

To Reproduce
Steps to reproduce the behavior:

1. Run command cargo install envio
2. See error

Expected behavior
Should install the app on the target machine.

Screenshots

Device (please complete the following information):

• OS: macOS Ventura
• Shell: zsh
• CLI Version: ??? envio 0.5.0

Additional context
I had to run these installers to get it to install

brew install libgpg-error
brew install gpgme

Command `import` doesn't work on Windows

The lib looks interesting for me. I tried to use it in my project, but got an error while importing my .env file to envoi profile. I cleaned up the file and kept only one variable just for an example.

I have a test .env file:

FEATURE_CUSTOM_AUTH_POPUP=true

I run envoi import .env my-profile

I get an error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', src/lib.rs:438:10
stack backtrace:
   0:           0x8af440 - std::backtrace_rs::backtrace::dbghelp::trace::h0dc1cf386a5df1cd
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\..\..\backtrace\src\backtrace/dbghelp.rs:98:5
   1:           0x8af440 - std::backtrace_rs::backtrace::trace_unsynchronized::h36721138064e13f0
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\..\..\backtrace\src\backtrace/mod.rs:66:5
   2:           0x8af440 - std::sys_common::backtrace::_print_fmt::ha9b27eb44c93d960
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:65:5
   3:           0x8af440 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h79886c501d528d51
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:44:22
   4:           0x90f04b - core::fmt::write::h29f886d793a3c470
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src\fmt/mod.rs:1213:17
   5:           0x8a1ff5 - std::io::Write::write_fmt::h4af9d02caf84da95
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\io/mod.rs:1682:15
   6:           0x8af194 - std::sys_common::backtrace::_print::h7bc8b91c42c6b465
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:47:5
   7:           0x8af194 - std::sys_common::backtrace::print::h5c02d637f1374aec
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:34:9
   8:           0x8b24df - std::panicking::default_hook::{{closure}}::hb4ad508e3ca0b358
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:267:22
   9:           0x8b21b3 - std::panicking::default_hook::hdb151db9713cfc98
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:286:9
  10:           0x8b2e29 - std::panicking::rust_panic_with_hook::h4550c1124a1c8a4f
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:688:13
  11:           0x8b2b96 - std::panicking::begin_panic_handler::{{closure}}::haadeea136a4af3b4
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:579:13
  12:           0x8aff6f - std::sys_common::backtrace::__rust_end_short_backtrace::hc224062df081731d
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:137:18
  13:           0x8b28a0 - rust_begin_unwind
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:575:5
  14:           0x90b835 - core::panicking::panic_fmt::h1ae32e95b4b1a788
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src/panicking.rs:64:14
  15:           0x90be16 - core::result::unwrap_failed::h8bd87678b87bb845
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src/result.rs:1790:5
  16:           0x438a6c - envio::import_profile::he337f85fe6110813
  17:           0x41bc1e - envio::commands::<impl envio::cli::Command>::run::hd47f498cbd5a07b8
  18:           0x42064f - envio::main::h203bc3a3b9c07d92
  19:           0x427806 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf7689d81c8e323c8
  20:           0x409dec - std::rt::lang_start::{{closure}}::h37a55eb61948c28a
  21:           0x893bf5 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h10e6b3810a97f594
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src\ops/function.rs:287:13
  22:           0x893bf5 - std::panicking::try::do_call::hc0c08aef0d307148
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:483:40
  23:           0x893bf5 - std::panicking::try::hf8b174b6af1ac35c
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:447:19
  24:           0x893bf5 - std::panic::catch_unwind::h85d6d1a0b4671865
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panic.rs:140:14
  25:           0x893bf5 - std::rt::lang_start_internal::{{closure}}::h7ca5722ac975c7be
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/rt.rs:148:48
  26:           0x893bf5 - std::panicking::try::do_call::h741061858f588bf2
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:483:40
  27:           0x893bf5 - std::panicking::try::h6abad9e74e6bdc5f
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:447:19
  28:           0x893bf5 - std::panic::catch_unwind::hf171c5a39891248d
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panic.rs:140:14
  29:           0x893bf5 - std::rt::lang_start_internal::h1fbc7ed3cff5c2a6
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/rt.rs:148:20
  30:           0x420b9d - main
  31:           0x4013c7 - __tmainCRTStartup
  32:           0x4014fb - mainCRTStartup
  33:     0x7ffc994855a0 - <unknown>
  34:     0x7ffc9abc485b - <unknown>
 SurfyII C:\project\speed-dating  fix-lobby-timer  npx cross-env RUST_BACKTRACE=full envio import .\.env speed-dating

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', src/lib.rs:438:10
stack backtrace:
   0:           0x8af440 - std::backtrace_rs::backtrace::dbghelp::trace::h0dc1cf386a5df1cd
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\..\..\backtrace\src\backtrace/dbghelp.rs:98:5
   1:           0x8af440 - std::backtrace_rs::backtrace::trace_unsynchronized::h36721138064e13f0
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\..\..\backtrace\src\backtrace/mod.rs:66:5
   2:           0x8af440 - std::sys_common::backtrace::_print_fmt::ha9b27eb44c93d960
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:65:5
   3:           0x8af440 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h79886c501d528d51
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:44:22
   4:           0x90f04b - core::fmt::write::h29f886d793a3c470
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src\fmt/mod.rs:1213:17
   5:           0x8a1ff5 - std::io::Write::write_fmt::h4af9d02caf84da95
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\io/mod.rs:1682:15
   6:           0x8af194 - std::sys_common::backtrace::_print::h7bc8b91c42c6b465
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:47:5
   7:           0x8af194 - std::sys_common::backtrace::print::h5c02d637f1374aec
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:34:9
   8:           0x8b24df - std::panicking::default_hook::{{closure}}::hb4ad508e3ca0b358
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:267:22
   9:           0x8b21b3 - std::panicking::default_hook::hdb151db9713cfc98
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:286:9
  10:           0x8b2e29 - std::panicking::rust_panic_with_hook::h4550c1124a1c8a4f
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:688:13
  11:           0x8b2b96 - std::panicking::begin_panic_handler::{{closure}}::haadeea136a4af3b4
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:579:13
  12:           0x8aff6f - std::sys_common::backtrace::__rust_end_short_backtrace::hc224062df081731d
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src\sys_common/backtrace.rs:137:18
  13:           0x8b28a0 - rust_begin_unwind
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:575:5
  14:           0x90b835 - core::panicking::panic_fmt::h1ae32e95b4b1a788
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src/panicking.rs:64:14
  15:           0x90be16 - core::result::unwrap_failed::h8bd87678b87bb845
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src/result.rs:1790:5
  16:           0x438a6c - envio::import_profile::he337f85fe6110813
  17:           0x41bc1e - envio::commands::<impl envio::cli::Command>::run::hd47f498cbd5a07b8
  18:           0x42064f - envio::main::h203bc3a3b9c07d92
  19:           0x427806 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf7689d81c8e323c8
  20:           0x409dec - std::rt::lang_start::{{closure}}::h37a55eb61948c28a
  21:           0x893bf5 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h10e6b3810a97f594
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\core\src\ops/function.rs:287:13
  22:           0x893bf5 - std::panicking::try::do_call::hc0c08aef0d307148
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:483:40
  23:           0x893bf5 - std::panicking::try::hf8b174b6af1ac35c
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:447:19
  24:           0x893bf5 - std::panic::catch_unwind::h85d6d1a0b4671865
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panic.rs:140:14
  25:           0x893bf5 - std::rt::lang_start_internal::{{closure}}::h7ca5722ac975c7be
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/rt.rs:148:48
  26:           0x893bf5 - std::panicking::try::do_call::h741061858f588bf2
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:483:40
  27:           0x893bf5 - std::panicking::try::h6abad9e74e6bdc5f
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panicking.rs:447:19
  28:           0x893bf5 - std::panic::catch_unwind::hf171c5a39891248d
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/panic.rs:140:14
  29:           0x893bf5 - std::rt::lang_start_internal::h1fbc7ed3cff5c2a6
                               at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library\std\src/rt.rs:148:20
  30:           0x420b9d - main
  31:           0x4013c7 - __tmainCRTStartup
  32:           0x4014fb - mainCRTStartup
  33:     0x7ffc994855a0 - <unknown>
  34:     0x7ffc9abc485b - <unknown>

Option to store variable expiration date in envio?

🧠⚡ Idea / Feature Request

I just ran into the issue that my GH_TOKEN for use with gh—among other things—expired and for the past week I was uncertain why some tooling I use regularly broke seemingly out of nowhere.

Would it be possible, useful, and feasible for envio to support expiration dates for environment variables after which envio issues a warning on stderr and maybe even replaces the environment variable value with something along the lines of Expired on YYYY-MM-DD?

What would the implications for implementations be?

Is the expiration date stored alongside the environment value with a suffix, e.g. GH_TOKEN_EXPIRES, and such variables are removed from the environment prior to launching a command? Do they need to be removed?
What are your thoughts on this, @humblepenguinn? Something you'd be interested in thinking through together a bit more?

When using subcommand it's unclear how to list out profiles

When I try to using the command envio list I get an Error: Invalid number of arguments exception.

The command works properly when listing the variables in an existing environment but I cannot figure out how to get is to list the available profiles.

Support Fish

Hi,
do you have any plans to support the fish shell? When I run envio I get prompted that this shell is not supported and I should source the unencrypted file instead (which makes this program useless)
Would be really great!

setenv.sh ENV_VARS includes all stdout

Describe the bug
setenv.sh set ENV_VARS by running envio list -n dev -v.
This includes unnecessary stdout print messages like:

New version available: 0.4.1 -> 0.5.0
Loading Profile
Enter your encryption key

To Reproduce
Steps to reproduce the behavior:

1. Create a profile: envio create dev_profile
2. Add environment variable: envio add dev_profile -e dummy=key
3. Load profile: envio load dev_profile
4. Check setenv.sh. Line 8 has:

ENV_VARS=$(envio list -n dev_profile -v)

5. Create ENV_VARS by running: ENV_VARS=$(envio list -n dev_profile -v)
6. echo $ENV_VARS

New version available: 0.4.1 -> 0.5.0
Loading Profile
Enter your encryption key
test=dev

7. Check the temp file created by setenv.sh (it's automatically deleted by the script so you need to edit it to not remove it)

export New version available: 0.4.1 -> 0.5.0
export Loading Profile
export Enter your encryption key
export dummy=key

The temp file is sourced to the shell and it produces error due to the unnecessary export lines.
8. Sourcing setenv.sh produces an errror:

❯ source  /home/marloeu/.envio/setenv.sh
> Enter your encryption key: ************
/tmp/tmp.oTZRrzyHPC:export:1: not valid in this context: available:
Failed to load environment variables from temp file

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Expected behavior
Temp file should only do export dummy=key .

Device (please complete the following information):

• WSL2 (Ubuntu 23.10)
• zsh
• Version 0.4.1

Additional context
Looks like line export New version available: 0.4.1 -> 0.5.0 is the main issue. export Loading Profile does not produce an issue.

Latest version not installed after a fresh installation

I just installed using cargo install envio but it seems that I have 0.4.0 while the latest version is 0.4.1. I am not familiar with Rust tooling, so is it a cargo error that the latest version wasn't installed, or something that needs to be done on envio's side for cargo to install the latest version?

Environment variable value cannot contain an equal sign

Describe the bug
Environment variable values are truncated to the first equal sign.

To Reproduce

1. Add an environment variable with a value that contains an equal sign:
   ./target/debug/envio add -e foo=bar=baz test
2. Print the environment variables from the profile to verify whether the environment variable value was added completely:

./target/debug/envio launch -p env test | grep ^foo`
> Enter your encryption key: ********
foo=bar

Expected behavior
The environment variable foo should have the value bar=baz

Screenshots
N/A If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• OS: macOS 14.3.1 (23D60)
• Shell: zsh
• CLI Version: 0.5.0

Additional context
The issue seems to stem from the use of split in combination with next. The Split.remainder function seems to be well suited, unfortunately it is experimental API.
Possibly split_once could be helpful to address this issue. Currently I understand too little about envio's codebase and Rust to propose a PR that addresses this issue.

envio requires rust 1.76.0

Rust 1.76.0 was released on February 8th, 2024 and envio bumped its minimum required Rust version to 1.76.0 on Feburary 17th, 2024. Unless envio requires 1.76.0 specific features—which I don't think it does as I was able to build it with Rust 1.75.0—I'd like to suggest to switch back to 1.75.0 if it doesn't cause any issues.

Being unfamiliar with the Rust ecosystem I'm unaware of any common or best practices in regards to requiring a specific Rust version, and am happy to hear reasons for using 1.76.0 over 1.75.0.

My main reason is that I don't know when Rust 1.76.0 will make it into nixpkgs and the 1.76.0 requirement would hinder updates to the envio package in nix until 1.76.0 lands. Maybe it's more of a nuisance for me at the moment than a real issue…

Feature: Prompt for variable value

Describe the bug
envio does not prompt for variable value when told to add a variable by name only

To Reproduce

1. Add a new environment variable without a value

./target/debug/envio add -e API_TOKEN test
Loading Profile
Enter your encryption key
> Enter your encryption key: ********
Error: Can not parse Environment variable
Environment variables should be in the format of KEY=VALUE

Expected behavior
The value of an environment variable managed by envio is likely to be sensitive and
having to pass the environment variable including its value on the command-line probably adds envio command to the shell history and therefore the sensitive environment variable value in plain text. This defeats the purpose of envio in way.
Therefore I'd like to be able to tell envio to add and environment variable by only specifying its name and envio will then prompt for the variable value, e.g.:

./target/debug/envio add -e API_TOKEN test
Loading Profile
Enter your encryption key
> Enter your encryption key: ********
Enter the value for API_TOKEN: MANUALLY_ENTERED_SECRET_API_TOKEN
Applying Changes

Screenshots
N/A ~~If applicable, add screenshots to help explain your problem.``

Device (please complete the following information):

• OS: macOS 14.3.1 (23D60)
• Shell: zsh
• CLI Version: 0.5.0

Additional context
Add any other context about the problem here.

GPG based profile prompts for encryption key

Describe the bug
envio asks for encryption key for GPG based profile

To Reproduce

1. Create a new profile using a GnuPG ID

envio$ ./target/debug/envio create gpg -g $GPG_ID
Success: Profile created

2. Add a new variable to the newly created profile

envio$ ./target/debug/envio add --keys foo gpg
Loading Profile
Enter your encryption key
? Enter your encryption key:
[OH NO! you forgot your key! just kidding... or did you?]

Expected behavior
I'd expect the GnuPG Pinentry programm to ask for the passphrase of the key
instead of envio asking for an encryption key.

Screenshots
N/A If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• OS: macOS 14.3.1 (23D60)
• Shell: zsh
• CLI Version: 0.5.0

Additional context
I might be missing something in regards how to properly use envio with GnuPG, yet expectation is: I tell envio which GnuPG key to use and envio then relays all passphrase/pin input to GnuPG and Pinentry.
What am I missing?

can't parse .env.defaults with comments

trying to load a file .env.defaults which has bash comments.

it seems to not like it.

Crash upon first attempt to use

Describe the bug
I tried to follow the steps from the usage.md but it crashed out on step 1

To Reproduce
Steps to reproduce the behavior:

zsh ❯ cargo install envio
    Updating crates.io index
  Downloaded envio v0.4.1
  Downloaded 1 crate (121.1 KB) in 0.51s
  Installing envio v0.4.1
    Updating crates.io index
  ...
  ...

zsh ❯ envio create me
    Creating config directory
    Creating shellscript
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/mosthated/.cargo/registry/src/index.crates.io-6f17d22bba15001f/envio-0.4.1/src/bin/envio/main.rs:66:18
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Device (please complete the following information):

• OS: Pop_os 22.04
• Shell: zsh
• CLI Version: envio v0.4.1

---

Note
I ran the command again and it asked me for an encryption key. So hopefully things are fine, but I did want to make sure to report this issue.

use age for crypto

https://github.com/magiclen/rust-magiccrypt gives me really weird vibes, should use age instead this way you can use public keys from other members of your org easily

https://crates.io/crates/age

Not clear how to use "list" subcommand, or what it effectively does

It'd be helpful to describe how the "list" subcommand is used/what it actually does.

At this time, envio list --help says List all the environment variables in a profile or all the profiles which gives me the impression that it lists out all the environment variables associated with all profiles, but it actually does the following:

• envio list alone results in Invalid number of arguments error, because the command expects a profile name, or the string profiles to list out all the profiles. This improvement is being explored in #2
• envio list profileName or envio list profiles results in listing of environment variables associated with the particular profile (in this example, named profileName) or all profile names.

I think, overall, it'd be helpful to branch out list into two different commands; list-profiles to list all the profiles, and list-envvars profileName to list envvars associated with a profile name.

If it's decided to retain the current approach, it'd perhaps be helpful to explore improving the Arguments part of the --help output:

Inadequate file permissions of source, documentation, and asset files

Describe the bug
The majority of files in this repository have the execute bit set, even though the files do not need to be executable.

To Reproduce

1. List all files in git along with their file permissions

% git ls-files -s | awk '{print $1, $4}'

100755 .all-contributorsrc
100755 .github/ISSUE_TEMPLATE/bug_report.md
100755 .github/dependabot.yml
100755 .github/workflows/CICD.yml
100755 .gitignore
100755 CHANGELOG.md
100755 CODEOWNERS
100755 CODE_OF_CONDUCT.md
100755 CONTRIBUTING.md
100644 Cargo.lock
100644 Cargo.toml
100755 Cross.toml
100755 LICENSE-APACHE
100755 LICENSE-MIT
100755 README.md
100755 SECURITY.md
100644 assets/envio-gpg-final.gif
100644 assets/envio-passphrase-final.gif
100644 assets/icon-color.svg
100755 assets/logo/cover.png
100755 assets/logo/default.png
100755 assets/logo/info.txt
100755 assets/logo/profile.png
100755 assets/logo/vector/default-monochrome-black.svg
100755 assets/logo/vector/default-monochrome-white.svg
100755 assets/logo/vector/default-monochrome.svg
100755 assets/logo/vector/default.svg
100755 assets/logo/vector/isolated-layout.svg
100755 assets/logo/vector/isolated-monochrome-black.svg
100755 assets/logo/vector/isolated-monochrome-white.svg
100755 build.rs
100755 completions/_envio
100755 completions/_envio.ps1
100755 completions/envio.bash
100755 completions/envio.fish
100755 docs/build_from_source.md
100755 docs/project_layout.md
100755 man/envio.1
100755 src/bin/envio/cli.rs
100755 src/bin/envio/commands.rs
100755 src/bin/envio/main.rs
100755 src/bin/envio/version.rs
100755 src/crypto.rs
100755 src/lib.rs
100755 src/utils.rs

Expected behavior
Given that there are not scripts in this repository the source, documentation and assets files should have 100644 instead.

Screenshots
N/A If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• OS: macOS 14.3.1 (23D60)
• Shell: zsh
• CLI: 0.5.0

Additional context

One way to correct the file permissions is with the following command:
% git ls-files | xargs chmod 0644 and then add and commit the changes.