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>
2.2 KiB
id, title, status, priority, created, completed, depends_on
| id | title | status | priority | created | completed | depends_on | |
|---|---|---|---|---|---|---|---|
| 0033b | Vendoring de funciones Python por enricher | completed | high | 2026-05-02 | 2026-05-03 |
|
Objetivo
Para que el .exe Windows sea portable a cualquier PC, los enrichers
con lang: python no pueden importar de <registry_root>/python/functions/
en runtime. Cada enricher copia las funciones del registry que
declara en uses_functions a <enricher>/_vendored/ durante el
build, y run.py importa de ahi.
Implementacion
1. Script tools/vendor_enricher_python.sh
Recibe <enricher_dir> y <registry_root>. Lee uses_functions del
manifest, filtra los IDs *_py_*, resuelve file_path desde
registry.db, copia el .py a _vendored/<domain>/<name>.py y
crea __init__.py por dominio. Genera .vendor.lock con
<id> <sha256> <src_path> por linea. Idempotente: si el sha256 de
origen coincide con el del lock, no copia.
2. Adaptacion de run.py
Cada enricher con lang: python que use funciones del registry
cambia el import:
# antes
sys.path.insert(0, os.path.join(registry_root, "python", "functions"))
from cybersecurity.cybersecurity import normalize_url
# despues
sys.path.insert(0, os.path.join(os.path.dirname(__file__), "_vendored"))
from cybersecurity.normalize_url import normalize_url
3. .gitignore
Anadir _vendored/ y .vendor.lock al .gitignore del repo (o de
cada app). Son artefactos de build, regenerables.
4. Hook al build
/compile (o el script de freeze del 0033) recorre
apps/<app>/enrichers/*/manifest.yaml. Para cada manifest con
lang: python, ejecuta vendor_enricher_python.sh.
Tests
- Test unit del script bash: dado un manifest con dos
uses_functionsPython conocidas, verificar que_vendored/queda con la estructura correcta y.vendor.locklista los hashes. - Test e2e:
fetch_webpage(lang: python) ejecuta correctamente con registry_root vacio en el ctx tras vendoring.
Definicion de hecho
tools/vendor_enricher_python.shexiste y es idempotente.- Cada enricher Python del proyecto tiene
_vendored/poblado y funciona sinregistry_rooten runtime. - El binario zippeado a Desktop arranca enrichers Python sin acceso al fn_registry.