- Spegnimento
- 19 agosto 2026 alle ore 02:18 UTC
- Autore
- kamo
- Impegno
- f55a95c
KToken non poteva verificare un vero token. I quattro id che trasporta sono int64s, e il Java signer (kamo-shared-library KToken#canonicalForMac) si applica ciascuno come un `long` grezzo, quindi tutti 19 cifre entrano nel materiale MAC. Questa classe li legge con Number(), che gira oltre 2^53, e ogni setter poi applicato `v|0` -- una tronca a 32 bit in cima alla arrotondazione. 1168485648209608710 venne fuori come un piccolo integer, il noto HMAC non corrispondeva al un server firmato, e parseAndVerifyCookie restituito null: un token valido letto come forgiato. Ha mai concordato con se stesso, su ids abbastanza piccolo da rappresentare. Gli id sono ora le stringhe digitali del cookie, quindi il materiale corrisponde al byte del firmatario per byte, e sono convalidati dalla forma piuttosto che da Number(), che avrebbe sconfitto punto. La scadenza rimane un numero -- epoca secondi sono ~1.8e9 e in nessun pericolo. Niente chiama parseAndVerifyCookie oggi, in una delle tre app Next; il cookie è inoltrato ai servizi verbatim. Così questo risolve una minestra piuttosto che un outage -- ma è una minestra in un percorso auth, dove il fallimento sembrerebbe come un login respinto piuttosto che una cimice arrotondata. I nuovi test sono provati da mutazioni: 4 dei 6 falliscono contro la precedente implementazione. La stessa correzione va a kamo-login e kamo-register, che portano copie divergenti di questo file con il difetto identico.