Addressing Issues

[linear-code]

[linear-code]

GRV-423

[github-actions]

👋 Thanks for opening this issue! It has been automatically labeled for triage.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Addressing Issues #413

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Fix the critical security defects first, because pickle RCE (SEC-001) and the XSS vector (SEC-003) can break production or expose users.
• Finish the VERA production wiring next, because the security framework exists but does not run at runtime without the middleware and persistent stores.
• Resolve the verified launch blockers last, because they block real payments and Pro features.
• Use the repository's own audit documents as the source of truth, and ignore the stale template backlogs whose deliverables already exist.

Design Choices

Design Choice 1: Scope of "Addressing Issues"

Options Considered:

1. Address the P0/P1 security findings in docs/analysis/REMEDIATION_PLAN.md and SECURITY_REPORT.md.
2. Address the launch blockers in LAUNCH_CHECKLIST.md (Stripe live cutover, Upstash verification, backend deploy).
3. Address the VERA production-wiring gaps in docs/VERA_AUDIT_REPORT.md.
4. Re-run the recurring PR-remediation runbook (docs/triage/pr-remediation-*.md).

Chosen Option: 1

Rationale: The ticket body contains only output-format instructions and does not name specific issues. The repository contains several backlogs, and some are stale. Combine options 1, 2, and 3, ordered by production risk: fix the critical security defects first, then the remaining VERA production wiring, then the verified launch blockers. Exclude option 4 because it is a report-only PR-hygiene process, not a code-change task. Exclude the stale template backlogs (.github/ISSUE_TEMPLATE/phase-*, cleanup-plan.md) because their deliverables already exist in the codebase.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Critical Security Remediation

Remove defects that can break production or allow remote code execution. These are the highest-priority items (P0) in docs/analysis/REMEDIATION_PLAN.md. Fix these first. Do not defer them.

Task 1: Remove insecure pickle deserialization (SEC-001, CVSS 9.8)

The cache reads untrusted Redis data with pickle.loads. An attacker who can write to Redis can run arbitrary code. This is the most dangerous defect in the repository.

• Update src/youtube_extension/backend/services/intelligent_cache.py (around the pickle.loads(data) call at line ~285).
• Replace pickle serialization and deserialization with JSON for all cache payloads. Prefer JSON because cache values are data, not code.
• If any cached object is not JSON-serializable, convert it to a plain dict or dataclass before caching, and reconstruct it on read.
• Verify no other module calls pickle.loads on external or Redis-sourced data. Search the backend for pickle.loads and pickle.load.

Task 2: Resolve NPM dependency vulnerabilities (SEC-002)

The web app depends on packages with 31 known vulnerabilities (6 high). Vulnerable transitive dependencies can break builds and expose the frontend.

• Update dependencies in apps/web/package.json and frontend/package.json (whichever declare the affected packages: @ai-sdk/anthropic, @ai-sdk/google, @ai-sdk/openai, @svgr/plugin-svgo, nanoid, react-scripts).
• Run npm audit fix first. For advisories that npm audit fix cannot resolve, upgrade the direct dependency to a patched major version and adjust breaking API usage.
• Confirm the build passes after upgrades. Do not use --force blindly, because it can install breaking major versions without review.

Task 3: Remove XSS via dangerouslySetInnerHTML (SEC-003)

The component injects a function .toString() into an inline <script> tag. This is a stored/DOM XSS vector.

• Update frontend/src/components/LearningFusion.tsx (around line 429).
• Move the injected logic into a normal, statically-bundled module or component method. Remove the inline <script> and the dangerouslySetInnerHTML usage.
• Add the ESLint rule react/no-danger to the frontend ESLint config to prevent regressions.
• If the injected logic needs test coverage, move it into a testable function and add a Jest test.

🤖 Prompt for AI agents

Implement Phase 1: Critical Security Remediation. Goal: eliminate the
highest-risk (P0) security defects that can break production or allow remote
code execution, before any other work.

1. Fix SEC-001 (pickle RCE, CVSS 9.8): In
`src/youtube_extension/backend/services/intelligent_cache.py`, locate the
`pickle.loads(data)` call (around line ~285). Replace pickle-based
serialization/deserialization with JSON for all cache payloads. If a cached
object is not JSON-serializable, convert it to a plain dict or dataclass before
caching and reconstruct it on read. Search the entire backend codebase for any
other `pickle.loads`/`pickle.load` calls that operate on external or
Redis-sourced data and remove them.

