feat: support sql func encrypt/decrypt #14717
Conversation
|
if time is allowed, let's merge this feature into v1.6.1 |
I am afraid we cannot make it.😥 It's a little too rushed. |
tabVersion
added
the
user-facing-changes
There was a problem hiding this comment.
There are a few regress test cases from Postgres pgcrypto that can be used to test e2e: https://github.com/postgres/postgres/blob/master/contrib/pgcrypto/expected/rijndael.out
LGTM
There was a problem hiding this comment.
Other proposed changes are here: #14869 (we can merge it into this branch/PR)
Seems blowfish support is still included. Are we confident in releasing it? Let's remove blowfish support as it is already considered legacy by openssl 3 and not enabled by default.
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 9425213 | Triggered | Generic Password | defcab8 | 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!
| -- key padding | ||
| SELECT encrypt( | ||
| '\x0011223344', | ||
| '\x000102030405', | ||
| 'aes-cbc'); | ||
| encrypt | ||
| ------------------------------------ | ||
| \x189a28932213f017b246678dbc28655f | ||
| (1 row) |
There was a problem hiding this comment.
PostgreSQL simply pads zero bytes for shorter key as these functions are supposed to be raw encryption. Key derivation is supposed to be handled by higher level utilities.
Our lack of such insecure (zero-pad-at-end) usage would not be a limitation in practice.
Co-authored-by: xiangjinwu <[email protected]>
Co-authored-by: Bohan Zhang <[email protected]> Co-authored-by: xiangjinwu <[email protected]>
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
add raw
encrypt/decryptfunctionsChecklist
./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.
where algorithm is one of:
* bf — Blowfishand mode is one of:
and padding is one of:
the given encryption/decryption key MUST match length 16/24/32 bytes as required by
aes-128/192/256follow up work: do key padding for key length does not match 16/24/32, then we no longer need the above constraint.cancel this item for postgres just pads all zero, which is not secure I think.examples
aes-cbc/pad:pkcs=> AES algorithm,cbcmode, enabling paddingaes=> AES algorithm,cbcmode, enabling paddingaes-ecb=> AES algorithm,ecbmode, enabling padding