egutierrez
ee0d26ce2d
Cada enricher con `lang: python` y `uses_functions` no vacio ahora
puede empaquetar las funciones del registry que necesita en
`<enricher>/_vendored/`. El run.py importa de ahi en lugar de
`<registry_root>/python/functions/`, lo que hace al binario
distribuible sin dependencia de un fn_registry montado.
Cambios:
1. tools/vendor_enricher_python.sh
- Lee `uses_functions` del manifest (filtrando IDs `*_py_*`).
- Resuelve `file_path` desde registry.db.
- Copia recursivamente con expansion transitiva: si un fichero
vendorizado importa siblings del mismo dominio, los siblings
tambien se copian (resuelve el caso `extract_iocs.py` que
importa 7 modulos hermanos).
- Genera `.vendor.lock` con `<id> <sha256> <src_path>` por
funcion declarada para auditoria.
- Idempotente — si todos los hashes coinciden, no rehace nada.
2. Manifests actualizados con `uses_functions`:
- fetch_webpage: normalize_url + html_to_markdown
- extract_links: extract_urls
- extract_text_entities: extract_iocs
3. run.py de los 3 enrichers afectados: importan de `_vendored/`
si existe, fallback a `<registry_root>/python/functions/` en
modo dev (mantiene los tests pytest funcionando).
4. app.md: anade `cryptography` a python_runtime_deps porque el
blob `cybersecurity.cybersecurity` lo importa al top.
5. Tests:
- test_vendor_script.py — 6 tests del script: layout correcto,
transitive siblings, lock con SHA256, idempotencia, modulos
importables en aislamiento.
- 16 tests de enrichers existentes pasan via vendoring (no usan
registry_root porque _vendored/ tiene prioridad).
6. Issue 0033b movido a issues/completed/.
Tests: 32/32 verde (16 enrichers + 6 dispatcher + 4 runtime + 6
vendor).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
39 lines
1.3 KiB
Markdown
39 lines
1.3 KiB
Markdown
---
|
|
id: 0003
|
|
title: Enricher web — descargar URL/dominio y extraer texto
|
|
status: completed
|
|
priority: medium
|
|
created: 2026-04-30
|
|
---
|
|
|
|
## Objetivo
|
|
|
|
Right-click sobre un nodo `url` o `domain` → "Run enricher → Fetch & extract
|
|
text". Descarga el HTML, extrae el texto principal, crea un nodo `text`
|
|
conectado al origen con relacion `FETCHED_FROM`.
|
|
|
|
Despues el usuario puede encadenar: sobre ese nodo `text`, ejecutar el enricher
|
|
GLiNER+GLiREL (issue 0002) para extraer entidades.
|
|
|
|
## Alcance
|
|
|
|
- HTTP GET con timeout (libcurl o sys WinHTTP).
|
|
- Extraccion de texto: regex/strip de tags simple en v1; v2 usa una lib
|
|
(htmlparser2 / lexbor / boost.url + algo de heuristica).
|
|
- User-agent identificativo, respeto de robots.txt opcional (out-of-scope v1).
|
|
- Limite de tamaño descargable (1 MB) para evitar bloqueos.
|
|
|
|
## Modelo de etiquetado
|
|
|
|
- Nodo origen (url/domain) → arista `FETCHED_FROM` → nodo nuevo (text con
|
|
metadata={fetched_at, status_code, content_type, length}).
|
|
- Nombre del nodo text: titulo de la pagina (si <title> existe) o primeros
|
|
120 caracteres del cuerpo.
|
|
|
|
## Definicion de hecho
|
|
|
|
- Funciona contra una URL real (https con TLS).
|
|
- Maneja errores (404, timeout, redirects basicos) sin tumbar la app.
|
|
- El nodo creado es visible y el texto se puede consumir por el enricher
|
|
GLiNER+GLiREL del issue 0002.
|