+1 (binding) On Tue, Aug 11, 2026 at 11:25 AM Alexander Bailey <[email protected]> wrote:
> +1 > > Thanks, > Xander > > On Tue, 11 Aug 2026 at 19:01, Anurag Mantripragada < > [email protected]> wrote: > >> +1 (non-binding) >> >> On Tue, Aug 11, 2026 at 8:57 AM Russell Spitzer < >> [email protected]> wrote: >> >>> +1 >>> >>> On Tue, Aug 11, 2026 at 1:42 AM Gidon Gershinsky <[email protected]> >>> wrote: >>> >>>> +1 >>>> >>>> Cheers, Gidon >>>> >>>> >>>> On Mon, Aug 10, 2026 at 10:36 PM Gábor Kaszab <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> The current spec says that the encryption key for table statistics >>>>> should be stored as raw key-metadata. However, since the table statistics >>>>> metadata is stored within the unencrypted table metadata, it's not secure >>>>> to follow the spec here. >>>>> >>>>> The proposal is two fold: >>>>> 1) Deprecate the 'key-metadata' field in table statistics (Note, >>>>> partition statistics doesn't have this field in the spec) >>>>> 2) Add encryption 'key-id' field to table and partition statistics. >>>>> This points to an encrypted encryption key stored in Table >>>>> metadata's 'encryption-keys' (that in turn points to the KEK in the same >>>>> list). This behaviour is similar to how we do the same for manifest list >>>>> encryption keys. >>>>> >>>>> PR: https://github.com/apache/iceberg/pull/17533 >>>>> >>>>> Best Regards, >>>>> Gabor Kaszab >>>>> >>>>
