Hi Yufei
I created https://github.com/apache/iceberg/issues/15314.
There is a workaround till this arrives:
Compute clients can do:
catalog.add_encryption_key(table, new_key_id)
catalog.update_table_properties(table, {"encryption.current-key-id":
new_key_id})
It is not atomic, but it gets us past this as a blocker.
--
Anand
From: Yufei Gu <[email protected]>
Date: Thursday, February 12, 2026 at 9:50 PM
To: Anand Kumar Sankaran <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: RFC for table-level encryption support (#2829)
This Message Is From an External Sender
This message came from outside your organization.
Report
Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZABkHi1B67qNGoJr0iIMV2VdHYQqj_G7Q-s5K2DOOMvKALEPrU2GvudX_VARaGKk53RaE1sT0QxNtfM-3grh0_X_JIJzYL3SqsjXwSlxQntfTMDkgS4kNxDzCPK2$>
Thanks Anand for addressing the feedback.
1. I'd recommend adding a Rotate encryption key REST endpoint to IRC, so that
it works across engines. If IRC does not take it, we can consider to define a
Polaris specific approach.
2. The checksum is acceptable to me as an initial step., but may not be
sufficient if users want to hide it, as it is currently plain text. It's
reasonable as phase one. We can continue exploring options such as making
metadata.json optional or leveraging storage level permissions for stronger
protection.
3. Will take a close look later
4. It makes sense to take a phased-in approach.
Yufei
On Thu, Feb 12, 2026 at 6:39 PM Anand Kumar Sankaran
<[email protected]<mailto:[email protected]>> wrote:
Yufei, Mike, Prashant, Russell
Thank for you for your detailed feedback. I have updated the
RFC<https://urldefense.com/v3/__https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?usp=sharing__;!!Iz9xO38YGHZK!7SN7TreU_dJsdmWKuRe8vMFJkl-AZH6mu-_QhrmHet6I1ReHkYcRbIncpue3D5OzVbAOcDSQJZpKaq0fDiXap80$>
based on your feedback. I request you to look at the RFC again. I marked some
comments as resolved just so that I know what I need to focus on next, please
feel free to reopen.
I think we need agreement on the following:
1.
Rotate encryption key REST endpoint: Do we need to wait for IRC to add this?
There is an old PR #2373 that was closed as not
planned<https://urldefense.com/v3/__https://github.com/apache/iceberg/issues/2373__;!!Iz9xO38YGHZK!7SN7TreU_dJsdmWKuRe8vMFJkl-AZH6mu-_QhrmHet6I1ReHkYcRbIncpue3D5OzVbAOcDSQJZpKaq0fNqJgUeg$>.
If we want to wait for IRC, can this work still be done without the REST
endpoint?
2.
Is the proposal for protecting metadata.json using checksum
sufficient<https://urldefense.com/v3/__https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?tab=t.0*heading=h.hj35el4zxapx__;Iw!!Iz9xO38YGHZK!7SN7TreU_dJsdmWKuRe8vMFJkl-AZH6mu-_QhrmHet6I1ReHkYcRbIncpue3D5OzVbAOcDSQJZpKaq0fOgsjDUI$>
and acceptable?
3.
Is the proposed Key Rotation
semantics<https://urldefense.com/v3/__https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?tab=t.0*heading=h.3p1v44t5whpl__;Iw!!Iz9xO38YGHZK!7SN7TreU_dJsdmWKuRe8vMFJkl-AZH6mu-_QhrmHet6I1ReHkYcRbIncpue3D5OzVbAOcDSQJZpKaq0f4b9qPf4$>
acceptable?
4.
Can snapshot-to-snapshot migration path be deferred to another follow up RFC /
design?
In general, this feels like a lot of work to be done in one go. I would
appreciate any guidance on how to break this down into smaller chunks to make
progress.
Thanks again.
—
Anand
From: Yufei Gu <[email protected]<mailto:[email protected]>>
Date: Monday, February 9, 2026 at 10:56 AM
To: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: Anand Kumar Sankaran
<[email protected]<mailto:[email protected]>>
Subject: Re: RFC for table-level encryption support (#2829)
This Message Is From an External Sender
This message came from outside your organization.
Report
Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZABkHi1B6_pOVSGpMMuQc0CmP3OULNHOAUHUwYVTgbsx_oh5Ze7QOuU7LW1BuqjeDCi1LpG0R1DEuMHUCxOCo0hQG1mi4VmtapPKGSElXop473V-D5mKBlzl65oK$>
Hi Anand, thanks for the RFC. I think it's the right direction, which may
significantly promote the use of the Iceberg Table encryption. Left some
comments. I think we still need to determine which part would be better suited
for IRC and how we will protect metadata.json better.
Yufei
On Mon, Feb 9, 2026 at 9:33 AM Michael Collado
<[email protected]<mailto:[email protected]>> wrote:
Very awesome to see. I left a few comments in the doc.
Mike
On Mon, Feb 9, 2026 at 8:12 AM Anand Kumar Sankaran via dev <
[email protected]<mailto:[email protected]>> wrote:
> Hi all
>
> Please find an RFC for table-level encryption support.
> https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?usp=sharing<https://urldefense.com/v3/__https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?usp=sharing__;!!Iz9xO38YGHZK!_Cc4ra1dyOvDg7UuabtBS1JqIdb7-ZLvhB0sCEvp1mNohZDTHqUj4QdsSiYNdc52VM7togKNDyMdHIKbbRsb2BI$>
>
> The feature request for this feature can be found here:
> https://github.com/apache/polaris/issues/2829<https://urldefense.com/v3/__https://github.com/apache/polaris/issues/2829__;!!Iz9xO38YGHZK!_Cc4ra1dyOvDg7UuabtBS1JqIdb7-ZLvhB0sCEvp1mNohZDTHqUj4QdsSiYNdc52VM7togKNDyMdHIKb4Th5C-Q$>.
>
> I appreciate any feedback and critical reviews from you.
>
> —
> Anand
>
