Please note that compression before encryption is considered a security breach. I would not implement this without a clear warning and specific user approval.
Regards,
Josh
On Mon, Jul 3, 2023 at 10:54 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
i opened https://github.com/ceph/ceph/pull/52300 to require a
'compress-encrypted' zonegroup feature for this, and updated the
documentation and release note accordingly
On Mon, Jul 3, 2023 at 2:11 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
>
> hey Shilpa and team,
>
> early in the reef cycle, https://github.com/ceph/ceph/pull/46188 was
> contributed to support the combination of server-side compression and
> encryption on the same object data. only recently did we catch a
> regression in multisite, where such objects fail to replicate and can
> cause crashes. this bug, tracked in
> https://tracker.ceph.com/issues/57905, was just fixed and backported
> for reef in https://github.com/ceph/ceph/pull/52297. this was a
> regression in reef, so i was planning to treat it as a blocker
>
> in that backport, i added a warning to the original release note:
>
> RGW: Compression is now supported for objects uploaded with
> Server-Side Encryption. When both are enabled, compression is applied
> before encryption.
> WARNING: In a multisite configuration, objects that are both
> compressed and encrypted will not replicate correctly to Pacific or
> Quincy. Upgrade all zones to Reef before enabling compression.
>
> it occurs to me that we might add a new 'compress-encrypted' feature
> flag to the zonegroup (similar to the 'resharding' flag in reef) to
> prevent this combination of compression+encryption until all zones
> upgrade and enable it. do you think that's worth doing, or is a
> release note sufficient?
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
