News OpenBSD spaltet sich mit LibreSSL von OpenSSL ab

DocWindows · 23. April 2014

@Creeed: Ich lese da nur dass er sich über vermeintliche Unzulänglichkeiten aufregt obwohl er noch gar nichts verstanden hat und dieses dann im Update im Nachhinein noch damit relativiert dass die Lösung die es da gibt seiner Meinung nach auch nix taugt. Und im zweiten Blogpost wirds noch peinlicher, weil er behauptet es gäbe in Windows keinen Zufallszahlengenerator in der Krypto API. Er hätte lieber schreiben sollen dass er es nicht weiß, und nicht dass es ihn nicht gibt. Interessant finde ich das nicht wirklich. Ist eher so die Kategorie facepalm.

PunGNU · 23. April 2014

0Maruja0 schrieb:
Ich sehe nicht wo dadurch weniger Betriebssysteme unterstützt werden sollen als mit OpenSSL.

Ziel von LibreSSL ist eine minimalistische SSL Implementierung. Wie du schon selbst festgestellt hast, hat dies mehr Vor- als Nachteile: Der overhead beim Supporten alter oder sinnloser Plattformen (Windows wegen eigener Implementierung) kann entfernt werden. Die API wird übersichtlicher, besser wattbar und somit bugfreier. Third-Party anbietet, welche SSL auf Ihrer Architektur brauchen können dank Open-Source und POSIX Kompatibilität LibreSSL einfach Portieren. Die offizielle Unterstützung weniger Architekturen zu Gunsten einer sauberen Architektur ist in diesem Fall erklärtes Ziel des Forks.

craine · 23. April 2014

Daaron schrieb:
Es ist Schwachsinn, das ist alles. Erst kegeln sie allen Kompatibiltitäts-Code raus, dann wollen sie "Spenden" dafür, den Code wieder einzubauen. Ein Schelm, wer Böses dabei denkt.

Das habe ich nirgens gelesen.

Daaron schrieb:
So etwas läuft am Ende eh nur auf einen Forking-Wettstreit raus, bei dem dann jeder sein eigenes Süppchen kocht und alles auseinander driftet.

+1
Da kommts auf eins mehr auch nicht an

PunGNU schrieb:
Ziel von LibreSSL ist eine minimalistische SSL Implementierung. ... Die API wird übersichtlicher, besser wattbar und somit bugfreier. ... Die offizielle Unterstützung weniger Architekturen zu Gunsten einer sauberen Architektur ist in diesem Fall erklärtes Ziel des Forks.

So sehe ich das auch

Daaron · 23. April 2014

PunGNU schrieb:
(Windows wegen eigener Implementierung) kann entfernt werden.

Aha, und wenn ich jetzt FOSS schreibe und in selbige die Bibliothek einbetten will, um 100% FOSS zu bleiben? Dann kann ich die Windows-API nicht verwenden... und WILL ich evtl auch gar nicht.

craine schrieb:
Das habe ich nirgens gelesen.

http://www.libressl.org/

Multi OS support will happen once we have
...
A Stable Commitment of Funding to support an increased development and porting effort.

etking · 23. April 2014

flappes schrieb:
Das System basiert nunmal auf Vertrauen. Wer Honest Achmed vertraut, der ist nunmal selber Schuld.

Jede Zertifizierungsstelle arbeitet prinzipiell wie Honest Achmet und seine Brüder und Onkel. Es gibt keinerlei Sicherheit und Kontrolle. Einbrüche werden nicht gemeldet, kriminelle Handlungen der Zertifizierungsstellen können nicht ausgeschlossen oder entdeckt werden. In den USA ansässige Firmen müssen alle Root-Zertifikate und privaten Schlüssel rausrücken. Fremde Staaten können sich als Goolgle, Facebook oder sonstwer ausgeben, wie vielfach schon geschehen, z.B. im Iran. Das ganze System ist völlig kaputt.

Jesaa · 23. April 2014

etking schrieb:
Das ganze System ist völlig kaputt.

Nein wir kommen nur wieder dahin zurück wo wir vor 100 Jahren waren. Die Staaten holen sich halt ihr Informationsmonopol mehr oder weniger wieder zurück. Ne Zeitung ist auch nur solang unabhängig, wie niemand sie kontroliert. Wenn jemand die Zensur einführt, wars das auch mit Unabhängigkeit. Das selbe setzt sich halt jetzt auch im Internet durch.

@PunGNU: Das heist aber dann dass du am ende 100000 Impelemtierungen für alles und jeden hast. Das ist am Ende nicht übersichtlicher, nur dass die Schuldfrage, wenn was schief geht, einfacher abzuschieben ist. Die Referenzimplementierung war ja sauber, nur halt die in deinem Gerät nicht.

Andererseits ist dann auch nicht jedes Gereät betroffen, wie das bei Heartbleed der Fall war/ist.

Wie gesagt, es wird für den Endanwender nur noch unübersichtlicher, weil welches Gerät hat jetzt ne Saubere Implementierung?

M-X · 23. April 2014

Ich denke das jetzt ein paar unternehmen bei der OpenSSL Endwicklung einsteigen werden. Es ist einfach zu verbreitet um es fallen zu lassen und auch zu wichtig! Das Forken finde ich persönlich nicht gut, aber es steht ja jedem offen das zu tun.

DasBoeseLebt · 23. April 2014

http://opensslrampage.org/

Herrlich. Fork/Neuanfang zu recht.

TheK · 23. April 2014

Netter Ansatz – OpenSSL steht in dem Ruf, gerne mal das Rad neu zu erfinden und daher eben ein riesiger Code-Molloch zu sein, der kaum zu warten ist. Und ob seiner Sicherheits-Brisanz muss eine solche API eigentlich wirklich fehlerfrei sein… In der aktuellen Version hat man die Codebasis schonmal halbiert – und das nur im Schnelldurchgang, indem man tote Funktionen rausgeworfen hat. Ich vermute, dass sich das ganze am Ende mindestens nochmal halbieren lässt. Und *dann* kann man da mal sinnvolle Code-Reviews machen.

Marco^^ · 24. April 2014

SO erklärt ARD Ratgeber Internet den Heartbleed bug ... (Volkverdummung)