Felix benutzt eh nie OpenSSL als Bibliothek, sondern bestenfalls mal das Kommandozeilenwerkzeug, um irgendwas zu konvertieren.

Der ganze Gnome-GTK-GLib-Desktoplinux-Stack benutzt natürlich GnuTLS.

>>155987
Aber könnte das UEFI dem Windows-Installer nicht erzählen, dass es leider kein BitLocker versteht, sodass sich Windows zunächst unverschlüsselt installiert, dann seinen Foo machen, und abschliessend Windows dann erklären, dass der User jetzt doch die Funktionaliäten für Bitlocker aktiviert habe und Windows sich jetzt doch verschlüsseln darf?
Auch: Installiert sich Windows überhaupt standardmässig mit Bitlocker aktiviert? Oder wird das erst nach dem ersten Boot (oder während des Reboots bei der Installation) eingeschaltet?

WolfSSL ist sogar GPL. Das kann man den Debianern bestimmt schmackhaft machen.

> wolfSSL, wolfCrypt, wolfMQTT, wolfTPM, wolfBoot, and wolfSentry software are free software downloads and may be modified to the needs of the user as long as the user adheres to version two of the GPL License. The GPLv2 license can be found on the gnu.org website (http://www.gnu.org/licenses/old-licenses/gpl-2.0.html).

Was soll das Multifredding? Warum macht man nicht für jeden Client einen eigenen Prozeß? Die Daten sollten doch eh getrennt sein.

>>155994
Steht doch über dir: WolfSSL verwenden

>>155991
Secure Boot mit Machine Owner Key beste.

Wie inzu OpenSSL ersetzen auf Luniks?

Ja geil. Was ist Btrfs eigentlich für ein Schrott? Sollte das nicht super resilient sein mit seinen Prüfsummen und dem ganzen Scheiß?

Felix hat das gute Abschneiden von WolfSSL überrascht, das hat Felix immer nur von OpenWrt gekannt. "Läuft schnell auf Embedded" muss nicht unbedingt mit "läuft schnell auf fettem 64-Kern-Servierer" korrelieren.

Für Felix sind die Bankmarken aber weniger relevant, weil Felix vielleicht mal 5 SSL-Verbindungen pro Sekunde aufmacht. Da wäre geringe Komplexität und dennoch Unterstützung für 0-RTT wichtiger, traurige LibreSSL-Geräusche hier einfügen.

>>155986
UEFI hat nen kompletten netzwerkstack. Darum sollte im netzwerk UEFI Traffic im eigenen VLAN geroutet werden und man sollte IMMER Secure Boot einschalten, damit blos keiner mehr modifizierte Betriebssysteme verwendet. Sonst wirst du preboot gehackt.

Bootkits gibt es auch für Linux. Wahrscheinlich hängen schon etliche in Botnetzen ohne es zu merken, weil sie nicht wissen, dass sie selbst in einer gehackten VM auf ihrem eigenen Rechner sind

>As I expected, the website uses RPC to talk to the background process running on my system.
Was könnte schief gehen?

Oh wow, es lebt!

>>155985
>Ich benutze Arch nebenbei.
Tut dieser Felix auch seit >10 Jahren, dachte deshalb eigentlich, er hätte inzwischen seinen Skill genug hochgelevelt für Gentoo. Aber dann hatte Felix gestern wieder das gleiche Problem wie damals beim ersten Versuch vor über 10 Jahren: Alles eingerichtet und dann wollte das System nicht starten.

Felix hat den Fehler jetzt aber gefunden: Er hatte in der Kommandozeile des Kerns root=PARTUUID="xyz" stehen statt root=PARTUUID=xyz. In irgendeinem Beispiel stand es mit Anführungszeichen und Felix hatte das nicht weiter hinterfragt, aber anscheinend kommt der Kern damit nicht klar und dann gibt es irgendeine nichtssagende Fehlermeldung beim Stiefeln.

Ein weiteres Problem, das Felix allerdings gestern schon erkannt und gelöst hatte, war, dass der Gentoo-Kern anscheinend immer noch nicht standardmäßig die Virtio-Module enthält. Das war damals vor über einem Jahrzehnt wohl auch das Problem. In jeder anderen kack Distribution funktionioniert das out-of-the-box, sogar mit verschiedenen BSDs. Gentoo und Fenster sind die einzigen Betriebssysteme, die Felix kennt, bei denen man die Treiber erst noch manuell installieren muss. Ist ja auch ein total ungewöhnlicher Anwendungsfall, dass man ein Betriebssystem in einer VM installieren möchte...

>>155986
Aber selbst auf Fenster gibt es BitLocker (und Secure Boot), so dass ein paar Dateien auf die System-Platte zu schreiben nicht drin ist (gut, man kann auf unverschlüsselte EFI-Partition schreiben). Der Bootloader bootmgfw.efi gibt dabei nach dem Entsperren die Ausführung nicht wieder ans UEFI zurück, sondern es wird der Kernel ausgeführt.

>>155977
Das UEFI könnte natürlich vor dem Stiefeln eine Flagge auf der zu stiefelnden Partition prüfen, und wenn diese nicht da ist, dort einfach seinen Rotz in die richtigen Ordner schieben und ein paar Konfigurationsflaggen umbiegen. Also nicht Fenster sagen "hier, installier das mal", sondern einfach seine Sachen Fenster von hinten einführen.

Ich benutze Arch nebenbei.

>>155962
Vielleicht ist dir auch einfach so oft der Arsch ausgeblasen worden, dass niemand mehr Bock auf diese ewig gleiche und sinnlose Diskussion hat, da du inhaltlich keine Punkte bringst und nur der russischen Regierung nachplapperst.

>>155982
Mit einem Schenker-Gaming-Laptop wäre das nicht passiert.

>>155979
>Oder dieses UI kommt einfach mit irgendeinem Treiber für das ASUS-Mainboard mit
Mmmh, das wäre ja noch doller. Die Treiber-Liste scheint wenigsten direkt die Treiber von den Geräteherstellern aufzulisten:
https://www.asus.com/us/motherboards-components/motherboards/tuf-gaming/tuf-gaming-b850-plus-wifi/helpdesk_download

Aber deine Hypothese gibt Felix Blitzzurücks an die Zeit, als Notebook-GPU-Treiber noch vom Notebook-Hersteller kamen, und nicht von Nvidia/Ati, und dann mit Tools letztere Treiberpakete erst installierbar machen musste (weil es vom Notebook-Hersteller natürlich nach 12 Monaten pünktlich zum nächsten Notebook-Modell keine Aktualisierungen mehr gab).

Nicht wirklich überraschend. Scheint aber etwas alt. Debian bekommt dieses Jahr schon OpenSSL 3.5.x.