envio-cli
Option to store variable expiration date in envio?
:brain::zap: 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?
The implementation for something like this won't be too complicated. I am sure we will be able to come up with a solution that works. Alongside this, I was also thinking we could add support for adding comments to the environment variables created, and maybe even profiles. What do you say, @afh? Do you think this is a feature you might consider using?
How about we store some metadata alongside the environment variables in a profile? Currently, it just stores the environment variables in an encrypted format. What if we add some additional data alongside it at the end or start of the buffer? Then we can just encrypt that entire buffer instead of the environment variables alone.
This will allow us to store extra metadata later on if we wish to.
From the top of my head I see little value in having profile and envvar comments for myself, because the profile and envvar names should be descriptive enough. What practical use case(s) for comments can you think of?
I'll have a look at how envio stores its envvars currently and will come back with an idea and proposal on how to approach this. It may take me a couple of days to get to it…
Okay now I see a good use case for envvar comments (ideally these can be multi-line). For example an envvar comment could include instructions how to regenerate an API token. In the case for a GH_TOKEN it could include the set of scopes that are needed.
Yep, Alongside that it can be used as a reminder, explaining the purpose the envvar. I suggest before implementing this we clean up the codebase first. There are a lot of areas where I see improvements can be made.
If we implement a feature right now, it will only add to the already poor foundation.
Sounds good to me, @humblepenguinn. Anything that I could have a look at to help with cleaning up the codebase?
I will get back to you on this @afh. Give me a few days, I'll make a list of everything that needs to get done and share that with you.
I appreciate your consistent contributions for the project, can't thank you enough!
Thank you for your kind words.
I was using envchain previously, but was annoyed that I could not encrypt the variables using GnuPG. Additionally envchain became a nuisance to use when installed via nix as it asks for the keychain password for every variable on first use with every new generation of nix (which for me happens more often than not).
So envio solves a fundamental problem for me and it solves it well. So thanks for envio, @humblepenguinn! 🙂
@afh, send me your email address either here or on my email [email protected]. I'll send you a invite to the notion page I created.
I have created a list of tasks that need to be completed. This isn't something I want to make public on the repository page for now since these are crucial necessities needed for the project and not something I want other people to contribute to or be aware about at this stage.
After these features have been implemented, any sort of improvements will be welcomed.