- Navios
- 19 de agosto de 2026 às 18:38 UTC
- Autor
- Kamo
- Enviar
- e64cc8b
Cada corpo de notas na produção era ilegível. NOTAS MASTER ENCRYPTION KEY foi nunca definido em nenhum lugar - não na implantação, e o ConfigMap implantado não notas: bloco em tudo - então notes.master-encription-key resolveu esvaziar e getUserEncryptionKey gerou uma chave AES aleatória no heap no primeiro uso. Isso. A chave viveu exactamente tanto quanto a cápsula. Cada implantação, OOM ou nó se move órfão cada nota escrita antes dela: descriptografia jogada, conteúdo foi anulado, e desde conteúdo salvar deliberadamente NULLs conteúdoPlain não havia nada legível deixado. A nota manteve seu título e cor e perdeu seu corpo. Uma chave ausente agora pára o serviço na construção. Inventar um é o fracasso modo, não um recuo: um serviço de notas que não pode ler as notas de ontem é pior do que um que não aparece, porque o primeiro destrói os dados silenciosamente. A chave em si vem do novo segredo notas-encriptação-chave, ligado através de ambos o ConfigMap e a implantação, e não deve ser rodado sem re-encriptar. As chaves por membro agora vêm de HKDF-SHA256 em vez de XOR contra uma repetição string "user-<id>", que foi reversível - uma chave de membro vazada mais um ID conhecido recuperou a chave mestra e com ela as notas de todos os outros membros. As chaves também são agora, coincidindo com o escopo das notas. Nenhum mudar custa uma migração: nenhum texto cifrado existente foi legível para começar. o descriptografarDTO pára de reportar uma falha como uma nota vazia e define a descriptografação Falhou, para que um cliente se possa recusar a escrever sobre o que não pôde ler.