2. Fix SEC-002 (NPM vulnerabilities): In `apps/web/package.json` and
`frontend/package.json`, identify which package declares each vulnerable
dependency (`@ai-sdk/anthropic`, `@ai-sdk/google`, `@ai-sdk/openai`,
`@svgr/plugin-svgo`, `nanoid`, `react-scripts`). Run `npm audit fix` first. For
remaining advisories, upgrade the direct dependency to a patched major version
and adjust any breaking API usage caused by the upgrade. Confirm the build still
passes. Do not blindly use `--force`.

3. Fix SEC-003 (XSS): In `frontend/src/components/LearningFusion.tsx` (around
line 429), remove the inline `<script>` tag and the `dangerouslySetInnerHTML`
usage that injects a function's `.toString()` output. Move that logic into a
normal, statically-bundled module or component method instead. Add the
`react/no-danger` ESLint rule to the frontend ESLint config to prevent
regressions. If the moved logic needs test coverage, extract it into a testable
function and add a Jest test for it.

Phase 2: Security Hardening and VERA Production Wiring

Close the high-severity input-handling gap and finish the VERA framework so its protections work in production, not only in development. The VERA modules exist but are not fully wired, so the protections do not run at runtime.

Task 1: Validate subprocess inputs (SEC-004)

There are 23 subprocess calls that accept external input. They use array-style calls without shell=True, so injection risk is reduced, but the input sources are not audited or allowlisted.

• Audit subprocess calls in src/agents/mcp_tools/build_validator_tool.py, src/agents/mcp_tools/deployment_tool.py, src/youtube_extension/cli.py, src/youtube_extension/backend/services/video_processing_service.py, deployment_manager.py, and revenue_pipeline.py.
• For each call, identify the input source. If an argument comes from user input or a network source, validate it against an allowlist (for example, known binary names, known file extensions, or a fixed set of commands).
• Reject any input that fails validation before the subprocess call. Raise a clear error.
• Keep array-style invocation. Never introduce shell=True.

Task 2: Wire VERA firewall middleware and status endpoint

The VERA audit reports that VeraFirewallMiddleware is not attached to the app and /vera/status is not exposed. Without the middleware, the input firewall does not run in production.

• Update the FastAPI app startup (the canonical main.py that serves the backend) to attach VeraFirewallMiddleware from src/vera/middleware.py.
• Add a /vera/status API endpoint that returns the output of vera/middleware.py::vera_status_dict().
• Confirm the middleware runs on request paths and does not break existing routes. Add a startup log line that confirms VERA is active.

Task 3: Enable VERA persistent state (Postgres and Redis)

Proof chains and circuit-breaker state are in-process only. On restart or across instances, state is lost. This weakens the tamper-evident logging and the kill switch in production.

• Configure the VERA proof-chain store (src/vera/proof_chain.py) to persist to PostgreSQL. Apply the existing migration supabase/migrations/002_vera_tables.sql.
• Configure the circuit-breaker/enforcement state (src/vera/enforcement.py / enforcer.py) to share state through Redis.
• Read connection settings from environment variables. If a store is not configured, keep the in-process fallback but log a clear warning at startup, because production must use the persistent stores.

🤖 Prompt for AI agents

Implement Phase 2: Security Hardening and VERA Production Wiring. Goal: close
the remaining high-severity input-handling gap and finish wiring the VERA
security framework so its protections actually run in production, not just in
development.

1. Fix SEC-004 (subprocess input validation): Audit the 23 subprocess calls that
accept external input across `src/agents/mcp_tools/build_validator_tool.py`,
`src/agents/mcp_tools/deployment_tool.py`, `src/youtube_extension/cli.py`,
`src/youtube_extension/backend/services/video_processing_service.py`,
`deployment_manager.py`, and `revenue_pipeline.py`. For each call, determine
whether any argument originates from user input or a network source. For those,
add allowlist validation (e.g., known binary names, known file extensions, or a
fixed set of commands) before the subprocess call, and reject/raise a clear
error on any input that fails validation. Keep all calls in array style; do not
introduce `shell=True` anywhere.

