JB, Dennis, and I have raised several concerns in the thread(https://github.com/apache/polaris/pull/5246/changes#r4383768595), and it looks like they are still unresolved. The original comments date back to Oct 26, but we haven't received any responses or follow-ups for over a week.
Dmitri, could you please check with the author and help get these concerns addressed? Yufei On Thu, Nov 5, 2026 at 6:15 AM Dmitri Bourlatchkov via dev <[email protected]> wrote: > > Hi Yufei, > > I believe the comment thread you mentioned [1] has been resolved for > relevant grants. > > If you think something is missing, please respond with a more specific > rationale. > > PR [5246] has several approvals. As I mentioned before, I think it is > essential to have it in 1.9.0 to prepare users for future migration toward > better authorization coverage. Delaying this PR by another release will > effectively delay authorization improvements on the user side by two (!) > releases. > > Please note that the main purpose of this PR is establishing the new AuthZ > operation and a feature flag. The new check is _not_ enforced by default. > Any remaining changes for Ranger and internal RBAC grants can be done on > main after 1.9.0. > > I propose merging it before 1.9.0 is branched, ideally today or tomorrow. > > Thanks, > Dmitri. > > [5246] https://github.com/apache/polaris/pull/5246 > > [1] https://github.com/apache/polaris/pull/5246/changes#r4383768595 > > On Wed, Nov 4, 2026 at 6:52 PM Yufei Gu <[email protected]> wrote: > > > I'd suggest not merging when there are comments needed to be resolved, > > here is an open comment: > > https://github.com/apache/polaris/pull/5246/changes#r4383768595 > > Yufei > > > > On Wed, Nov 4, 2026 at 3:45 PM Dmitri Bourlatchkov via dev > > <[email protected]> wrote: > > > > > > Hi All, > > > > > > Given an extensive review period, I propose merging [5246] on Nov 6. > > > > > > Note: this PR does _not_ introduce any behaviour changes. It only > > prepares > > > options for stricter authZ in the future. > > > > > > Please reply to this thread or comment in GH if you have any concerns. > > > > > > Thanks, > > > Dmitri. > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > On Mon, Nov 2, 2026 at 10:16 AM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Hi Vignesh, > > > > > > > > Thanks for promptly addressing the feedback! > > > > > > > > I think PR [5246] approaches a mergeable state. > > > > > > > > Given that it introduces a migration action for users, which is > > optional > > > > in the current code, I think it makes sense to include the PR into the > > > > upcoming 1.9.0 release. This will enanle working on flipping the flag > > In > > > > the following release. > > > > > > > > Yufei, Dennis: Please take a look at the latest PR state. > > > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > > > Thanks, > > > > Dmitri. > > > > > > > > > > > > On Sat, Oct 31, 2026 at 12:11 PM vignesh a <[email protected]> > > wrote: > > > > > > > >> Hi all, > > > >> > > > >> Thanks Yufei, Dmitri and JB. I've restacked #5246 [1] > > > >> > > > >> Dropped GET_CATALOG_CONFIG_PROPERTIES. That takes out the second > > > >> authorizer op and the partial-result case Yufei called out, where a > > > >> client can't tell absent settings from withheld ones. > > > >> > > > >> Kept GET_CATALOG_CONFIG behind ENFORCE_CATALOG_CONFIG_AUTHORIZATION > > > >> (default false), as Dmitri asked. That covers the /config AuthZ gap as > > > >> of 1.8.0, and existing deployments keep today's behaviour. > > > >> > > > >> Once that check passes, the response still returns catalog properties > > > >> as it does today. > > > >> > > > >> CHANGELOG says the default is not flipping until the client-facing > > > >> config follow-up is settled, as JB asked. Client-facing vs server-only > > > >> properties can stay in its own thread. > > > >> > > > >> PR is updated now. PTAL > > > >> > > > >> Thanks, > > > >> *Vignesh* > > > >> > > > >> [1] https://github.com/apache/polaris/pull/5246 > > > >> > > > > > >
