Über die Probleme und Herausforderungen beim Unit-Testen im Security-Umfeld mit Kotlin-Bibliotheken...

Ich habe mich dafür entschieden, die Tests für meinen Timestamping Server zu veröffentlichen und - wo möglich und sinnvoll - zu automatisieren.

Ich dachte, dass die größte Schwierigkeit dabei darin bestünde, die Tests so weit zu automatisieren, dass die Code-Coverage nahe 100 % läge, ohne sensibles Crypto-Material im Repository zu exponieren. Schließlich wollte ich, dass das Projekt auf GitHub über die GitHub-Actions gebaut werden sollte.

Und im Zuge der CI/CD sollten natürlich möglichst auch alle Tests abgearbeitet werden. Viele dieser Tests benötigen aber tatsächliches Crypto-Material (Schlüssel, Zertifikate, ...). Was ich vermeiden wollte war, echtes Crypto-Material in das Repo zu packen - das würde unweigerlich dazu führen, dass Leute, die das Projekt verwenden keine eigenen Materialien dazu nutzen würden, sondern aus Faulheit einfach das dem Projekt beiliegende.

Ich erinnerte mich an RFC 6963 - Certificate Transparency und die darin beschriebene Methode des Vergiftens eines Zertifikats mittels einer kritischen Erweiterung (poison extension) - ist eine Erweiterung im Zertifikat, die als critical eingestuft, jedoch unbekannt ist, muss das Zertifikat insgesamt als ungültig betrachtet werden.

Genau auf diese Weise habe ich letztlich das Zertifikat der Test-TSA markiert: Es enthält eine solche Erweiterung und damit wird effektiv verhindert, dass dieses Zertifikat jemals im Produktivbetrieb eingesetzt werden kann.

Dadurch kommen unter Umständen neue Herausforderungen auf mich zu wenn es darum geht, auch die Integrationstests zu automatisieren, aber das lasse ich erst einmal in Ruhe auf mich zukommen.

Das eigentlich interessante Problem beim Publizieren der Unit-Tests kam aus einer gänzlich unerwarteten Richtung: Das Projekt nutzt als Grundlage Javalin - ein Kotlin-Framework. Diese Tatsache sorgte dafür, dass ich meinen bestehenden Code umstrukturieren musste: In Kotlin sind per Definition alle Klassen und deren Member final - was offenbar dazu führt, dass interne Variablen nicht mehr per Getter und Setter maskiert werden - man greift direkt darauf zu. Das führt aber dazu, dass es nicht mehr trivial ist, solche Infrastruktureelemente zu "mocken" - zum Beispiel mit Mockito.

Bei mir führte das dazu, dass ich tatsächlich Code umschreiben musste, da ich auf Methoden und Felder einer zentralen Javalin-Klasse zugriff und beides zusammen nicht zu mocken ist - entweder werden die Felder einzeln durch Mocks ersetzt - dann kann die umgebende Klasse kein Mock sein - oder die Klasse selber wird gemockt - dann kann man aber die Felder nicht mocken.

Glücklicherweise war die daraus resultierende Änderung minimal und betraf nicht die Funktionalität, sondern lediglich das Monitoring. Dadurch kann das Projekt jetzt mit einer - meiner Ansicht nach - durchaus ordentlichen Code Coverage aufwarten.