-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Easy way of decrypting fields #19
Comments
@jcheng5, @wch, and @trestletech, how does this dovetail with other work/thinking we have done on this front? (I know we have it on our radar to support encrypted config using another mechanism, seems like the |
I'm not aware of anything on our radar around encrypted config values on the R side. Looping @slopp in for broader perspective, though. |
I haven't thought much about this recently but this looks like a nice extension. @hadley @gaborcsardi may have more thoughts. |
There are two things here IMO. Encrypted fields are one, and if there are good use cases for them, then they make sense. I can't really judge this. Second, using the "type system" of YAML, so the parsed config will be typed. E.g. something like shinydemo:
host: !type kms |
AAAbadcafe... and then the parser could just add a OTOH, AFAICT with shinydemo:
host: !expr kms_decrpyt("
AAAbadcafe...") |
I'd rather avoid putting R function calls in the YAML config if possible so that we can keep that language-independent. Eg one could use the same YAML config both from R and Python -- implementing in both languages how to deal with the |
Yeah, that is a good point for sg like shinydemo:
host: !type AWR.KMS::kms |
AAAbadcafe...
But then you'd need to walk the list to decrypt, or config would need to be able to pass handlers to the yaml package. |
Not sure: trying to keep the YAML language-independent, and for a ciphertext to be decrypted via Amazon KMS,
I think that's fairly easy and already done in 1-1 lines in my own |
I agree that we should keep the YAML language-independent. I also agree that since we won't likely end up with more than a handful to a couple-dozen of these handlers (we currently have 0) that we don't need a formal namespacing mechanism per se. That said, since |
Would you be open/interested in a PR introducing new YAML types for encrypted
config
values?See eg https://github.com/daroczig/dbr/blob/master/R/config.R#L32
(Image source: http://bit.ly/user2018-dbr)
^^ Although that only supports Amazon KMS for now, but extending it with new types would be similarly easy. This way I could drop the custom functions from my
dbr
pkg and useconfig
.The text was updated successfully, but these errors were encountered: