- Verschifft
- 19. August 2026 um 02:18 UTC
- Autor
- kamo
- Ausschuss
- f55a95c
KToken konnte ein echtes Token nicht verifizieren. Die vier IDs, die es trägt, sind int64s, und die Java Signer (kamo-shared-Bibliothek KToken#canonicalForMac) fügt sich jeder als rohe "long", so dass alle 19 Ziffern gehen in das MAC-Material. Diese Klasse liest sie mit Number(), die vorbeirundet 2-53, und jeder Setter dann angewendet "v|0" -- eine 32-Bit-Abkürzung auf der Oberseite der Rundung. 1168485648209608710 kam als kleiner Integer heraus, der neubeglaubigte HMAC passte nicht mit einer der Server unterzeichnet, und parseAndVerifyCookie zurückgegeben Null: eine gültige Token gelesen als geschmiedet. Es stimmte immer nur mit sich selbst überein, auf ids klein genug, um zu vertreten. Die ids sind nun die eigenen Ziffernfolge des Cookie, so dass das Material mit dem Signer-Bäter übereinstimmt für byte, und werden durch Form statt durch Zahlen( validiert, die die Punkt. Der Ablauf bleibt eine Zahl -- Epochesekunden sind 1,8e9 und in keiner Gefahr. Nichts ruft parseAndVerifyCookie heute, in einer der drei Next Apps; das Cookie ist fachübergangen an die Dienste wörtlich. Das behebt also eher eine Landmine als einen Ausfall -- aber es ist eine Landmine in einem Auth-Pfad, wo der Ausfall wie ein abgelehntes Login aussehen würde anstatt eine Rundung Bug. Die neuen Tests sind mutationserprobt: 4 der 6 scheitern gegen die vorherige Implementierung. Die gleiche Lösung geht an Kamo-Login und Kamo-Register, die voneinander abweichende Kopien dieser tragen mit dem gleichen Defekt.