add slack bot

[amyliiu]

• Add a Slack Events webhook (/api/slack/events) so organizers can @mention a bot and ask natural-language questions about dashboard Postgres (read-only SQL via Drizzle).
• Restrict access to Slack users whose email matches a users row with role organizer; skip session auth for /api/slack.
• Wire Slack/OpenAI secrets into ECS (task-definition.json) and document app setup, env vars, and local tunneling in docs/slack.md.

[hujalex]

Automated code review (medium effort). 10 findings, most severe first. Verified as non-issues: signature verification (constant-time, length-checked, 5-minute skew), the intentional /api/slack middleware bypass, SET LOCAL transaction_read_only = on after a prior SET, the ai/@ai-sdk/openai lockfile resolution, and the hasSeenEvent LRU eviction.

[hujalex]

Wait, looks good to me, only thing is wondering if the keys are in the prod environment

[HangYeung1]

fragile to schema updates. can this be a simple query for schema instead

[HangYeung1]

this isn't safe. can we do something tighter like a read only posgres role that the orm temp assumes?

[HangYeung1]

is there a slack sdk or something. this feels a bit brute.

[pradhamk]

1. Please use Slack SDK for typescript so the bot can be reusable in the future and is resilient against api changes from slack
2. Query the general schema of each table in schema-prompt.ts rather than defining each table manually (this will break easily if we make a table change during the hackathon). Instead, just whitelist the columns that the bot can read maybe? (we will never remove columns, only add during the event)
3. Unsafe transactions are a big no-no in sql.ts. Should be able to use safe transactions here and be fine since we are only doing reads.

Security Issues:

1. SQL allowlist bypass via derived-table subquery — lib/slack/sql.ts:341

• Severity: High
• Category: authorization_bypass / sql_scope_bypass
• Confidence: 9/10

Description: validateReadonlySelect() is the only thing constraining LLM-authored SQL before it is executed with tx.unsafe() on the application's privileged Postgres connection (lib/slack/sql.ts:447-451, pool from lib/db/index.ts:17). Its table allowlist is applied by extractTableNames(), which scans for from/join word tokens — but when a from/join is immediately followed by (, it calls skipParens() and advances the loop index past the closing parenthesis (lib/slack/sql.ts:341-348). Every token inside a derived table is therefore never examined: neither ALLOWED_TABLES (lib/slack/sql.ts:124-129) nor the public-only schema check in parseQualifiedName() (lib/slack/sql.ts:380-382) is reached. SELECT * FROM (SELECT * FROM auth.users) AS q passes validation. The same applies to JOIN (…) and to nesting inside CTE bodies. Note the non-derived forms are caught — SELECT (SELECT count(*) FROM auth.users) FROM users correctly throws — so the control looks like it works while being inert for the most natural subquery shape.

2. SQL allowlist bypass via query-taking XML built-ins — lib/slack/sql.ts:48

• Severity: High
• Category: authorization_bypass / sql_scope_bypass
• Confidence: 9/10

Description: tokenizeSql() reduces every string literal to a contentless { type: "string" } token with no value field (lib/slack/sql.ts:226; same for dollar-quoted strings at lib/slack/sql.ts:174-184), so nothing inside a literal is ever inspected. Postgres ships built-ins that take a SQL string or a regclass and execute it under the caller's privileges, and FORBIDDEN_FUNCS (lib/slack/sql.ts:48-56) does not list any of them. SELECT query_to_xml('SELECT * FROM auth.users', true, false, '') contains no from/join token outside the literal, so extractTableNames() returns [] and the allowlist loop never executes at all. checkForbidden() sees only select, query_to_xml, true, false. The outer wrapper SELECT * FROM () AS q LIMIT 25 is valid around a FROM-less select, and is appended after validation so it cannot re-trigger the scanner.

[amyliiu]

@pradhamk addressed in ac40d83:

1. Slack Node SDK: request verification now uses @slack/bolt (isValidSlackRequest), events use @slack/types (AppMentionEvent), and the Web API client stays on @slack/web-api.
2. Schema prompt is built from information_schema.columns for the allowlisted tables so added columns show up without a manual prompt edit.
3. SET LOCAL runs as tagged-template queries. The validated SELECT still has to go through unsafe because postgres.js cannot interpolate a whole statement into a tagged template.

Security: extractTableNames now walks derived-table / subquery parens after FROM/JOIN, and query-taking XML / dblink-style functions are on the forbidden list.