2. Wire the VERA firewall middleware: In the canonical backend `main.py`
(FastAPI app startup), attach `VeraFirewallMiddleware` from
`src/vera/middleware.py`. Add a new `/vera/status` API endpoint that returns the
output of `vera/middleware.py::vera_status_dict()`. Confirm the middleware runs
on request paths without breaking existing routes, and add a startup log line
confirming VERA is active.

3. Enable VERA persistent state: Configure `src/vera/proof_chain.py` to persist
proof-chain data to PostgreSQL, applying the existing migration
`supabase/migrations/002_vera_tables.sql`. Configure
`src/vera/enforcement.py`/`enforcer.py` to share circuit-breaker/enforcement
state through Redis. Read all connection settings from environment variables. If
a store is not configured, keep the in-process fallback behavior but log a clear
startup warning, since production deployments must use the persistent stores.

Phase 3: Launch Blocker Verification

Resolve the live production blockers listed in LAUNCH_CHECKLIST.md. These items block real revenue and real Pro features. Treat them as production defects, not enhancements.

Task 1: Complete Stripe live cutover

Stripe runs in TEST mode. The claimed LIVE price IDs return No such price. Checkout cannot take real payments.

• Create LIVE Stripe products and prices. Record the LIVE price IDs.
• Set the LIVE secret key (sk_live_) and the LIVE webhook signing secret (whsec_) in the deployment environment (Vercel).
• Reconcile the mismatched price IDs in apps/web/.env.local with the LIVE values so local and deployed configs agree.
• Verify a live checkout completes and the webhook is received and verified.

Task 2: Verify Upstash Redis durable entitlements

The entitlement code is correct but unverified in production. assertEntitlementDurability() throws on boot if the credentials are missing.

• Confirm the Upstash Redis credentials are injected in the Vercel environment.
• Confirm assertEntitlementDurability() passes at boot in the deployed environment.
• If the credentials are missing, add them to the deployment environment and redeploy.

Task 3: Deploy the FastAPI backend for agent dispatch

The Pro agent-dispatch feature calls the FastAPI backend, which is not deployed by default. /api/agents/dispatch returns 503.

• Deploy the FastAPI backend so /api/agents/dispatch is reachable.
• Set BACKEND_URL in the web app environment to the deployed backend URL.
• Verify a dispatch request returns a success response instead of 503.

🤖 Prompt for AI agents

Implement Phase 3: Launch Blocker Verification. Goal: resolve the live
production blockers in `LAUNCH_CHECKLIST.md` that block real revenue and real
Pro features. Treat these as production defects.

1. Complete Stripe live cutover: Create LIVE Stripe products and prices and
record the LIVE price IDs. Set the LIVE secret key (`sk_live_`) and LIVE webhook
signing secret (`whsec_`) in the Vercel deployment environment. Reconcile the
mismatched price IDs in `apps/web/.env.local` with the LIVE values so local and
deployed configs match. Verify a live checkout completes end-to-end and the
webhook is received and verified.

2. Verify Upstash Redis durable entitlements: Confirm the Upstash Redis
credentials are injected into the Vercel environment. Confirm
`assertEntitlementDurability()` passes at boot in the deployed environment. If
credentials are missing, add them to the deployment environment and redeploy.

3. Deploy the FastAPI backend for agent dispatch: Deploy the FastAPI backend so
`/api/agents/dispatch` is reachable instead of returning 503. Set `BACKEND_URL`
in the web app environment to point to the deployed backend URL. Verify a
dispatch request returns a success response.

Research

EventRelay is a hybrid monorepo. The Python backend lives under src/youtube_extension/backend/ and src/, the web app lives under apps/web/ and frontend/, and a Zero-Trust security layer lives under src/vera/.

The repository has a mature audit trail. docs/analysis/REMEDIATION_PLAN.md and docs/analysis/SECURITY_REPORT.md list scored security findings (SEC-001 to SEC-005). docs/VERA_AUDIT_REPORT.md lists remaining production-wiring gaps for the VERA framework. LAUNCH_CHECKLIST.md (the most recent authoritative status document, verified 2026-07-14) lists live launch blockers. This plan uses those documents as the source of truth for the work to do.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: Critical Security Remediation. Goal: eliminate the
highest-risk (P0) security defects that can break production or allow remote
code execution, before any other work.

