wxWidgets auf Windows per Kommandozeile mit Visual Studio kompilieren

Wer schnell und einfach wxWidgets auf Windows auf der Kommandozeile kompilieren will, öffnet ein Visual Studio Terminal, also ein Terminal, in dem die Umgebungsvariablen für VS gesetzt sind, navigiert zu den Sourcen von wxWidgets und dort ins Verzeichnis build\msw und kann via nmake den Kompilationsprozess in Gang setzen:

nmake /f makefile.vc BUILD=release SHARED=0 TARGET_CPU=X64 RUNTIME_LIBS=static

Wir sehen am Beispiel, dass wir eine Release-Version von wxWidgets bauen, also keine Debug-Informationen drin sind (ansonsten release einfach durch debug tauschen). SHARED=0 bedeutet, dass wir keine dynamischen Libraries bauen möchten (wenn doch, einfach weglassen). Die restlichen Parameter sollten ebenso selbsterklärend sein.

Ein interessanter Fehler beim Testen von Software

In der Firma, in der ich arbeite, ist mir ein Malheur passiert, und zwar beim Testen der von mir geschriebenen Software. Ich will (vielleicht darf) ich keine Details verraten, aber es geht um ein Programm, welches ein anderes Programm startet, überwacht und beendet. Nichts Großes, nichts Kompliziertes. Eine Sache muss man aber wissen: das Programm, an dem ich arbeite und das Programm, dass von meinem gestartet wird, soll auf macOS arm64 und macOS amd64 laufen und ist keine Fat-Binary, was bedeutet, dass es für die jeweilige Plattform immer ein Bundle gibt.

Jetzt ging es zum Glück nur um eine Testversion, die ich meinen Kollegen zum Ausprobieren geben wollte. Ich packte mein Programm also, zusammen mit dem Fremdprogramm. Einmal für macOS amd64, einmal für macOS arm64 (und noch weitere Plattformen). Faul, wie ich bin, hatte ich dafür ein Script geschrieben. Leider habe ich nicht weit genug automatisiert, denn hier passierte das Problem: Ich packte mein Programm für amd64 und das Fremdprogramm für arm64. Bevor ich meine Software zum Testen herausgebe, probiere ich diese immer einmal aus, zumindest im kleinen Rahmen. Eine CI-CD-Pipeline gab es in dem frühen Entwicklungsstadium leider noch nicht (Das ist ein Fehler! Kümmert euch direkt darum!). Jetzt hätte das Problem beim Testen auffallen müssen, aber hier beging ich den entscheidenden großen Fehler in der gesamten, sehr suboptimalen Kette: Ich probierte die arm64 und die amd64 meine Software und der Fremdsoftware nur auf meiner arm64-macOS-VM aus.

Wer aufgepasst hat, kann sich sicher denken, was jetzt passiert ist: Da Rosetta 2 lief, startete sie natürlich mein amd64-Programm und mein amd64-Programm startete das arm64-Fremdprogramm, ohne, dass ich was von einem Fehler mitbekam.

Ich lieferte natürlich die amd64-Version aus und es kam, wie es kommen musste: bei den Kollegen mit amd64 macOS funktionierte zwar mein Programm, das Fremdprogramm aber natürlich nicht, da es kein Rosetta-Äquivalent auf macOS amd64 gibt.

Dabei hatte ich den Fehler die ganze Zeit auf dem Schirm, denn mein Paketierungsscript lieferte Hinweise, wenn die Architektur der Fremdsoftware mit der Architektur meines Programms nicht zusammenpasst. Aber ein Hinweis lässt sich im Stress leicht übersehen. Hier hätte ich doch besser einen Abbruch eingebaut.

Was lernen wir daraus? Am Besten vollständig automatisierte Tests implementieren, aber wenn man für verschiedene Architekturen händisch testet, das dann auch direkt auf der jeweiligen Architektur durchführen und nicht in einer Emulation.

AESNI und FreeBSD – “Crypto: accelerated software” nutzt Hardware

Nur kurz am Rande: meine Verwirrung war groß, als ich bei geli las “Crypto: accelerated software”. Ich dachte, der Hardwareteil der Algorithmik für AESNI würde nicht genutzt. Also suchte ich zuerst im BIOS meines HP MicroServer Gen8 mit XEONProzessor nach AES, wurde aber nicht fündig. Dann durchsuchte ich das Internet.

