-
Notifications
You must be signed in to change notification settings - Fork 20
feat!: Adding support for redacted environment variable values through… #232
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
Conversation
f5485d3 to
50db13f
Compare
| h = sha256() | ||
| h.update(message.encode("utf-8")) | ||
| logger_name = "redacted" + h.hexdigest()[0:32] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do the logger names need to be these hashes? Hard to tell if it's a functional part of the logger or just a way to make a random name for the test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah kind of ugly having this in the tests. Basically we're just setting up unique logger names. I've moved all of these to be dealt with inside the helper I made based on your other suggestion so they aren't cluttering up these tests anymore
| mock_log.warning.assert_called_once() | ||
| assert "REDACTED_ENV_VARS extension is not enabled" in mock_log.warning.call_args[0][0] | ||
|
|
||
| # The callback should NOT be called since our implementation changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"since our implementation changed" seems like a leftover AI comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, removed, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the code in these tests looks like it gets repeated a lot, like setting up the logger. Is there a good way to parametrize the tests or make some helpers? (There might not be a great way.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good call, it sure does! I've created a helper that reduces the boilerplate in these tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One higher level test that would be easy to read and help explain the feature at the same time could be having an input log file and output file, and assert on the output contents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a similar test in here like what you're thinking? I see some similar ones in openjd-cli and did add a more long form higher level test like what I think you might be describing, that will be in the next PR
3aa697e to
7f3a1e1
Compare
src/openjd/sessions/_subprocess.py
Outdated
| # On Windows, we need to handle redaction in command strings | ||
| cmd_line = list2cmdline(self._args) | ||
| # Pre-redact any sensitive information in the command string | ||
| cmd_line_for_logger = pre_redact_command(cmd_line) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the redacted value gets escaped as a result of the list2cmdline call, it would probably slip through here. Should this instead redact the _args list to in parallel construct the cmd line for logging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure what case you're thinking here - pre redact will redact everything after the openjd_redacted_env: token appears (We don't try to figure out where the value(s) begin and end in what might be a complicated multi line string) - we just want to be sure we're redacting something that is not yet but is likely about to become a redacted value.
ae54d72 to
4ada5c9
Compare
| # Split into name and value | ||
| parts = message.split("=", 1) | ||
| name = parts[0].rstrip() # Remove trailing spaces | ||
| value = parts[1] # Keep leading spaces in value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this doesn't handle the JSON case of _handle_env. Can you add tests for a case like:
openjd_redacted_env: "MY_VAR=abc\ndef"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the JSON case was missed, thanks! I've added JSON/multi line support with testing and a second openjd run template example in the description to show the current behavior.
| or "REDACTED_ENV_VARS" in self._revision_extensions.extensions | ||
| ) | ||
|
|
||
| def apply_message_redaction(self, record: logging.LogRecord): |
Check notice
Code scanning / CodeQL
Explicit returns mixed with implicit (fall through) returns Note
|
|
||
| # If we have an original value (from JSON parsing), add it to redaction set too | ||
| if original_value is not None: | ||
| self._redacted_values.add(original_value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will have the trailing quote, is that what you intended here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is yeah - not completely necessary though
… openjd_redacted_env Signed-off-by: Brian Axelson <86568017+baxeaz@users.noreply.github.com>
|


What was the problem/requirement? (What/Why)
We want to support redacted environment variables through openjd_redacted_env from RFC 0003
What was the solution? (How)
Add support for the new token.
What is the impact of this change?
Environment variables may be set similarly to openjd_env while their values become redacted strings in the logs through openjd_redacted_env:
How was this change tested?
All existing tests pass
All new unit tests pass
Running with the following new sample template:
Produces the following output:
Running with the following sample template:
Produces the following output:
Was this change documented?
Yes
Is this a breaking change?
No
Does this change impact security?
Yes - it has been through a security review and approved.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.