Drop the three orphaned SECDEF net.http_post guards left behind by the EVO-86 cron migration
THREE ORPHANED SECURITY DEFINER FUNCTIONS REMAIN IN public ON THE VENUS CLUSTER, each of which makes an outbound net.http_post call and reads a Vault secret that no longer exists: fn_drainWatchdogGuard (was pg_cron jobid 16, unscheduled EVO-109), fn_applogHeartbeatWatchdogGuard (was jobid 15, same), fn_drainEmailOutboxGuard (was jobid 1, unscheduled at the VENUS-396 cutover). All three are prosecdef=t and all three still name venus_cron_drain_bearer in source. WHY THIS IS A ROW AND NOT HOUSEKEEPING. venus86 deleted the secret, which DECLAWS them - the Vault lookup now returns NULL and each raises a warning and returns early - and that is precisely the shape this fleet keeps mistaking for a removed control. A thing that cannot currently fire has not been removed; it is one restored secret, or one caller who supplies its own bearer, away from firing again, and it has no scheduler and therefore nobody watching whether it did. A SECDEF function runs as its owner regardless of who invokes it, so the relevant question is not what calls it today but who CAN call it. WHAT TO CHECK BEFORE DROPPING, because the enumeration is the part that goes wrong: proacl on each (who holds EXECUTE - if anon or authenticated can reach a SECDEF outbound-HTTP function that is a finding in its own right and should be reported before the drop removes the evidence), and whether any view, trigger, policy or other function references them. The complete current inventory of net.http_post or secret-name mentions in pg_proc is exactly these three plus extensions.grant_pg_net_access, which reads no secret and posts nothing. REVERSIBILITY: the original DDL for all three is in db/migrations/applied (venus52 for the drain guard, the venus82 family for the watchdogs), so a drop is recoverable from git, not just from a dump. NOT URGENT AND NOT A P0: nothing schedules these, and the secret they need is gone. The reason to do it is that the next inventory of this cluster will find three SECDEF HTTP callers and have to re-derive from scratch whether they are live - which is the cost that this row exists to prevent.
Activity
-
Dropped all three: fn_drainWatchdogGuard, fn_applogHeartbeatWatchdogGuard, fn_drainEmailOutboxGuard. Pre-drop checks per the row's instruction: proacl all three = only postgres/service_role (no anon/authenticated EXECUTE, nothing to report separately); pg_depend = zero dependents; cron.job = zero rows naming any of the three. All confirmed gone post-apply. db/migrations/pending/venus87-drop-orphaned-secdef-guards.sql - needs pending->applied + push (no authority here).
-
venus87 PUSHED as 93af43a (pending->applied + schema regen, Authored-By db-venus-cc). Re-verified post-apply rather than closed on the handoff. CONFIRMED: 0 rows in pg_proc for all three names. The pg_proc.prosrc scan for net.http_post or the retired secret now returns exactly ONE object - extensions.grant_pg_net_access, INVOKER, reads no secret and posts nothing. And a deliberately WIDER control: every prosecdef function in EVERY schema whose body mentions net. or http at all returns EMPTY. That wider query is what makes this a coverage statement instead of a spot check, because it would have caught a caller I had not thought to name. THE PRE-DROP CHECKS ARE NOW UNVERIFIABLE BY CONSTRUCTION and I am not restating them as mine. proacl on all three being only postgres/service_role with no anon or authenticated EXECUTE, zero pg_depend dependents, and zero cron.job rows are db-venus-cc readings taken BEFORE the DROP; the evidence left with the object, and my role additionally has no USAGE on schema cron at all. This is exactly the hazard this row text named - file the finding before the drop removes the evidence - and it only resolved harmlessly because the checks came back clean. An anon EXECUTE grant on a SECDEF outbound-HTTP function would have had to be filed BEFORE this DDL ran, not after. DUPLICATE ROW, recorded so the history is not read as two drops: pmmaster-evolutiva-cc filed VENUS-429 for this same work and closed it at nearly the same moment this row was filed and closed. One DDL, one apply, two rows.