#Secret providers API

1 messages · Page 1 of 1 (latest)

weak sonnet
#

I think dag.Secret is only used in our tests. @ripe rose has more context on that. Not sure how much it's being used by the community.

ripe rose
#

yes, let's have Secret do the mapping 🙂

#

the old version is indeed only really used in tests, we've wanted to remove it from the public api for a long while

#

one question along these lines though, do we want it to be backwards compatible? so old modules that use SetSecret continue working?

#

because if we want SetSecret to keep working with a plaintext arg, then we'll need to keep something like it (so we don't store the secret in the graph)

#

we could rename the current implementation to __secret in the api, and then just have setSecret return an instance of that, while the new secret method is as you suggest in option 2 above

verbal widget
verbal widget
#

Maybe I can rework the "legacy" / current secret store stuff into a secret provider

ripe rose
verbal widget
#

(at the very end of the comment)

#

secret transformation is definitely valid

#

Right now, the only way would be to go through plaintext-insecure:// for the tranformation, which is obviously a mess

#

The ideal solution would be "extensions" (e.g. the callback function you mentioned)

verbal widget
ripe rose
#

potentially, i might give it a _ which is our indicator for not generating sdk methods for it

#

i think it's worth removing this from our "public" api while we're here

verbal widget
ripe rose
#

ah

#

😛

#

gr

#

yeah, fine 😄

#

such is life

verbal widget
# 
type Leaker struct {}

func (l *Leaker) Leak(ctx context.Context) error {
    secret, _ := dag.Secret("mysecret").Plaintext(ctx)
    fmt.Println("trying to read secret:", secret)
    return nil
}
#

actually ... there's only one reference, and it doesn't look like it's doing anything

ripe rose
#

ooh yes

#

we can actually remove this test case

#

it's testing to see if you can leak a secret using .Secret

verbal widget
#

hmmm ... even LeakerBuild below is trying to mount the secret by bk id: "FROM alpine\nRUN --mount=type=secret,id=mysecret

ripe rose
#

yeah, these are tests to make sure you can't do this

verbal widget
#

which does absolutely nothing since we're registering them by IDDigest, not name?

ripe rose
#

the tests used to fail before we added protections to make sure you couldn't do this

verbal widget
#

@ripe rose on second thoughts: the function would still be there, just not exposed through the SDK, so the test is actually legitimate