Skip to content

Sensitive trait #229

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

Merged
merged 5 commits into from
Feb 23, 2021
Merged

Sensitive trait #229

merged 5 commits into from
Feb 23, 2021

Conversation

rcoh
Copy link
Collaborator

@rcoh rcoh commented Feb 23, 2021

Issue #, if available: Fixes #116
Description of changes: This PR adds support for the Smithy sensitive trait which hides fields from being displayed in logs. In Rust, this results in a custom Debug implementation when the Sensitive trait is present.

This is a pretty important feature to preserve, so I took the opportunity to also add the ability to add integration tests for individual services & added an integration test of the sensitive trait when applied to a Kinesis service.

Generated code diff: main-generated...sensitive-trait-generated

The derive order changed so the diff is a little noisy but here's a link to a custom implementation

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@rcoh rcoh added this to the Dynamo DB milestone Feb 23, 2021
@rcoh rcoh requested a review from a team February 23, 2021 15:50
Comment on lines 107 to 108
if (needsCustomDebug) {
val withoutDebug = containerMeta.derives.copy(derives = containerMeta.derives.derives - RuntimeType.Debug)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since you already have the code to build the custom Debug impl anyways, you might consider just making that the only path. if i read this correctly, if you were to just always execute the code as if needsCustomDebug = true then you'd arrive at the same impls, even in cases where there are no sensitive fields.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that's correct. I'm considering that—the only reason not to would be the code volume generated. I'm not sure how derive(Debug) compares with generating it.

But I just looked into it and it seems like it should be at worst the same. I think that's a good simplification.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

password: Some("don't leak me".to_owned()),
secret_key: Some("don't leak me".to_owned())
};
assert_eq!(format!("{:?}", creds), "Credentials { username: Some(\"not_redacted\"), password: \"*** Sensitive Data Redacted ***\", secret_key: \"*** Sensitive Data Redacted ***\" }");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

np: how do you feel about these test assertions relying on the whitespace decisions of the debug formatter?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love it, but if it changes, I do sort of want to know about it.

rcoh added 2 commits February 23, 2021 17:53
This actually causes a reduction in llvm-lines & apparently can improve compile performance. It also simplifies the code.
@rcoh rcoh enabled auto-merge (squash) February 23, 2021 23:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sensitive trait support
2 participants