Die freie Embedded-Datenbank LMDB (Lightning Memory-Mapped Database) hat Version 1.0 erreicht. Mit dem ersten Major-Release dokumentieren die Entwickler die API und das Verhalten der Bibliothek neu und stellen eine aktualisierte Dokumentation bereit. Für bestehende Anwendungen gibt es einen eigenen Migrationsleitfaden von der 0.9-Serie.

LMDB ist eine in Anwendungen eingebettete Key/Value-Datenbankbibliothek für lokale Datenhaltung. Sie richtet sich an Entwickler, die eine transaktionssichere Datenbank ohne separaten Serverprozess benötigen, etwa für Verzeichnisdienste, Caches oder Metadaten. Anders als klassische Datenbanksysteme lädt LMDB Daten nicht in einen eigenen Puffer-Cache, sondern bildet die komplette Datenbank per Memory Mapping in den virtuellen Adressraum des Prozesses ab. Lesezugriffe erfolgen dadurch direkt auf die gemappten Speicherbereiche, ohne zusätzliche Speicherallokationen oder Kopieroperationen.

Memory Mapping statt Datenbank-Cache

Das Grundprinzip von LMDB bleibt auch mit Version 1.0 unverändert. Die Bibliothek verwendet einen B-Baum als Datenstruktur und überlässt das Caching vollständig dem Betriebssystem. Da Datensätze direkt aus dem Speicherabbild gelesen werden, entfallen Zwischenschritte wie malloc() oder memcpy() beim Auslesen von Daten. Das reduziert den Verwaltungsaufwand und kann insbesondere bei leseintensiven Workloads die Leistung steigern. Grundlage dafür ist die Memory-Mapping-Funktion des Betriebssystems, bei der Dateiinhalte transparent in den virtuellen Speicher eingeblendet werden.

Auch das Transaktionsmodell bleibt erhalten. LMDB bietet ACID-Eigenschaften und setzt auf Multi-Version Concurrency Control (MVCC). Neue Daten werden per Copy-on-Write geschrieben, sodass bereits vorhandene Seiten niemals überschrieben werden. Ein Leser sieht dadurch stets einen konsistenten Datenbestand, während Schreibvorgänge parallel vorbereitet werden können. Ein typisches Beispiel ist ein Dienst, der kontinuierlich Konfigurationsdaten ausliest, während ein Verwaltungswerkzeug Änderungen schreibt: Leser arbeiten ohne Sperren weiter und werden durch den Schreibvorgang nicht blockiert.

Ein Schreiber, viele Leser

Das Nebenläufigkeitsmodell von LMDB unterscheidet sich von vielen anderen Datenbanken. Beliebig viele Prozesse oder Threads können gleichzeitig lesen, Schreibtransaktionen werden dagegen vollständig serialisiert. Zu jedem Zeitpunkt darf nur eine Schreibtransaktion aktiv sein. Dadurch schließt das System Deadlocks zwischen konkurrierenden Schreibern aus. Leser blockieren Schreiber nicht, ebenso wenig müssen Leser auf laufende Schreibvorgänge warten.

Die Entwickler verzichten außerdem bewusst auf ein Write-Ahead-Log oder ein Append-only-Protokoll. Statt regelmäßig Logdateien zusammenzuführen oder Datenbanken zu komprimieren, verwaltet LMDB freie Seiten innerhalb der Datenbank selbst und verwendet sie für spätere Schreibvorgänge erneut. Dadurch wächst die Datenbank im Normalbetrieb nicht unbegrenzt an, wie es bei logbasierten Verfahren ohne Wartung passieren kann.

Hinweise für den Betrieb

Die Release-Notes auf GitHub sowie die Dokumentation weisen auf einige Einschränkungen hin: Lange laufende Lesetransaktionen können verhindern, dass bereits freigegebene Seiten wiederverwendet werden. Dadurch kann die Datenbankdatei unnötig anwachsen. Entwickler sollten deshalb lang andauernde Transaktionen vermeiden und abgebrochene Prozesse regelmäßig auf verwaiste Reader-Einträge prüfen. Dafür stehen unter anderem die Funktion mdb_reader_check sowie das Werkzeug mdb_stat zur Verfügung.

