- Verschifft
- 23. September 2026 um 10:12 UTC
- Autor
- Kamo
- Ausschuss
- e94af78
TranscriptionController, RecordingIngestController und RecordingProcessController alle im Vergleich X-Internal-Auth mit String.equals (ein Timing-Okakel auf einem geteilten Geheimnis) und säumig ************ zum buchstäblichen "dev-secret-change-in-prod" - beides im Java @Value-Anmerkung und in k8s/configmap.yaml's eigenem Platzhalter Standard. Die *** secretRef in deployment.yaml ist "optional: true", also eine Umgebung ohne dieses Geheimnis montiert fiel durch zu einem Wert, der Schiffe in diesem Repo, und damit im Bild, anstatt sich zu verweigern Service-to-Service-Anrufe konnte es nicht überprüfen. Nun: MessageDigest.isEzu für den Vergleich, und jede wörtliche Standardeinstellung entfernt (Java und ConfigMap) so ein unset Geheimnis löst sich leer und jeder dieser Controller verweigert die rufen. Bestätigt sicher für die Produktion vor dem Entfernen der Standardwerte: kubectl zeigt die *** k8s Secret existiert mit einem echten ************ Wert in der Namespace kamo und deployment.yaml zieht ihn bereits über envFrom/secretRef ein. Neue Tests ******************************** ************ decken die leere/null-geheime Verweigerung und insbesondere den Fall ab das altes von neuem Verhalten unterscheidet: mit dem geheimen erzwungenen Leerzeichen, ""gleich("") ist wahr, also die OLD Single . . == null || **************** überprüfen lassen einen Anrufer, der eine EMPTY X-Internal-Auth Header direkt bis hin zur Business-Logik. Mutation-geprüft gegen die Pre-Fix-Controller: 3 von 13 Tests (genau die drei ************-Fälle) gehen rot ohne diese Lösung.