Durch bsdforen.de fanden wir aber heraus: es gab lediglich eine Namensänderung (:. Es steht jetzt “accelerated software” drin und bedeutet, dass die Hardware mitgenutzt wird, ansonsten sollte nur “software” darin stehen.

Java: JAR-Klassen-Versionsproblematik

Ja, nach langer langer Pause musste ich mich wieder einmal mit Java auseinander setzen. Dabei stieß ich auf ein Problem: Ich wollte JDBC-Treiber in einer bereits vorhandenen Version eines Programms einbinden. Soweit kein Problem, doch nicht alle Treiber funktionierten. Ich bekam keine (sinnvolle) Fehlermeldung, sondern Dinge funktionierten einfach nicht.

Ich fand dann heraus, dass mein JDK mitunter zu alt war, um mit den Klassendateien im JAR zu laufen. hier hätte ich mir eine vernünftige Fehlermeldung gewünscht, es kam aber keine.

Da ich für das Deploying (und nur für das Deploying) diese Problematik testen und Fehler werfen wollte, überlegte ich, wie ich vorzugehen habe. Zuerst dachte ich naiv, dass JAR-Dateien versioniert sein könnten. Natürlich völliger Quatsch, sind das ja einfach nur Archive, in denen alles Mögliche drin sein kann. So ist es auch: die darin enthaltenen Klassen-Dateien (.class) können für unterschiedliche JRE-Versionen kompiliert worden sein.

Allerdings kann man recht einfach herausfinden, für welche Version die Klassendateien kompiliert wurden: Im fünften und sechsten Byte der class-Datei steht die Minor-Version (also Byte-Offset 4 und 5), im siebten und achten Byte steht die Major-Version: s. Wikipedia.

Ich schrieb also ein Programm in C, welches die libzip nutzt, um an die Dateien im JAR zu kommen, las dann Byte 7 und 8 aus (Offset 6 und 7) (auf Endianess achten!) und fand somit die höchste und niedrigste Version des JDKs heraus. Eigentlich recht einfach.

Vielleicht hilft dem ein oder anderen das.

Hier noch die Versionsnummern bis 19 (kopiert von hier):

Java SE 19 = 63 (0x3F hex)
Java SE 18 = 62 (0x3E hex)
Java SE 17 = 61 (0x3D hex)
Java SE 16 = 60 (0x3C hex)
Java SE 15 = 59 (0x3B hex)
Java SE 14 = 58 (0x3A hex)
Java SE 13 = 57 (0x39 hex)
Java SE 12 = 56 (0x38 hex)
Java SE 11 = 55 (0x37 hex)
Java SE 10 = 54 (0x36 hex)
Java SE 9 = 53 (0x35 hex)
Java SE 8 = 52 (0x34 hex)
Java SE 7 = 51 (0x33 hex)
Java SE 6.0 = 50 (0x32 hex),
Java SE 5.0 = 49 (0x31 hex)
JDK 1.4 = 48 (0x30 hex)
JDK 1.3 = 47 (0x2F hex)
JDK 1.2 = 46 (0x2E hex)
JDK 1.1 = 45 (0x2D hex)

KooKooK (Update 4): Die Authentifizierung im Einzelnen

Vielleicht interessiert es den ein oder anderen, wie ich die Authentifizierung durchführe. Mich würde unbedingt Eure Meinungen interessieren.

Ziel war es, dass man nicht Benutzername und Kennwort über die Leitung zum Server zur Verifizierung überträgt, da ich das für unsicher halte. Ich habe es erst einmal so gelöst:

  1. Client verbindet sich zum Server
  2. TLS-Handshake
  3. Server sendet Welcome-Message an Client. Die Welcome-Message besteht aus der Versionsnummer des Servers sowie einer UUID, getrennt mit einem Doppelpunkt (1.0.1:8234-234-234-234)
  4. Der Client trennt die empfangene Versionsnummer von der UUID anhand des Doppelpunkts
  5. Der Benutzer hat am Client den Benutzernamen und das Kennwort eingegeben
    1. Das Kennwort wird mit MD5 gehasht
    2. Benutzername, UUID und gehashtes Kennwort wird als Bytearray zusammengefasst und mit Keccak_512 gehasht
    3. Daraus entsteht dann das Bytearray, was zum Server geschickt werden soll
  6. Das gehashte Bytearray mit vorangestelltem Benutzername@ wird zum Server geschickt (ausgedachtes Beispiel: thorsten@ljdf08asdflu0dsa98foklj234ASDF)
  7. Der Server hat jetzt den unverschlüsselten Benutzernamen, der eindeutig in der Datenbank ist und zieht das Kennwort, fügt auch alles zusammen und hasht dann das Bytearray
  8. Der Server vergleicht, ob das empfangene Bytearray gleich dem selbst generiertem Bytearray ist. Ja = Der Benutzer ist eingeloggt, Nein = Der Benutzer ist nicht eingeloggt

Anmerkungen: In der Implementierung werden weitere Fehler behandelt und zurückgeliefert. Beispielsweise, ob der Benutzer überhaupt vorhanden ist, ob der Hash gebildet wurde, usw. Was noch fehlt ist, ob der Benutzer auch (in der Datenbank) auf aktiv steht.

Ihr könnt das in folgenden Dateien nachvollziehen:

Mitunter sollte man weitergehen und zum Beispiel auch den Benutzernamen nicht im Klartext senden?

KooKooK (Update 3): Umbauten und weitere Informationen

Ich habe mich doch entschieden, einige Umbauten durchzuführen. Zunächst wollte ich den Server eigentlich pro Verbindung mit einem Thread laufen lassen. Das hat direkt, für ein Hobbyprojekt mit wenig Zeit, viele Probleme aufgeworfen.

Von Threads

Vor allem sind die Dateideskriptoren auf unterschiedlichen Betriebssystemen unterschiedlich konfiguriert, aber doch teils sehr limitiert. Ich wollte auf meinem Mac mal eben 500 Verbindungen aufbauen, bei 80 oder so war Schluss. Man kann das Limit zwar höher schrauben, aber man ist natürlich durchaus limitiert.

Dann gab es noch Probleme mit dem Verschieben von Objekten innerhalb von Qt zu Threads. Neue erstellte Objekte liefen nicht im Thread, sondern Hauptthread. Das kann man alles recht problemlos fixen, indem man mit Workerprozessen arbeitet, aber ich wollte da nicht weiter herumbauen (zeitliche Einschränkung), da ich vorwärts kommen wollte. Aber interessant: Ich habe mal 500 Konnektierungen gleichzeitig startet (so gleichzeitig, wie es nur geht). Das hat auf meinem Mac 200ms (etwas darunter) benötigt, um auf 500 Verbindungen ein “Hallo Welt” über das Loopback-Device zu senden. War zwar nur Loopback, aber ich war doch erstaunt, wie schnell es geht, so viele Threads zu öffnen, was zu schicken und wieder zu schließen.

Keine Threads mehr

Dann habe ich einfach mit generellen nonblocking Sockets herumgespielt (im Thread waren sie auch nonblocking!) und festgestellt, dass es von der Geschwindigkeit her für einige hundert Verbindungen ausreichen sollte, zumal man nicht sonderlich viele Informationen senden muss und diese ja auch noch komprimieren kann. Also habe ich alles umgebaut.

Benutzerauthentifizierung

Ich habe das tatsächlich so ähnlich, wie im vorherigen Blogeintrag, implementiert. Letztlich ist es so: Der Client macht eine Authentifizierungsanforderung an den Server. Der Server kennt den Benutzernamen und schickt eine UUID. Dann werden die Benutzerinformationen mit der UUID zusammengefasst und gehasht, zurückgeschickt, der Server macht das selbe und vergleicht beide Ergebnisse. Sind sie gleich, gilt der Benutzer als eingeloggt.

Weiteres

Weiterhin habe ich noch Datenbankabstraktionen implementiert für MySQL, PostgreSQL und SQLite, damit man Benutzer speichern kann. Ein Logging habe ich implementiert und dem Server kann man Signale schicken, um ihn zu beenden oder sonst was zu tun. Es gibt einen Testclient unter resources/sslclient, mit dem man mit dem Server ein wenig spielen kann.

Hier geht es übrigens zum GitHub-Repo.

KooKooK (Update 2): Überlegungen zur Benutzerauthentifizierung

Benutzer sollen sich am System anmelden können. Ich dachte mir, die speichern wir einfach in einer relationalen Datenbank, da Qt dafür schon Bibliotheken mitbringen (MySQL, PostgreSQL, SQLite). Welches DBMS wir nehmen, weiß ich noch nicht.

Dennoch muss die Benutzerauthentifizierung ja implementiert werden. Naiv könnte man das so machen:

  1. Client schickt Benutzernamen und Kennwort an Server
  2. Server prüft per Datenbank Benutzernamen und Kennwort
  3. Server gibt OK oder NK zurück

Jetzt will ich aber, wenn auch verschlüsselt, keinen Benutzernamen und kein Kennwort einfach durch die Gegend schicken. Meine Idee war folgende:

  1. Auf dem Server sind Benutzername und Kennwort in der Datenbank hinterlegt, wobei das Kennwort gehasht ist
  2. Client meldet sich bei Server, dass er sich authentifizieren will
  3. Server schickt einen einfache String (z.B. eine UUID) an den Client
  4. Der Client hasht sein Kennwort in der selben Weise, wie der Server, und fügt im String Benutzernamen und Kennwort zusammen (thorstenAdsfjlksudSDFAalsj)
  5. Mit dem zusammengefügten Benutzernamen und gehashten Kennwort verschlüsseln wir den vom Server geschickten String (z.B. die UUID)
  6. Den verschlüsselten String schicken wir an den Server zurück
  7. Der Server prüft den verschlüsselten String mit seinem eigenen (er macht das selbe online)
  8. Der Server gibt OK oder NK zurück

Was haltet ihr davon? Eine gute Idee? Hat jemand eine bessere?

KooKooK (Update 1): Ein paar Implementierungen ohne Video

Ich habe überlegt: ich kann leider nicht alles zu dem Projekt aufnehmen. Ich habe noch ein paar Erweiterungen gemacht. Was alles, seht ihr im GitHub-Projekt.

Hier eine Liste:

  • Über die Server.ini kann man den Server jetzt teils konfigurieren
  • Einfaches Logging wurde eingebaut
  • Threads können beendet werden
  • Kompilierungsscript wurde erweitert
  • Unix-Signal-Handling wurde implementiert (TERM und HUP)

Schreibt mir gerne bei Fragen und Anregungen.