Saltar al contenido
Aegis Latent Core

Proyecto

Changelog: historial de versiones verificables

Cada entrada corresponde a un release publicado y leído de vuelta (GitHub Release, PyPI, npm, GHCR, cosign, attestations). Las mediciones son de la versión indicada; ninguna se re-ejecuta para releases solo de versión. Formato basado en Keep a Changelog 1.1.0 y SemVer 2.0.0.

v5.0.2(2026-10-01)

Cambio de licencia de AGPLv3 a Apache-2.0. Todos los archivos de primera parte llevan cabecera SPDX. Metadatos de paquetes declaran Apache-2.0. LICENSE y NOTICE viajan con cada distribución (sdist, wheel, imágenes OCI). Política de dependencias: copyleft fuerte = bloqueante para artefacto Apache-2.0.

docs/legal/LICENSE_TRANSITION_5.0.2.mdCLM-122

Licencia

  • LICENSE es ahora el texto literal de Apache-2.0 (SHA-256 cfc7749b…c523d30)
  • NOTICE lleva atribución Section 4(d), puntero de licencia y reserva de marca Section 6
  • AGPLv3 y grant 'AGPLv3 o comercial' eliminados del árbol de fuentes
  • Cabecera de tres líneas (SPDX-License-Identifier: Apache-2.0) en cada archivo de primera parte
  • Metadatos de paquetes declaran Apache-2.0 (PEP 639, Cargo, npm)
  • LICENSE y NOTICE copiados a sdk/python/, sdk/typescript/, /licenses/ en imágenes
  • Escáner de licencias: GPL/AGPL = bloqueante, UNKNOWN = bloqueante
  • Lo que se vende cambia: COMMERCIAL.md describe servicios, no segunda licencia

Versión

  • Catorce anclas de release, Cargo.lock, crate envoy-wasm, etiquetas de imagen y literales de despliegue leen 5.0.2
  • Despliegues por defecto (ghcr.io/juanlunaia/aegis-latent-core:5.0.2) no resuelven hasta que la imagen se publique
  • Gate de vigencia documental trata 5.0.1 como baseline superado
  • Ningún path de runtime cambió salvo cadenas de versión, cabeceras, docstrings y un mensaje de error del motor de licencias reescrito

v5.0.1(2026-09-24)

Publicado 2026-09-24 en GitHub Release (31 assets, SHA256SUMS sweep 15/15), PyPI y npm aegis-latent-sdk 5.0.1, GHCR gateway y dashboard. PyPI aegis-latent-core siguió el 2026-09-26. Gatekeeper: HALTED → resuelto en PR #205.

docs/RELEASE_STATUS.md §1.0aRELEASE_HALTED_CRITICAL_ERRORS.mdRELEASE_READINESS_v5.0.1.md

Añadido — Operación multi-réplica (AD-17, CLM-108)

  • AEGIS_HA_MODE: active_passive (Redis writer lease con época monotónica) y active_active (cada réplica su cadena, secuencia global en PostgreSQL con compare-and-append + epoch fence)
  • python -m aegis.core.ha verify re-deriva la secuencia y verifica cada WAL
  • Arranque y Helm chart rechazan formas que bifurcarían evidencia
  • Guía de operador: docs/operations/HIGH_AVAILABILITY.md
  • Test de humo de contenedor (scripts/container_smoke_test.py): postura endurecida, seccomp kill-mode, AppArmor, root read-only, sin capabilities, upstream HTTPS por hostname

Añadido — Preparación para auditoría

  • docs/compliance/AUDIT_READINESS.md: procedimiento y matrices de control para SOC 2, HIPAA §164.312, ISO/IEC 27001:2022 Annex A, EU AI Act, MiFID II/MiFIR
  • Recopilador de evidencia (scripts/collect_audit_evidence.py, solo stdlib): health, readiness, /metrics, integridad auditoría, reportes de capacidad, SHA256SUMS
  • python -m aegis.auth.principal genera AEGIS_API_KEY_PRINCIPALS_JSON desde claves en stdin
  • docs/MAINTAINER_HANDBOOK.md: acceso a transfer, build, gates, orden de release, depósito escrow

