Google pflegt schon einige Zeit einen Satz eigener Patches für OpenSSL. Die in Googles Browser Chrome verwendete Mozilla-SSL-Technik (NSS) will das Unternehmen ersetzen. Jedoch fließen nicht alle Patches in die offizielle Entwicklung zurück. Google-Mitarbeiter Adam Langley schreibt in seinem Webblog, dass ein Teil der Änderungen sich nicht mit den Versuchen der OpenSSL-Entwickler verträgt, ABI und API stabil zu halten. Google selbst schätzt manche als zu experimentell ein.

Google-Projekte wie Android und Chrome greifen andererseits zunehmend auf die Google-Ergänzungen zurück. Daher blieb von der Heartbeat-Lücke Android zumeist verschont. Deshalb haben sich die Entwickler entschlossen, die Art und Weise zu ändern, in der sie die Ergänzungen realisieren: Bisher wurden diese an eine neue OpenSSL-Version angepasst (Rebase). Statt dessen wollen sie Änderungen an OpenSSL zukünftig in die eigene Code-Basis einpassen.

Neben LibreSSL und OpenSSL ensteht dadurch die dritte SSL-Implementierung mit dem Namen BoringSSL. Allerdings soll die Google-Variante anders als LibreSSL nicht als 1:1-Ersatz dienen. An den OpenSSL-Entwickler will Google weiterhin Korrekturen zurückgeben und mit den LibreSSL-Entwicklern eng zusammenarbeiten. Unter ISC-Lizenz soll der Code stehen (einer abgewandelten BSD-Lizenz, unter anderem für OpenBSD und BIND).

Auf googlesource.com gibt es bereits den BoringSSL-Code als Git-Repository. Der Code soll demnächst auch Bestandteil des Chromium-Repositorys werden, später auch von Android und Teil weiterer interner Projekte, berichtet Google-Entwickler Langley in seinem Blog. Der SSL-Fork soll OpenSSL auch langfristig nicht ersetzen.

(ts, hannover)

(siehe auch Heise-News-Ticker:)

Hannover · EDV-Beratung · Linux · Novell · Microsoft · Seminar · IT-Consult · Netzwerk · LPIC · CLE