The idea being we use use stdin/out from other binaries as the interface, optionally.
Something like ProviderKind::CredentialHelper which literally just calls format!("teller-credential-{} {}", bin, action)? Albeit without the command injection
This may also allow fancier credential syncing where we may have needed a template before, e.g. if i wanted to setup a docker registry auth where our secret is an arbitrary provider, we may teller put it by essentially calling docker login ${registry:-} -u ${user} --password-stdin. I think before i would have needed docker-temp.t and then overloaded DOCKER_CONFIG locations, or some shell logic.
So that one may write custom providers of which are 'internal', a good example would be how
docker
does it:{ "credsStore": "ecr-login" }
ecr-login
provider, as written here: https://github.com/awslabs/amazon-ecr-credential-helperSo in teller world that may be:
or more likely:
The idea being we use use stdin/out from other binaries as the interface, optionally.
Something like
ProviderKind::CredentialHelper
which literally just callsformat!("teller-credential-{} {}", bin, action)
? Albeit without the command injectionThis may also allow fancier credential syncing where we may have needed a template before, e.g. if i wanted to setup a docker registry auth where our secret is an arbitrary provider, we may
teller put
it by essentially callingdocker login ${registry:-} -u ${user} --password-stdin
. I think before i would have neededdocker-temp.t
and then overloadedDOCKER_CONFIG
locations, or some shell logic.