Nicht empfohlen wird außerdem der Einsatz auf Netzwerkdateisystemen. Da LMDB auf Memory Mapping sowie Dateisperren des Betriebssystems setzt, können dort Synchronisationsprobleme auftreten. Auch das gleichzeitige mehrfache Öffnen derselben Datenbank innerhalb eines Prozesses gilt laut Dokumentation als problematisch.

(fo)

.NET 10.0 enthält drei neue asymmetrische Kryptografie-Algorithmen: ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205), die im August 2024 die US-amerikanischen Bundesbehörde National Institute of Standards and Technology (NIST) verabschiedet hat.

Federal Information Processing Standards (FIPS) sind offizielle technische Standards des NIST:

Diese Kryptografie-Algorithmen gehören zur Klasse Post-Quanten-Kryptografie (Post-Quantum Cryptography, PQC). Das sind neuere kryptografische Verfahren, die selbst dann sicher bleiben sollen, wenn leistungsstarke Quantencomputer verfügbar sind. Heute etablierte Algorithmen wie RSA und ECC basieren auf mathematischen Problemen, die Quantencomputer recht schnell lösen können. PQC-Algorithmen sollen auch mit Quantencomputern nicht schnell angreifbar sein.

Die neuen Klassen findet man im .NET-Namensraum System.Security.Cryptography:

• System.Security.Cryptography.MLKem
• System.Security.Cryptography.MLDsa
• System.Security.Cryptography.SlhDsa

Microsoft will aber FIPS 206 nicht implementieren: „We do not believe there is a need for any FIPS 206 algorithms in .NET workloads, they are planned as ’never’ until evidence suggests otherwise.“

Windows liefert diese Algorithmen in der Cryptography Next Generation API (CNG) seit Windows Insiders, Canary Channel Build 27852 oder höher mit. Eine stabile Version gibt es seit Windows 11 25H2 und Windows Server 2025. Für macOS- und Linux-Systeme braucht man die OpenSSL-Bibliothek ab Version 3.5. Folgender Code zeigt einige Beispiele für PQC:

using System.Security.Cryptography;	
 
namespace NET10_Console;
 
public class FCL10_PQC
{
 public void GetSupportedStandards()
 {
 
  CUI.Demo("Post-Quantum Cryptography (PQC) in .NET 10.0");
 
  CUI.H2("Prüfung, ob die PQC-Algorithmen verfügbar sind");
  Console.WriteLine("ML-KEM (FIPS 203) für Verschlüsselung: " + System.Security.Cryptography.MLKem.IsSupported);
  Console.WriteLine("ML-DSA (FIPS 204) für Digitale Signaturen: " + System.Security.Cryptography.MLDsa.IsSupported);
 
#pragma warning disable SYSLIB5006 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
  Console.WriteLine("SLH-DSA (FIPS 205) für Digitale Signaturen (Alternative/Reserve): " + System.Security.Cryptography.SlhDsa.IsSupported);
 
 
 }
 
 /// 

