You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just wanted to float this idea with other maintainers.
We may want to support data encryption within central dogma so users can save sensitive data. (and centraldogma can possibly also act as a backend for a KMS)
One idea I had was:
Users can register a key[s] when creating a repository.
The registered key[s] encrypt the content when stored.
Users send over a private key when reading/modifying content. Alternatively, the encrypted content could be fetched and decrypted using a user's private key locally.
caveats:
Each file content would be encrypted, but the directory structure will still be visible
We should make sure that the encryption/decryption is performant since central dogma may host a large number of files with reasonable size (10MB~)
TBU...
The text was updated successfully, but these errors were encountered:
Motivation:
Before we support content encryption within CentralDogma, we need a way to secure the sensitive information in mirroring configuration.
We can do this using `ConfigValueConverter` that is introduced via line#890 as a temporarily workaround.
Modifications:
- Apply `ConfigValueConverter` to mirroring configuration.
Result:
- You can temporarily hide sensitive information in mirroring configuration using `ConfigValueConverter`. Please note that this feature will be deprecated after we implement line#755.
Motivation:
Before we support content encryption within CentralDogma, we need a way to secure sensitive information in mirroring configuration. We can do this using `ConfigValueConverter` that is introduced via #890 as a temporary workaround.
Modifications:
- Apply `ConfigValueConverter` to mirroring configuration.
Result:
- You can temporarily hide sensitive information in mirroring configuration using `ConfigValueConverter`. Please note that this feature will be deprecated after we implement #755.
Just wanted to float this idea with other maintainers.
We may want to support data encryption within central dogma so users can save sensitive data. (and centraldogma can possibly also act as a backend for a KMS)
One idea I had was:
caveats:
The text was updated successfully, but these errors were encountered: