Connect with us

Entwicklung & Code

Neu in .NET 10.0 [30]: Algorithmen für die Post-Quanten-Kryptografie


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.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.

Weiterlesen nach der Anzeige


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

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

FIPS Algorithmus Zweck .NET-10.0-Klasse
203 ML‑KEM (CRYSTALS‑Kyber) Schlüsselaustausch für AES u.a. System.Security.Cryptography.MLKem
204 ML‑DSA (CRYSTALS‑Dilithium) Digitale Signatur zur Authentifizierung und Datenintegrität System.Security.Cryptography.MLDsa
205 SLH‑DSA (SPHINCS+) Digitale Signatur (Alternative Signaturen, falls später bei ML‑DSA Schwächen entdeckt werden.) System.Security.Cryptography.SlhDsa
206 FN‑DSA (FALCON) Digitale Signatur (geplantes weiteres optionales Signaturverfahren) keine

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.


betterCode() .NET 11.0

betterCode() .NET 11.0

(Bild: King / stock.adobe.com)

Das ist neu in .NET 11.0: Dr. Holger Schwichtenberg und weitere Experten präsentieren am 17. November 2026 auf der Online-Konferenz betterCode() .NET 11.0 die Änderungen für Entwicklerinnen und Entwickler. Das Programm steht jetzt fest, Tickets zum Frühbucherpreis sind verfügbar.

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

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

Weiterlesen nach der Anzeige

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);
  }
 }



Screenshot

Screenshot

Der Screenshot zeigt die Ausgabe des Beispielcodes (Abb. 1).


(rme)



Source link

Entwicklung & Code

MongoDB integriert Vektorsuche direkt in die Datenbank


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

MongoDB stellt seine Volltextsuche und Vektorsuche nun allgemein für selbst verwaltete Installationen bereit. Die Funktionen sind sowohl für MongoDB Enterprise Advanced als auch für die Community Edition verfügbar. Entwickler können damit Suchabfragen, semantische Suche und hybride Suchverfahren direkt in ihrer Datenbank nutzen, ohne eine separate Suchplattform mit eigener Datensynchronisation betreiben zu müssen.

Weiterlesen nach der Anzeige

MongoDB ist eine dokumentenorientierte NoSQL-Datenbank, die JSON-ähnliche BSON-Dokumente speichert. Sie wird häufig für Anwendungen mit flexiblen Datenmodellen eingesetzt und ist sowohl als Cloud-Dienst MongoDB Atlas als auch für den Eigenbetrieb erhältlich. Bislang standen einige der erweiterten Suchfunktionen vor allem in Atlas zur Verfügung.

Laut der Ankündigung erreichen die Suchfunktionen in selbst verwalteten Umgebungen nun Funktionsparität mit MongoDB Atlas. Unterstützt werden unter anderem die Aggregationsstufen $search, $searchMeta, $vectorSearch, $rankFusion und $scoreFusion. Dadurch lassen sich klassische Volltextsuche und semantische Vektorsuche in einer gemeinsamen Abfrage kombinieren.

Während die Volltextsuche Dokumente anhand von Schlüsselwörtern und sprachabhängigen Merkmalen durchsucht, vergleicht die Vektorsuche numerische Repräsentationen von Inhalten, sogenannte Embeddings. Dadurch lassen sich auch inhaltlich ähnliche Dokumente finden, selbst wenn sie andere Begriffe verwenden. Eine hybride Suche verbindet beide Verfahren und kann so sowohl exakte Treffer als auch semantisch passende Ergebnisse liefern. Solche Ansätze kommen unter anderem in RAG-Systemen (Retrieval-Augmented Generation) zum Einsatz, bei denen Sprachmodelle externe Wissensquellen in ihre Antworten einbeziehen.

MongoDB integriert außerdem eine automatische Erzeugung von Embeddings auf Basis der Modelle von Voyage AI. Entwickler müssen die Vektoren damit nicht mehr selbst außerhalb der Datenbank erzeugen und synchronisieren. Laut MongoDB erfolgt die automatische Embedding-Erstellung derzeit über einen von MongoDB gehosteten Dienst von Voyage AI. Zusätzlich stehen sogenannte Reranker zur Verfügung, die Suchergebnisse nachträglich neu bewerten und in eine relevantere Reihenfolge bringen sollen.

