Gustavo Fernandes de Carvalho

> Hi, > > The new repo is still at v0.x > > When is it safe to migrate production deployments over? Are there plans for a 1.0 release? Hi...

Hi @shuheiktgw ! Thank you for your contribution! Regarding your implementation, my concern is that this will make the need to set up a property in the Fake provider to...

@shuheiktgw any news on this one? If you're out of time, let us know - we can finish this implementation up.

no worries @shuheiktgw ! It also took me a while to take a look at it again!

One thing we are also requesting now (like we deployed it yesterday), is that every PR should have a DCO signoff. This means you should commit your code using like...

hey @ianpurton ! I'm just wondering. Is this feature about compatibility with SealedSecrets, or to you it would suffice to be compatible with secret decryption?

regarding the APIs, they are not the same, unfortunately. As you can see, `SealedSecrets` do not have a `data` field. Instead they have an `encryptedData` one, which makes the conversion...

There is already some support for decryption mechanisms using [sprig functions](http://masterminds.github.io/sprig/crypto.html). If that's still not enough, I think the better way to support it would be to add some custom...

Second option: We add in csi-secret-store a [compatible grpc server](https://secrets-store-csi-driver.sigs.k8s.io/providers.html) and add an API in our project that responds to given requests on requested secret stores. the handling of the...

after reading this [design doc](https://docs.google.com/document/d/10-RHUJGM0oMN88AZNxjOmGz0NsWAvOYrWUEV-FbLWyw/edit), actually none of the options above make sense. Each provider from csi-secret-store is responsible for both communicating with a given provider and for handling the...