Supabase security advisor will still flag EQL functions until packaged as an extension

[coderdan]

Context

EQL ships its own splinter check (tasks/test/splinter.sh) with an explicit allowlist of function_search_path_mutable findings on the EQL functions that must remain inlinable for the planner to match the relevant functional index. As of #190 + #196 the allowlist covers:

• 8 GIN-critical wrappers (@>, <@, 3× jsonb_contains, 3× jsonb_contained_by) — GIN index on eql_v2.jsonb_array(col)
• 6 equality wrappers (3× =, 3× <>) — btree-hash index on eql_v2.hmac_256(col)
• 5 LIKE wrappers (3× ~~, plus like, ilike) — GIN index on eql_v2.bloom_filter(col)
• 3 aggregates (min, max, grouped_value) — ALTER AGGREGATE has no SET configuration_parameter syntax

That allowlist is local to our build pipeline. Supabase customers running EQL will still see all of these flagged in their dashboard's Security Advisor, because the advisor runs splinter against their database and has no knowledge of our exemptions.

Why we can't fix this today

There are two clean ways to make these warnings go away for downstream Supabase users:

a) Package EQL as a real PostgreSQL extension (CREATE EXTENSION eql_v2)

Splinter's function_search_path_mutable rule explicitly excludes functions owned by extensions:

left join pg_catalog.pg_depend dep
    on p.oid = dep.objid and dep.deptype = 'e'
where ...
    and dep.objid is null  -- exclude functions owned by extensions

If EQL functions were owned by an extension, splinter would skip them entirely — both the inlinable wrappers and the aggregates, no allowlist needed.

Blocker: Supabase only allows a curated list of first-party extensions. Third-party extensions (including EQL) aren't permitted on Supabase-hosted instances yet. We are working with Supabase to change this; no firm date.

b) Get our allowlist entries surfaced in Supabase's hosted advisor

Supabase would need a mechanism to suppress specific findings for trusted publishers (or accept body-based qualification as a substitute for proconfig). Neither exists today and both require Supabase-side changes.

What we should do in the meantime

1. Document the caveat in the EQL Supabase install guide. Make it clear that the warnings are expected, list the exact rule + functions, and link to this issue and the in-repo allowlist (tasks/test/splinter.sh).
2. Track the upstream conversation. Any change in Supabase's third-party extension policy unblocks (a) outright; any addition of a per-finding suppression mechanism unblocks (b).
3. Resist the temptation to add SET search_path to silence the warnings. It would silently break inlining and force seq scans on Supabase — much worse than a yellow warning in the advisor UI.

Definition of done

This issue closes when EQL ships as a CREATE EXTENSION-installable package on Supabase (option a) or Supabase exposes a way for users to acknowledge our specific findings (option b).