-
Notifications
You must be signed in to change notification settings - Fork 589
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
feat(parser): redact SqlOption #14760
Conversation
src/connector/src/source/common.rs
Outdated
#[derive(Clone, Debug, Deserialize, PartialEq, with_options::WithOptions)] | ||
pub struct SecretString { | ||
inner: redact::Secret<String>, | ||
} |
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.
What about #[serde(transparent)]
?
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.
redact::Secret
doesn't implement Serialize
.
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.
Meanwhile impl Serialize for SecretString
should be chosen according to use case, i.e. whether the original value or the redacted one is expected.
Though currently there is no other use case that serializes SecretString
.
src/sqlparser/src/ast/utils.rs
Outdated
} | ||
|
||
fn serialize_str(self, v: &str) -> Result<Self::Ok, Self::Error> { | ||
Ok(Value::SingleQuotedString(v.to_string())) |
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 there's a special character (like \t
), I guess we should serialize into a CstyleEscapedString
instead. #14193 (comment)
src/sqlparser/src/ast/utils.rs
Outdated
SqlOption { | ||
name: to_object_name("d"), | ||
value: Value::Null | ||
}, |
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.
Should we omit the field that's unset? I guess we need an end-to-end test like
SQL
--parse--> AST
--deser--> Connector Options
--redact--> Redacted Connector Options
--ser--> AST
--unparse--> SQL
to check whether it works well.
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.
Omitted the field that's unset.
Modified pubsub.slt
to cover the code path.
# Conflicts: # src/connector/src/source/common.rs
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
9425213 | Triggered | Generic Password | f2644fd | ci/scripts/regress-test.sh | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
definition: if source.owner == user_id { | ||
source.create_sql() | ||
} else { | ||
source.redacted_create_sql() | ||
}, |
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.
Why do we distinguish owner? I'm not sure whether this is reasonable 🤣
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.
User should be able to view secrets in definition somehow.
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 one reason user want redaction is that they want to SHOW CREATE
and share it to us for debugging. For this use case, it seems not very convenient if we distinguish by owner.
@BugenZhao comes up with an idea that maybe we can add sth like SHOW REDACTD CREATE
. 🤣 (Maybe alternatively we can add a session variable or sth..?)
I'm not sure what users want now. @fuyufjh Do you have any ideas about users' requests? Since I saw you opened #15402
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.
BTW on the other hand, force redaction if source.owner != user_id
sounds good 🤔
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.
The major requirement is that users are concerning about the secret leaks. Before having a real secret store, I think we should redact for all users.
try_redact_statement(&stmt).map(|stmt| stmt.to_string()) | ||
} | ||
|
||
fn try_redact_statement(stmt: &Statement) -> Result<Statement, Error> { |
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.
Let me try to summarize my understanding of this PR:
try_redact_statement
(Statement
->Statement
) is the end goal we want to achieve.- The implementation is
Statement
->ConnectorProperties
->Statement
.- The
ConnectorProperties
->Statement
is achieved by theSqlOptionVecSerializer
, and theSerialize
impl (which actually does the redaction)
- The
This approach generally sounds good to me. But I have some thoughts:
- In order to redact
Statement
->Statement
, an easier approach IMO is just modifying the hashmap directly. We can check the key's name (like having a blacklist for redaction). - The redaction needs to be performed manually, so we may still access original SQL in e.g., SQL log. I don't know if this is good enough.
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.
Oh, #14310 looks very like the solution in my mind, but it contains more stuff, including redacting table/column names. Why don't we go with that approach? 🤔
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.
In order to redact Statement -> Statement, an easier approach IMO is just modifying the hashmap directly. We can check the key's name (like having a blacklist for redaction).
Yes, #14310 basically redact all with_options values, i.e. an empty whitelist.
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.
The upside of this PR is it's strong typed, and secrets in ConnectorProperties won't be printed unexpectedly.
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.
secrets in ConnectorProperties won't be printed unexpectedly
I agree this is quite a good change.
However, previously ConnectorProperties
doesn't implements Serialize
(and Debug
) (Actually I removed some unnecessary #[derive(Serialize)]
), so probably it won't be printed unexpectedly.
Now we adds #[derive(Serialize)]
(although redacted), I feel this isn't very cool..
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.
However, previously ConnectorProperties doesn't implements Serialize (and Debug)
It seems I'm wrong. It already implemented Debug
. 🤡
prefer #14310 |
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Implement this idea.
redact::Secret<String>
is supported (used in*Properties
), via a wrapper typeSecretString
.redact::Secret<T>
are not supported, for the sake of implementation simplicity. Because otherwise redacted string need be able to convert back to the original type.This PR doesn't perform"escape back the unescaped CstyleEscapedString when serializing it"
, because I think it's non-trivial and always converting toSingleQuotedString
is just fine.#14115
Checklist
./risedev check
(or alias,./risedev c
)Documentation
Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.