 /// ML-KEM (quantensicher) schützt den Schlüsselaustausch
 /// AES-256 (quantenresistent) verschlüsselt die Daten
 /// Beide zusammen bieten vollständigen Quantenschutz
 /// 
 public void KEMDemo()
 {
  CUI.Demo(nameof(KEMDemo) + ": Verschlüsselung mit AES unter Verwendung von ML-KEM zum Schlüsselaustausch");
 
  try
  {
   string originalText = "Dies ist ein vertraulicher Text, der mit Post-Quantum Cryptography geschützt wird!";
 
   CUI.H2("Originaltext");
   Console.WriteLine(originalText);
 
   // 1. Empfänger generiert Schlüsselpaar
   CUI.H2("1. Schlüsselpaar generieren (Empfänger)");
   using MLKem receiverKey = MLKem.GenerateKey(MLKemAlgorithm.MLKem1024);
 
   // Export/Import als PEM
   string publicKeyPem = receiverKey.ExportSubjectPublicKeyInfoPem();
   Console.WriteLine($"Öffentlicher Schlüssel (PEM): {publicKeyPem.Substring(0, Math.Min(80, publicKeyPem.Length))}...");
 
   // 2. Sender verwendet öffentlichen Schlüssel für Encapsulation
   CUI.H2("2. Gemeinsames Geheimnis erzeugen (Sender)");
   using MLKem senderKey = MLKem.ImportFromPem(publicKeyPem);
 
   // ML-KEM 1024: Ciphertext = 1568 Bytes, Shared Secret = 32 Bytes
   byte[] ciphertext = new byte[1568];
   byte[] sharedSecretSender = new byte[32];
   senderKey.Encapsulate(ciphertext, sharedSecretSender);
   Console.WriteLine($"Ciphertext Größe: {ciphertext.Length} Bytes");
   Console.WriteLine($"Gemeinsames Geheimnis (Sender): {Convert.ToHexString(sharedSecretSender)}");
 
   // 3. Sender verschlüsselt Daten mit AES unter Verwendung des gemeinsamen Geheimnisses
   CUI.H2("3. Daten mit AES verschlüsseln (Sender)");
   byte[] encryptedData;
   byte[] iv;
   using (Aes aes = Aes.Create())
   {
    aes.Key = sharedSecretSender;
    aes.GenerateIV();
    iv = aes.IV;
    using ICryptoTransform encryptor = aes.CreateEncryptor();
    byte[] plainBytes = System.Text.Encoding.UTF8.GetBytes(originalText);
    encryptedData = encryptor.TransformFinalBlock(plainBytes, 0, plainBytes.Length);
   }
   Console.WriteLine($"Verschlüsselte Daten: {Convert.ToHexString(encryptedData)}");
   Console.WriteLine($"IV: {Convert.ToHexString(iv)}");
 
   // 4. Empfänger extrahiert gemeinsames Geheimnis mit Decapsulation
   CUI.H2("4. Gemeinsames Geheimnis extrahieren (Empfänger)");
   byte[] sharedSecretReceiver = new byte[32];
   receiverKey.Decapsulate(ciphertext, sharedSecretReceiver);
   Console.WriteLine($"Gemeinsames Geheimnis (Empfänger): {Convert.ToHexString(sharedSecretReceiver)}");
   Console.WriteLine($"Geheimnisse identisch: {sharedSecretSender.SequenceEqual(sharedSecretReceiver)}");
 
   // 5. Empfänger entschlüsselt Daten mit AES
   CUI.H2("5. Daten mit AES entschlüsseln (Empfänger)");
   string decryptedText;
   using (Aes aes = Aes.Create())
   {
    aes.Key = sharedSecretReceiver;
    aes.IV = iv;
    using ICryptoTransform decryptor = aes.CreateDecryptor();
    byte[] decryptedBytes = decryptor.TransformFinalBlock(encryptedData, 0, encryptedData.Length);
    decryptedText = System.Text.Encoding.UTF8.GetString(decryptedBytes);
   }
 
   CUI.H2("Entschlüsselter Text");
   CUI.Green(decryptedText);
   CUI.Success($"Verschlüsselung erfolgreich: {originalText == decryptedText}");
  }
  catch (Exception ex)
  {
   CUI.Error(ex);
  }
 }
 
 /// 