Der Anbieter sieht die Neuerungen vor allem als Baustein für KI-Anwendungen wie Chatbots, Empfehlungssysteme oder KI-Agenten. Statt Daten zwischen Datenbank, Suchmaschine und Vektor-Datenbank zu replizieren, sollen sich Such- und KI-Workloads innerhalb derselben Plattform umsetzen lassen. Die Suchtechnologie basiert dabei auf Apache Lucene.

Weiterlesen nach der Anzeige

In der Community Edition stehen Such- und Vektorsuche ab MongoDB 8.2 ohne zusätzliche Lizenzkosten unter der Server Side Public License (SSPL) zur Verfügung. Die Funktionen laufen in einem separaten Prozess namens mongot, der parallel zum eigentlichen Datenbankprozess mongod betrieben wird. MongoDB hat den Quellcode von mongot nach eigenen Angaben ebenfalls unter der SSPL veröffentlicht.

Für Enterprise-Kunden werden die Suchfunktionen als kostenpflichtige Erweiterung von MongoDB Enterprise Advanced angeboten. Für Kubernetes-basierte Installationen erfolgt die Bereitstellung über MongoDB Controllers for Kubernetes (MCK), sodass sich Such- und Vektorsuche in Kubernetes-basierte On-Premises-, Private-Cloud- oder Hybrid-Cloud-Umgebungen integrieren lassen. Nach Angaben des Herstellers richtet sich das Angebot insbesondere an Unternehmen mit regulatorischen Anforderungen oder isolierten Infrastrukturen, die KI-Anwendungen vollständig unter eigener Kontrolle betreiben möchten.


(fo)



Source link

Weiterlesen

Entwicklung & Code

software-architektur.tv: Johannes Link und der Anti-GenAI-Aktivismus


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.

Weiterlesen nach der Anzeige

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.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

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)



Source link

Weiterlesen

Entwicklung & Code

Supreme Court überprüft Apples Missachtung des Epic-Gerichts


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Apple hat in seinem Spiel auf Zeit einen neuerlichen Etappensieg erzielt: Das US-Höchstgericht (Supreme Court of the United States, SCOTUS) nimmt einen Teilaspekt des Komplexes Epic v Apple zu Überprüfung an. Grundsätzlich geht es in dem seit fast sechs Jahren laufenden Rechtsstreit um wettbewerbsfeindliche Praktiken in Apples App Store für iOS und iPadOS. Der vom SCOTUS angenommene Teil dreht sich darum, dass Apple eine Entscheidung eines Bundesbezirksgerichts dem Geiste nach umgangen hat, indem es App-Anbietern prohibitive Gebühren verrechnet und andere nachteilige Auflagen macht.

Weiterlesen nach der Anzeige

Das hat das Bundesbezirksgericht für den Norden Kaliforniens als Missachtung des Gerichts eingestuft, was vom zuständigen Bundesberufungsgericht auch bestätigt worden ist. Doch Apple argumentiert, Missachtung sei nur bei Umgehung sehr konkreter Gerichtsbefehle möglich, nicht bei Umgehung des grundsätzlichen Tenors einer Gerichtsentscheidung. Mit diesem Vorbringen hat der Konzern das Interesse von mindestens vier der neun SCOTUS-Richter geweckt. Sie haben beschlossen, die Sache zu prüfen.

Damit gewinnt Apple weiter Zeit und kann seine Geschäftspraktiken fortführen. Frühester Termin für die mündliche Verhandlung wäre Oktober; bis zur Entscheidung könnte ein ganzes Jahr vergehen. Und dann geht die Sache womöglich zurück an ein untergeordnetes Gericht.

Apple hat in seinem App Store für iOS und iPadOS seit jeher hohe Gebühren verrechnet, typischerweise 30 Prozent aller Kundenzahlungen. Gleichzeitig untersagte Apple Umsätze außerhalb des App Store, direkte Kommunikation mit Kunden über andere Kanäle, und den Betrieb alternativer Appstores für die mobilen Apple-Betriebssysteme. Als Epic Games in seinem Spiel Fortnite Apples teures Bezahlsystem zu umgehen suchte, sperrte Apple Fortnite aus.

