Je suis tombé sur un article d'un ingénieur de Google qui annonce qu'ils vont maintenir leur propre branche/fork d'open ssl.
Yet Another Fork, pourquoi ?
Jusqu'ici, Google devait maintenir pas moins de 70 patches différents par rapport à la version d'openssl qui acceptait très peu de choses étant donné les contraintes fortes qu'ils se mettaient en terme de compatibilité source et binaire. La situation était un peu ingérable pour Google qui devait maintenir ses 70 patches à part à chaque fois que le projet openssl mère était mis à jour. Et Google n'a pas les contraintes qu'a openssl, ni même libressl : pour eux avoir une faille de sécurité dans leurs produits ayant des centaines de millions d'utilisateur est un problème bien plus énorme que de devoir passer un coup de fil pour demander aux développeurs de Android AOSP et Chromium de mettre à jour le code source et recompiler en fonction du changement qu'ils viennent d'implémenter.
Du coup ils changent de modèle : tous les projets Google vont migrer vers BoringSSL, et Boring SSL s'occupera de réintégrer et de synchroniser les patches pertinents avec OpenSSL ou LibreSSL
There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project. We will still be sending them bug fixes when we find them and we will be importing changes from upstream. Also, we will still be funding the Core Infrastructure Initiative and the OpenBSD Foundation.
But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us. We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.
(Note: the name is aspirational and not yet a promise.)
# OpenSSL forké également par Google
Posté par jean-michel.bertrou.eu . En réponse au journal LibReSLL déjà dans les bacs !. Évalué à 7.
Je suis tombé sur un article d'un ingénieur de Google qui annonce qu'ils vont maintenir leur propre branche/fork d'open ssl.
Yet Another Fork, pourquoi ?
Jusqu'ici, Google devait maintenir pas moins de 70 patches différents par rapport à la version d'openssl qui acceptait très peu de choses étant donné les contraintes fortes qu'ils se mettaient en terme de compatibilité source et binaire. La situation était un peu ingérable pour Google qui devait maintenir ses 70 patches à part à chaque fois que le projet openssl mère était mis à jour. Et Google n'a pas les contraintes qu'a openssl, ni même libressl : pour eux avoir une faille de sécurité dans leurs produits ayant des centaines de millions d'utilisateur est un problème bien plus énorme que de devoir passer un coup de fil pour demander aux développeurs de Android AOSP et Chromium de mettre à jour le code source et recompiler en fonction du changement qu'ils viennent d'implémenter.
Du coup ils changent de modèle : tous les projets Google vont migrer vers BoringSSL, et Boring SSL s'occupera de réintégrer et de synchroniser les patches pertinents avec OpenSSL ou LibreSSL
https://www.imperialviolet.org/2014/06/20/boringssl.html
https://boringssl.googlesource.com/boringssl/