The vectors of Go are regenerated on datekeys-go 69dbb0c: only the cases
of those checks change. The writer of the extension refuses a DateKey of a
profile that is not pinned.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ -4,6 +4,11 @@ Cambios notables de la librería TypeScript y de la página. El proyecto usa ver
## Especificación 0.10, en la rama `v0.10` — sin versión
### El localizador sellado, comprobado antes de la fecha (06-10-2026)
- `parseInfo` comprueba el localizador sellado como `ParseInfo` de Go desde `69dbb0c`, a petición del autor: la cadena del stanza tlock en hexadecimal en minúsculas y, si la DateKey es de Quicknet, la de Quicknet; y que el cuerpo tras la cabecera `age` lleve un texto de 4096 bytes o un múltiplo, así que una cabecera sin cuerpo se rechaza. Cada caso es `ERR_EXTENSION_DATA_INVALID` con el texto de Go. `infoExtension` rechaza además una DateKey de un perfil que la librería no fija. El límite de 1 MiB al abrir el localizador se queda, por decisión del autor.
- Los vectores de Go del localizador se regeneran sobre ese commit: cambian solo los casos de esas comprobaciones.
### La especificación 0.13, aprobada (06-10-2026)
- El autor aprobó el 6 de octubre de 2026 el borrador v0.13, NAT64, tal como estaba: `datekeys-go` lo cierra con el tag `spec-v0.13` (`913dd60`). `SPEC_VERSION` pasa a `0.13`, `testdata` se sincroniza con ese tag, y `testing/mutation-texts.json` se regenera con Go: solo cambia el campo `spec` de cada fichero.
@ -110,12 +110,11 @@ Secretos: `access_material` de un `.dkk` e `I_PAYLOAD` de CONTROL_CBOR se borran
### El localizador
El localizador sigue al paquete `locator` de Go también donde el autor tiene decisiones pendientes (apartado de la sesión del 5 y 6 de octubre de `../docs/HANDOFF.md`), para que las dos librerías den lo mismo hasta que Go cambie:
El localizador sigue al paquete `locator` de Go también en esto, que el autor decidió el 6 de octubre de 2026 dejar así:
- `parseInfo` no mira la cadena del stanza sellado, acepta una cabecera `age` sin cuerpo, e `infoExtension` no comprueba que el perfil esté pinneado;
- `openSealed` lee como mucho 1 MiB del texto del localizador, y un defecto posterior queda oculto tras el error de `unmarshalLocator`.
Un CID con un carácter de más cuyos bits son cero, y `https://[[2000::]/`, se rechazan desde que Go los rechaza (`e801e03` de `datekeys-go`): el §44.1 de la v0.12 ya pedía el CID en su forma canónica y un literal IPv6 con un solo par de corchetes.
`parseInfo` comprueba el localizador sellado tanto como se puede antes de la fecha, como Go desde `69dbb0c`: la cadena del stanza en hexadecimal en minúsculas, la de Quicknet si la DateKey es de Quicknet, y un cuerpo que lleva un texto de 4096 bytes o un múltiplo, así que una cabecera sin cuerpo se rechaza; `infoExtension` rechaza además una DateKey de un perfil que la librería no fija. Un CID con un carácter de más cuyos bits son cero, y `https://[[2000::]/`, se rechazan desde que Go los rechaza (`e801e03` de `datekeys-go`): el §44.1 de la v0.12 ya pedía el CID en su forma canónica y un literal IPv6 con un solo par de corchetes.
`checkResolvedIp` sigue la v0.13 (§44.1, cambio 1 del §76), como `locator.CheckResolvedIP` de Go: una dirección de NAT64 a la que resuelve un nombre, de `64:ff9b::/96` o del prefijo de la red que la aplicación le pasa en `nat64`, cuenta por la IPv4 que lleva dentro. `vectors.test.ts` corre los 42 casos de `resolved_ip.json`.
`locator: self-check: a reader rejects this extension: locator: the body of the locator is ${sealed.length-end} bytes, which no plaintext of 4096 bytes or a multiple gives: ERR_EXTENSION_DATA_INVALID`,
);
}
});
it('infoExtension refuses a DateKey that is not canonical and a note that breaks its rules, with their errors',()=>{