fix(security): harden crawler boundaries - #91
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be5b464ec3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad4351da3f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Il client outbound creava e chiudeva un Agent per ogni richiesta, quindi le centinaia di pagine di uno stesso monitor rifacevano handshake TCP/TLS e risoluzione DNS: con il timeout di 10 minuti del workflow gli scan grandi rischiavano di scadere prima di produrre output. Ora i dispatcher sono pooled per insieme di indirizzi fissati, il DNS è risolto una volta per host e lo scan chiude i pool in un finally. Chiude anche due thread Codex della PR #91: le sitemap duplicate non consumano più il budget di 32 prima di essere deduplicate al dequeue, e la classificazione degli indirizzi copre i prefissi IPv6 non globali e di transizione (Teredo, 6to4, NAT64, ORCHIDv2, SRv6, doc 3fff::/20) più il relay 6to4 IPv4 192.88.99.0/24. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il client outbound creava e chiudeva un Agent per ogni richiesta, quindi le centinaia di pagine di uno stesso monitor rifacevano handshake TCP/TLS e risoluzione DNS: con il timeout di 10 minuti del workflow gli scan grandi rischiavano di scadere prima di produrre output. Ora i dispatcher sono pooled per insieme di indirizzi fissati, il DNS è risolto una volta per host e lo scan chiude i pool in un finally. Chiude anche due thread Codex della PR #91: le sitemap duplicate non consumano più il budget di 32 prima di essere deduplicate al dequeue, e la classificazione degli indirizzi copre i prefissi IPv6 non globali e di transizione (Teredo, 6to4, NAT64, ORCHIDv2, SRv6, doc 3fff::/20) più il relay 6to4 IPv4 192.88.99.0/24. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Cosa cambia
Causa radice
Le fetch di risorse, robots e sitemap applicavano controlli diversi e tardivi; il workflow feedback riconosceva Codex tramite una regex sul login e partiva anche per eventi pubblici non pertinenti.
Verifiche
npm test— 63 test verdinpm run test:coverage— 92,87% linee, 75,81% branchnpm run buildactionlint .github/workflows/codex-pr-comments.ymlnpm audit --audit-level=high— 0 vulnerabilitànpm run sentinel -- scan --dry-run --site sancarlo-sviluppo— 41 URL, 0 problemiNessun deploy o release incluso: runtime operativo e dashboard restano canali separati.