Corregido — Remediación hallazgos gatekeeper (PR #205)

  • Seccomp P0: REG-D67 (io_uring_enter en host bare), REG-D68 (filtro saltado en Docker), REG-D78 (imagen matada en primer request a host nombrado), REG-D83 (ctypes.find_library corría ldconfig; AppArmor lo denegaba)
  • Seccomp P1: REG-D82 (hilos pre-lockdown), REG-D84 (parada grácil terminaba en SIGSYS)
  • Cadena de suministro: REG-D69 (imágenes instalan hash-pinned lock), REG-D70 (cachetools añadido al lock), REG-D86 (prometheus-client añadido, AppArmor permite su collector)
  • Despliegue: REG-D79 (URL backend …/v1 producía /v1/v1/…), REG-D80 (AppArmor bloqueaba WAL e intérprete), REG-D81 (compose endurecido no arrancaba strict)
  • Severidad menor: REG-D73 (excepciones → JSON 500), REG-D74 ([all] no instala toolchain dev), REG-D75 (bind loopback por defecto sin auth), REG-D60 (variables ejemplo eliminadas con test guard), REG-D026 (mypy --strict aegis_server limpio), REG-D03 (chacha20 0.10.2), REG-D85 (tests módulos leak real-time), REG-D87 (SQLite sequence store retry busy timeout)
  • Cita MiFID: Directive 2014/65/EU Art. 16(6)/(7) y MiFIR Art. 25(1), confirmación de counsel recomendada

Seguridad

  • prometheus-client 0.26.0 (Apache-2.0 AND BSD-2-Clause) entra al lock runtime
  • pip-audit --require-hashes: 0 vulnerabilidades conocidas en 37 paquetes lock

v5.0.0(2026-09-16)

Publicado 2026-09-16: tag firmado c34d412 en commit b2e4335, GitHub Release 31 assets, PyPI y npm aegis-latent-sdk 5.0.0, ambas imágenes GHCR. PyPI aegis-latent-core NO publicado (sigue en 4.1.2). 4.4.0 y 4.2.0 no existen (saltados deliberadamente). Salto 4.3.0 → 5.0.0 = cambio rompiente API JSON (signature_assurance reemplaza legal_admissibility).

docs/RELEASE_STATUS.md §1.0

Corregido — Cuatro hallazgos que tres auditorías independientes coincidieron

  • Normalización WAF Capa 2 (CLM-093): Layer 1 plegaba confusables cirílicos/griegos a ASCII antes de match; Layer 2 recibía _extract_text output y lo puntuaba raw. Ahora AegisWAF._guard_variants alimenta Layer 2 con texto raw PRIMERO, luego cada variante normalizada.
  • Control de admisión streaming (CLM-094): StreamAdmissionGate limita streams concurrentes en AEGIS_MAX_CONCURRENT_STREAMS (default 256) y rechaza con 429 en lugar de encolar. Slot atado al lifetime del generador, no al handler.
  • Manifiesto de bundle forense firmado (CLM-095): VERIFY.sh comparaba archivos contra digests incrustados en el propio VERIFY.sh (círculo). Firma Ed25519 opt-in sobre manifest.json exacto rompe el círculo. La clave pública NO viaja en el archivo.
  • Verificación CMS RFC 3161 (CLM-096): verify aceptaba cualquier token con tag DER SEQUENCE exterior. Ahora verifica firma sobre signedAttrs re-codificado, binding messageDigest→TSTInfo, messageImprint contra digest esperado, y ventana de validez contra anclas del llamador. Sin comprobación de revocación (necesita red).

Cambiado — Tres correcciones prescritas rediseñadas en lugar de aplicadas

  • timestamp: float → int microsegundos NO aplicado: floats nunca llegan a serializador JCS float (_jcs_bytes los rechaza), y hoja MMR formatea timestamp como f"{…:.9f}" determinista cross-language. El cambio alteraría cada hash hoja, root, firma y prueba por cero ganancia de determinismo, y contradice UPGRADING.md §6 promesa de identidad de byte.
  • Buffer de staging group-commit NO construido: el append ocurre bajo lock; staging serializa eso y cuesta el coalescing. El invariante real (ningún caller escucha 'durable' cuando no lo es, y los latches de fallo) ahora fijado por TestWhatAFsyncFailureLeavesBehind. Trabajo también estableció que registros rechazados SÍ están en el archivo WAL: bytes escritos antes del fsync que falló.
  • "Migración v1 → v2" reemplazada por anclaje cruzado: un root es su construcción; recomputar hojas v1 bajo v2 da root que ningún verificador jamás vio y rompe toda prueba emitida. tools/anchor_v1_chain_into_v2.py registra dónde terminó la cadena v1 y la deja byte-por-byte intacta.

Añadido — Guía bloqueos NFS/EFS y registro disposición comercial

  • docs/operations/STORAGE_REQUIREMENTS.md: ya avisaba contra FS de red por fsync; ahora también documenta fallo independiente flock/lockd: pod muerto sin gracia no libera lock WAL, servidor lo retiene hasta timeout reclaim, pod reemplazo entra en CrashLoopBackOff que se resuelve solo minutos después — propiedad de almacenamiento rutinariamente archivada como race del gateway.
  • docs/commercial/COMMERCIAL_READINESS.md: registra seis acciones que ningún agente puede realizar — pen test, SOC 2, escrow, licencia comercial, design partners, segundo maintainer — cada una marcada NOT STARTED, con test de aceptación para segundo maintainer = fix de seguridad enviado end-to-end SIN el fundador.

Releases históricos (readback verificado)

v5.0.1

2026-09-24

Superficies: GitHub Release, PyPI SDK, npm SDK, GHCR gateway, GHCR dashboard

Nota: PyPI gateway siguió 2026-09-26

Readback: Tag b590a7f, 31 assets, SHA256SUMS 15/15, cosign verify ambos GHCR, attestations verificadas

v5.0.0

2026-09-16

Superficies: GitHub Release, PyPI SDK, npm SDK, GHCR gateway, GHCR dashboard

Nota: PyPI gateway NO publicado (sigue 4.1.2)

Readback: Tag c34d412, 31 assets, cosign verify GHCR, attestations verificadas

v4.1.2

2026-09-04

Superficies: GitHub Release, PyPI gateway, PyPI SDK, npm SDK, GHCR gateway, GHCR dashboard

Nota: Primer release con gateway en PyPI

Readback: Tag 860f141, 31 assets, PyPI gateway 4.1.2 (byte-diferente a release assets), cosign GHCR

v4.0.2

2026-09-02

Superficies: GitHub Release, GHCR gateway, GHCR dashboard

Nota: SDK publish jobs saltados

Readback: Tag a6eb58d, GHCR imágenes readback

v4.0.1

2026-08-XX

Superficies: GitHub Release (fallido)

Nota: Lightweight tag, workflows fallidos

Readback: Tag 6469904, registries observadas en 4.0.0 sin proveniencia atribuida

v4.0.0

2026-08-XX

Superficies: Registries

Nota: Baseline inmutable: fdace884 (catorce anclas 4.0.0)

Readback: Sin proveniencia atribuida

Cómo verificar un release

Cada release publicado genera artefactos verificables independientemente. No confíe en metadatos de versión del código fuente: lea de vuelta los registros externos.

01

GitHub Release

gh release view v5.0.2 --json assets,tagName,createdAt

Ver tag, assets (31 esperados), fecha y SHA256SUMS

02

SHA256SUMS

curl -fsSL https://github.com/JuanLunaIA/aegis-latent-core/releases/download/v5.0.2/SHA256SUMS | sha256sum -c --ignore-missing

Verifica integridad de todos los 15 assets del release

03

PyPI

curl -fsSL https://pypi.org/pypi/aegis-latent-core/5.0.2/json | jq '.files[].digests.sha256'

Compara digests PyPI contra SHA256SUMS del release

04

GHCR + cosign

cosign verify ghcr.io/juanlunaia/aegis-latent-core:5.0.2 --certificate-identity-regexp '.*' --certificate-oidc-issuer-regexp '.*'

Verifica firma y attestation de procedencia contra workflow identity exacto

05

npm

npm view aegis-latent-sdk@5.0.2 dist.integrity

Compara integrity npm contra SHA256SUMS

06

Verificador offline

python prove_it.py ledger.json <root-hash>

Valida integridad criptográfica del ledger exportado (313 líneas Python / gemelo TS)

Enlaces de referencia

RELEASE_STATUS.md

Estado de publicación por superficie y fecha de readback

Abrir

CLAIMS_MATRIX.md

Matriz controlada de afirmaciones públicas

Abrir

REGISTRY.md

Registro maestro de defectos, evidencias y disposición

Abrir

RELEASE_HALTED_CRITICAL_ERRORS.md

Informe de parada del gatekeeper 2026-09-24

Abrir

RELEASE_READINESS_v5.0.1.md

Evidencia de remediación item por item

Abrir

UPGRADING.md

Notas de migración por versión (breaking changes)

Abrir

BENCHMARKS.md

Mediciones reales con límites declarados

Abrir

FORMAL_VERIFICATION.md

Artefactos formales (Lean, Z3, TLA+) y sus límites

Abrir
Siguiente paso
Fuente

El código de Aegis está disponible en PyPI y GHCR, con verificación de integridad mediante hashes SHA-256 y firmas digitales. No necesita GitHub para evaluar o desplegar.

← Volver al inicioTodo el proyecto →