1. Fix SEC-001 (pickle RCE, CVSS 9.8): In
`src/youtube_extension/backend/services/intelligent_cache.py`, locate the
`pickle.loads(data)` call (around line ~285). Replace pickle-based
serialization/deserialization with JSON for all cache payloads. If a cached
object is not JSON-serializable, convert it to a plain dict or dataclass before
caching and reconstruct it on read. Search the entire backend codebase for any
other `pickle.loads`/`pickle.load` calls that operate on external or
Redis-sourced data and remove them.

2. Fix SEC-002 (NPM vulnerabilities): In `apps/web/package.json` and
`frontend/package.json`, identify which package declares each vulnerable
dependency (`@ai-sdk/anthropic`, `@ai-sdk/google`, `@ai-sdk/openai`,
`@svgr/plugin-svgo`, `nanoid`, `react-scripts`). Run `npm audit fix` first. For
remaining advisories, upgrade the direct dependency to a patched major version
and adjust any breaking API usage caused by the upgrade. Confirm the build still
passes. Do not blindly use `--force`.

3. Fix SEC-003 (XSS): In `frontend/src/components/LearningFusion.tsx` (around
line 429), remove the inline `<script>` tag and the `dangerouslySetInnerHTML`
usage that injects a function's `.toString()` output. Move that logic into a
normal, statically-bundled module or component method instead. Add the
`react/no-danger` ESLint rule to the frontend ESLint config to prevent
regressions. If the moved logic needs test coverage, extract it into a testable
function and add a Jest test for it.
===============================================================================

Task: 2

Implement Phase 2: Security Hardening and VERA Production Wiring. Goal: close
the remaining high-severity input-handling gap and finish wiring the VERA
security framework so its protections actually run in production, not just in
development.

1. Fix SEC-004 (subprocess input validation): Audit the 23 subprocess calls that
accept external input across `src/agents/mcp_tools/build_validator_tool.py`,
`src/agents/mcp_tools/deployment_tool.py`, `src/youtube_extension/cli.py`,
`src/youtube_extension/backend/services/video_processing_service.py`,
`deployment_manager.py`, and `revenue_pipeline.py`. For each call, determine
whether any argument originates from user input or a network source. For those,
add allowlist validation (e.g., known binary names, known file extensions, or a
fixed set of commands) before the subprocess call, and reject/raise a clear
error on any input that fails validation. Keep all calls in array style; do not
introduce `shell=True` anywhere.

2. Wire the VERA firewall middleware: In the canonical backend `main.py`
(FastAPI app startup), attach `VeraFirewallMiddleware` from
`src/vera/middleware.py`. Add a new `/vera/status` API endpoint that returns the
output of `vera/middleware.py::vera_status_dict()`. Confirm the middleware runs
on request paths without breaking existing routes, and add a startup log line
confirming VERA is active.

3. Enable VERA persistent state: Configure `src/vera/proof_chain.py` to persist
proof-chain data to PostgreSQL, applying the existing migration
`supabase/migrations/002_vera_tables.sql`. Configure
`src/vera/enforcement.py`/`enforcer.py` to share circuit-breaker/enforcement
state through Redis. Read all connection settings from environment variables. If
a store is not configured, keep the in-process fallback behavior but log a clear
startup warning, since production deployments must use the persistent stores.
===============================================================================

Task: 3

Implement Phase 3: Launch Blocker Verification. Goal: resolve the live
production blockers in `LAUNCH_CHECKLIST.md` that block real revenue and real
Pro features. Treat these as production defects.

1. Complete Stripe live cutover: Create LIVE Stripe products and prices and
record the LIVE price IDs. Set the LIVE secret key (`sk_live_`) and LIVE webhook
signing secret (`whsec_`) in the Vercel deployment environment. Reconcile the
mismatched price IDs in `apps/web/.env.local` with the LIVE values so local and
deployed configs match. Verify a live checkout completes end-to-end and the
webhook is received and verified.

2. Verify Upstash Redis durable entitlements: Confirm the Upstash Redis
credentials are injected into the Vercel environment. Confirm
`assertEntitlementDurability()` passes at boot in the deployed environment. If
credentials are missing, add them to the deployment environment and redeploy.

3. Deploy the FastAPI backend for agent dispatch: Deploy the FastAPI backend so
`/api/agents/dispatch` is reachable instead of returning 503. Set `BACKEND_URL`
in the web app environment to point to the deployed backend URL. Verify a
dispatch request returns a success response.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---