- Navios
- 19 de agosto de 2026 às 02:18 UTC
- Autor
- kamo
- Enviar
- f55a95c
O KToken não pôde verificar um item real. Os quatro IDs que carrega são int64s, e o Java singer (kamo-shared-library KToken# canonicalForMac) adiciona cada um como um 'long' em bruto, então tudo 19 dígitos vão para o material MAC. Esta classe lê- as com o Number (), que passa 2^53, e cada setter então aplicado `v'0` -- um truncamento de 32 bits no topo do arredondamento. 1168485648209608710 saiu como um número inteiro pequeno, o HMAC recomputado não correspondeu ao um o servidor assinado, e analisarAndVerifyCookie retornou null: um token válido lido como Forjada. Ele só concordou consigo mesmo, em identidades suficientemente pequenas para representar. Os IDs são agora as strings de dígitos do próprio cookie, então o material corresponde ao byte do sinalizador para byte, e são validados por forma em vez de por Number(), o que iria derrotar o Ponto. A expiração permanece um número -- os segundos de época são ~1.8e9 e não correm perigo. Nada chama de parseAndVerifyCookie hoje, em qualquer um dos três aplicativos seguintes; o cookie é encaminhou para os serviços verbatim. Isto corrige uma mina em vez de uma falha. é uma mina em um caminho de autenticação, onde a falha pareceria um login rejeitado em vez de um vírus de arredondamento. Os novos testes são comprovados pela mutação: 4 dos 6 falham contra a implementação anterior. A mesma correção vai para kamo-login e kamo-register, que carregam cópias divergentes deste ficheiro com o defeito idêntico.