You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on a project where I would like to use SOPS as the secret engine. In this context, I want to be agnostic whether the user is using my CLI or sops to interact with the secret, but that requires that I generate the .sops.yaml in their repository.
Currently, there is no simple public Load function that returns a Config and I am wondering if that is by design. My use-case requires both the full config creation_rules and destination_rules.
I am happy to implement this, but I wanted to know if I am not doing anything wrong here.
The text was updated successfully, but these errors were encountered:
Exposing more things, especially the config, makes it a lot harder to do changes in that area in the future, since they then need to be fully backwards compatible.
For that reason I personally don't think this is a good idea.
I see where you are coming from, but could one not argue that the config is currently part of the (public) API considering that it exists in a lot of repositories in the wild?
Hi,
I am working on a project where I would like to use SOPS as the secret engine. In this context, I want to be agnostic whether the user is using my CLI or
sops
to interact with the secret, but that requires that I generate the.sops.yaml
in their repository.Currently, there is no simple public
Load
function that returns aConfig
and I am wondering if that is by design. My use-case requires both the full configcreation_rules
anddestination_rules
.I am happy to implement this, but I wanted to know if I am not doing anything wrong here.
The text was updated successfully, but these errors were encountered: