fix: serialize secrets to json.#465
Conversation
Codecov Report
@@ Coverage Diff @@
## master #465 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 14 14
Lines 2225 2230 +5
Branches 437 437
=====================================
+ Hits 2225 2230 +5 |
|
I don't know if this is a good idea or not. I think @samuelcolvin would prefer not to do something like this. |
samuelcolvin
left a comment
There was a problem hiding this comment.
I think the change required here can be much simpler.
|
The reason I made changes to the str function for both is that if we keep it as is, then we end up with these kinds of things as JSON output: Where as with the modified str we would get something like this instead: Please let me know what you think. |
|
Ok, let's add a |
|
That will then need one line the docs/example to explain/show it. |
|
@samuelcolvin is that something like what you were thinking? |
|
Yes exactly. |
2727be7 to
801bcf8
Compare
|
@samuelcolvin I've been thinking about how to deal with a situation such as this: Which would result in: If you need the inner 'object' to be provided for the configuration of another item, you have to kind of force it to fit by modifying the values in-place to be what you want. Like for instance in the above example, where you'd have to unsecret the secret items(manually turn everything into Which is not especially useful, ideally we would be able to unsecret the entire dict recursively and then pass it on to classes or functions that need those items to be plain-text. Do you have any thoughts on this? |
|
See dangerouslySetInnerHTML in react. See hazmat in cryptography. The whole point is to make it somewhat involved to get the raw value. If there's any point whatsoever in include If people don't need it to be secret, they don't have to use it. In fact in your example above, it's still not exactly complicated to generate the uri: f'postgresql://{username.get_secret_value()}:{password.get_secret_value()}@{host}:{port}/{db_name}' |
|
@samuelcolvin In the postgresql example, that would expose secrets if the conf object is printed out. Anyway, that's not really related to this PR, just a couple of thoughts I was having. |
Yes, obviously! If you use the secret values then they may be visible in the context in which you use them, there's no way around that. The only point in |
* use pytest-examples * fix docstring tests on emscripten * working on linting examples * fixing more examples * update docstring * updating examples * all examples formatted * reformat examples * uprev deps * revert coverage * revert other uprevs * remove "HYPOTHESIS_PROFILE: slow" * fix ci * linting and add tmate * move tmate * add -g to RUSTFLAGS * allow coverage to fail
Change Summary
This change adds JSON serialization of secret types,
SecretStrandSecretBytes. Also modifies the str functions of the same.It does not support serialization of the actual serialized values, which it maybe should.
Related issue number
#462
Checklist