Daraufhin zog Epic im August 2020 vor das US-Bundesbezirksgericht für den Norden Kaliforniens. Dieses entschied im September 2021, dass Apples Bestimmungen zwar nicht gegen Monopolrecht des Bundes, wohl aber gegen ein kalifornisches Gesetz gegen Unlauteren Wettbewerb verstoßen. Das Gericht trug Apple auf, Hyperlinks aus Apps auf externe Webseiten mit unabhängigen Bezahlsystemen zu erlauben.

Apple berief erfolglos, und konnte auch den Supreme Court nicht zu einer weiteren Überprüfung gewinnen. Schließlich gelobte der Konzern, sich an die rechtskräftigen Auflagen zuhalten.

Weiterlesen nach der Anzeige

Tatsächlich legte Apple sein neues System jedoch so an, dass niemand es nutzen würde: Erlaubt ist darin nur ein einzelner Hyperlink, der nicht als solcher erkennbar sein darf. Die aufgerufene Seite darf keine Informationen über den Kunden oder sein Konto übernehmen, sondern muss das neu abfragen. Dazu kommen abschreckende Einblendungen und eine Gebühr von 27 Prozent aller Umsätze. Weil der Betrieb eines externen Bezahlsystems auch etwas kostet, und Finanzdienstleister Gebühren erheben, wäre der Umsatz außerhalb des App Store noch teurer als die 30 Prozent direkt im App Store.

Die Sache war also prohibitiv, was, wie sich später vor Gericht herausgestellt hat, Absicht war. Nebenbei schloss Apple alle Teilnehmer seines Video Partner Program und seines News Partner Program generell von externen Umsätzen aus. Eine sachliche Grundlage dafür ist nicht erkennbar.

Epic musste wieder das Bundesbezirksgericht anrufen. Dieses prüfte Apples Vorgehen ausführlich und hörte mehrfach Zeugen, bis es schließlich auf Missachtung des Gerichts entschied. Apples Argument, die ursprüngliche Gerichtsentscheidung hätte die gesetzten Maßnahmen nicht konkret verboten, zog nicht.

Das Bezirksgericht erließ diesmal detailliertere Auflagen, darunter ein absolutes Verbot von Gebühren für außerhalb des App Store anfallende Umsätze – nicht nur gegenüber Epic, sondern gegenüber allen App-Anbietern im US App Store. Apple berief erneut. Bundesberufungsgericht befand Ende 2025 (Az. 25-2935), dass Teile der neuen Auflagen zu streng seien: Beispielsweise dürfe Apple sehr wohl Gebühren für externe Umsätze berechnen, bloß nicht in prohibitiver Höhe.

Grundsätzlich habe das Bezirksgericht jedoch zulässig festgestellt, dass Apple durch sein Vorgehen das Gericht missachtet habe. Zwei Gerichtsauflagen habe Apple dem Buchstaben nach verletzt, zwei weitere dem Geiste nach.

Gegen diese Entscheidung des Bundesberufungsgerichts hat Apple den Supreme Court angerufen und ihm zwei Fragen zur Erörterung vorgeschlagen: Erstens, ob Missachtung des Gerichts überhaupt gegeben sein könne, wenn eine Entscheidung nur ihrem Geiste nach umgangen werden, nicht aber ihren Buchstaben nach. Diese Frage hat das Höchstgericht am Dienstag angenommen.

Zweitens wollte Apple diskutieren, ob das Bundesbezirksgericht überhaupt landesweite Verbote, gestützt auf das Recht eines US-Staates, aussprechen darf, die auch Personen betreffen, die am Verfahren gar nicht beteiligt sind (hier: alle Anbieter von Apps im App Store). Diese Frage hat das Höchstgericht nicht angenommen. Es begründet seine Entscheidungen über Annahme oder Nichtannahme generell nicht.

Das Verfahren vor dem Supreme Court heißt Apple v Epic Games und trägt das Az. 25-1311. Das US-Bundesbezirksgericht für den neunten US-Gerichtskreis führt Epic Games v Apple unter den Az. 21-16506 und 21-16695, während das Bundesbezirksgericht Epic Games v Apple unter 4:20-cv05640 veraktet.


(ds)



Source link

Weiterlesen

Beliebt