 /// ML-DSA (FIPS 204) - Post-Quantum Digitale Signaturen
 /// Quantensichere Alternative zu RSA/ECDSA für digitale Signaturen
 /// 
 public void DSADemo()
 {
  CUI.Demo(nameof(DSADemo) + ": ML-DSA (FIPS 204) - Post-Quantum Digitale Signaturen");
 
  try
  {
   string originalText = "Dieses Dokument muss digital signiert werden, um Integrität und Authentizität zu gewährleisten.";
 
   CUI.H2("Originaldokument");
   Console.WriteLine(originalText);
   byte[] data = System.Text.Encoding.UTF8.GetBytes(originalText);
 
   // 1. Sender generiert Schlüsselpaar
   CUI.H2("1. Schlüsselpaar generieren (Sender)");
   using MLDsa senderKey = MLDsa.GenerateKey(MLDsaAlgorithm.MLDsa87);
   Console.WriteLine($"Algorithmus: {MLDsaAlgorithm.MLDsa87} (höchste Sicherheitsstufe)");
 
   // Export öffentlicher Schlüssel als PEM
   string publicKeyPem = senderKey.ExportSubjectPublicKeyInfoPem();
   Console.WriteLine($"Öffentlicher Schlüssel (PEM): {publicKeyPem.Substring(0, Math.Min(80, publicKeyPem.Length))}...");
 
   // 2. Sender signiert die Daten
   CUI.H2("2. Daten signieren (Sender)");
   byte[] signature = senderKey.SignData(data);
   Console.WriteLine($"Signatur Größe: {signature.Length} Bytes");
   Console.WriteLine($"Signatur: {Convert.ToHexString(signature).Substring(0, Math.Min(100, Convert.ToHexString(signature).Length))}...");
 
   // 3. Empfänger importiert öffentlichen Schlüssel
   CUI.H2("3. Öffentlichen Schlüssel importieren (Empfänger)");
   using MLDsa verifierKey = MLDsa.ImportFromPem(publicKeyPem);
   Console.WriteLine("Öffentlicher Schlüssel erfolgreich importiert");
 
   // 4. Empfänger verifiziert die Signatur
   CUI.H2("4. Signatur verifizieren (Empfänger)");
   bool isValid = verifierKey.VerifyData(data, signature);
 
   if (isValid)
   {
    CUI.Success("✓ Signatur ist gültig! Datenintegrität bestätigt.");
   }
   else
   {
    CUI.Error("✗ Signatur ist ungültig! Daten wurden möglicherweise manipuliert.");
   }
 
   // 5. Manipulationsversuch demonstrieren
   CUI.H2("5. Manipulationsversuch demonstrieren");
   byte[] manipulatedData = System.Text.Encoding.UTF8.GetBytes(originalText + " MANIPULIERT!");
   bool isManipulatedValid = verifierKey.VerifyData(manipulatedData, signature);
 
   if (!isManipulatedValid)
   {
    CUI.Warning("✓ Manipulation wurde erkannt! Signatur ist für geänderte Daten ungültig.");
   }
   else
   {
    CUI.Error("✗ FEHLER: Manipulation wurde nicht erkannt!");
   }
  }
  catch (Exception ex)
  {
   CUI.Error(ex);
  }
 }

(rme)

Johannes Link, Maintainer der Java-Test-Bibliothek jqwik, hat sich intensiv mit der ethischen Seite von GenAI auseinandergesetzt. Daher hat er im Projekt jqwik, das auf Property-basiertes Testing ausgelegt ist, Vorkehrungen gegen die Nutzung mit GenAI getroffen.

Eine einzelne Zeile Code hat daraufhin eine Debatte über die Grenzen zwischen Protest, Prompt Injection und Lieferketten-Vertrauen im Open-Source-Umfeld ausgelöst. Johannes Link hat in einem ausführlichen Blogeintrag dargelegt, warum er eine bewusst provokante Botschaft an KI-Coding-Agenten in sein Projekt einbaute – und warum er die Aktion als ethisch motivierte Selbstverteidigung versteht und nicht als PR-Gag.

In dieser Episode spricht Eberhard Wolff mit Johannes Link über den Aufschrei in Teilen der Community, der ihm öffentlichen Gegenwind, aber auch Unterstützung eingebracht hat. Link legt seine ethische Motivation dar und was er aus dem ganzen Vorfall gelernt hat.

Livestream am 3. Juli

Die Ausstrahlung findet am Freitag, 3. Juli 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal solo mit Wolff, Schäfer oder Müller. Seit mittlerweile mehr als zwei Jahren berichtet iX (heise Developer) über die Episoden.

(map)