Skip to content

Redact the rest values once the previous one matches redact fields #12980

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 1 commit into from
Sep 15, 2022

Conversation

jenting
Copy link
Contributor

@jenting jenting commented Sep 15, 2022

Description

Redact the rest values once the previous one matches redact fields

Related Issue(s)

Fixes https://github.com/gitpod-io/security/issues/64

How to test

Check the unit test.
Check the issue to see how to reproduce and test it.

Release Notes

None

Documentation

None

Werft options:

  • /werft with-preview

@jenting
Copy link
Contributor Author

jenting commented Sep 15, 2022

/werft run with-preview

👍 started the job as gitpod-build-jenting-64.5
(with .werft/ from main)

@jenting jenting marked this pull request as ready for review September 15, 2022 06:00
@jenting jenting requested review from a team September 15, 2022 06:00
@github-actions github-actions bot added team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team labels Sep 15, 2022
Copy link
Member

@svenefftinge svenefftinge left a comment

Choose a reason for hiding this comment

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

It seems to work but comes with a pretty hard-to-understand logic (at least for me 😇 ).
Adding some more tests would help. The core problem is that we want to redact based on property name not the value (as https://github.com/cloudfoundry/lager/blob/master/json_redacter.go does). So when we have properties like envs that are described on meta-level (name, value) it doesn't work so well anymore. This change "hacks" it in a way that it just redacts the rest of object (alphabetical property order), which might cause unwanted effects.

I.e this test case would pass:

`{"env":[{"another":"value","name":"secret","specialproperty":"foo"}]}`,
`{"env":[{"another":"value","name":"[redacted]","specialproperty":"[redacted]"}]}`,

I'm still approving as it solves the issue.

@roboquat roboquat merged commit cd0247a into main Sep 15, 2022
@roboquat roboquat deleted the jenting/64 branch September 15, 2022 09:37
@roboquat roboquat added the deployed: webapp Meta team change is running in production label Sep 16, 2022
@svenefftinge
Copy link
Member

alphabetical property order

I think it is not alphabetical order but arbitrary as I've seen this test fail occasionally.

@jenting
Copy link
Contributor Author

jenting commented Sep 16, 2022

alphabetical property order

I think it is not alphabetical order but arbitrary as I've seen this test fail occasionally.

Thanks for the heads up. Yes, the order is randomly not alphabetical. I will file a new PR to address it.

@roboquat roboquat added deployed: workspace Workspace team change is running in production deployed Change is completely running in production labels Sep 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed: workspace Workspace team change is running in production deployed Change is completely running in production release-note-none size/S team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants