Allow setting tokens via env variables about cistern HOT 11 CLOSED

Some way to say "look at this envvar" from the config file would be a good way to do this. I guess making the password be something like:

token = "string" # current status
token = { value = "string" } # what it is interpreted as
token = { environment = "variable" }

This would also be possible:

token = { process = [ ... ] }

Guidance from rust-lang/rfcs#2730 would be useful to know how to interpret the process case on different platforms.

from cistern.

I'm not fond of changing the configuration file just to get tokens from environment variables because it seems like a very narrow use case. It also encourages sharing the same token with multiple applications which is not ideal.

However the token-from-process used by cargo seems like a good idea since it should cover most use cases of people storing their secrets outside of the configuration file. I'm not too worried about cross platform compatibility since Golang provides exec.Command to run arbitrary commands and the signature of this function matches the value expected for token-from-process.

So setting a token could be done in a couple of ways:

# Token stored in the configuration file
token = "mytoken"
# Token stored in an environment variable
token-from-process = ["bash", "-c", "echo $MY_API_TOKEN"]
# Generic case: token returned by calling `executable arg1 arg2 ...`
token-from-process = ["executable", "arg1", "arg2"]

As mentioned in the RFC the process inherits stdin and stderr so people could store their tokens in their password manager and be prompted for a password when running cistern. It seems like a good solution. Thanks @mathstuf for pointing out the RFC.

from cistern.

It also encourages sharing the same token with multiple applications which is not ideal.

This is the exact use case I have. I don't want to generate 15 tokens for GitHub but have on per machine and share it with all my programs and using ENVs for something is not narrow. Basically any program which wants an API Token of some sort uses the ENV GITHUB_TOKEN.

Also I don't really see the need to store an API token which has the scope of showing publicly available information in a password manager.

from cistern.

Why would you need a token per project for cistern? Isn't the token per host in the configuration file?

from cistern.

I made the changes for this feature on the following branch: https://github.com/nbedos/cistern/tree/feature/token_from_process

Usage is detailed in the sample configuration file:

# Also, every "token" key can be replaced by "token-from-process" which is a list of strings
# consisting of the name of an executable to call followed by the arguments to be provided to it.
# The process will inherit stdin and stderr (allowing for password prompts) and the output of the
# process will be used as the value of the token.
#
# Examples:
#        # Read token from environment variable
#        token-from-process = ["bash", "-c", "echo $MY_API_TOKEN"]
#
#        # Read token from `pass` store
#        token-from-process = ["pass", "ci/gitlab/cistern"]
#

I tested this with pass and the workflow is quite nice. You get a single password prompt and then cistern starts as normal. It even works without an X server.

@SuperSandro2000 Let me know what you think.

from cistern.

Single password prompt even for multiple tokens?

I still kinda prefer getting environment variables directly.

from cistern.

Well you can do that by setting token-from-process = ["bash", "-c", "echo $MY_API_TOKEN"] and you won't be asked for a password.

pass is just a password store I tested but you don't have to use it all. But yes, it asks for a single password if all tokens are encrypted using the same GPG key.

from cistern.

This only works if I have the tokens in my startup script and is kinda a workaround.
Using os.Getenv("MY_API_TOKEN") would be preferable and just nicer.

from cistern.

This only works if I have the tokens in my startup script

This should be fixed by a4392aa

Using os.Getenv("MY_API_TOKEN") would be preferable and just nicer.

Yeah but then I have to implement, test and document both token-from-env and token-from-process when just the second configuration option covers both cases.

I understand the syntax is not ideal but it provides the functionality you requested and I don't see any other drawback. And given how it's implemented it will also work for other people storing their credentials elsewhere meaning it's unlikely I'll have to extend this feature later.

from cistern.

Yeah but then I have to implement, test and document both token-from-env and token-from-process when just the second configuration option covers both cases.

So right now we are both lazy and don't want to do something. I mean it should be fine. Thanks 👍

from cistern.

So right now we are both lazy and don't want to do something.

Just stop contributing to this repository. I'm sure you can find other repositories and developers that are up to your standards.

from cistern.