Consumers must be fed.

Je trouve cet article (en anglais, mais non technique) concernant le développement de logiciels libres très intéressant, surtout sachant que pour beaucoup de couches dont la majorité des programmes dépendent, il s’agit d’un “unpaid hobby project”. Cet article pourrait correspondre à de nombreux domaines de notre société aussi (éducation, santé, …).

L’un des plus importants problèmes vient de toutes ces géantes entreprises qui gagnent un fric fou sans payer leurs parts justes.

EDIT : rajout de liens pour contexte :

• “FAQ on the xz-utils backdoor (CVE-2024-3094)” par Sam James (en anglais) https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
• “XZ utils backdoor” sur Wikipedia (en anglais) https://en.wikipedia.org/wiki/XZ_utils_backdoor

La philosophie de “l’open source” ne touche ainsi pas que le monde de l’informatique, et c’est une très bonne chose.

Mais par contre, comme indique l’article à travers l'inquiétude des écuries sur « un système où le curseur vers la standardisation serait poussé trop loin », forcer ou simplement précipiter les choses n’est pas une bonne approche.
Je crains que l’origine de la demande, qui est ici la « standardisation des pièces de F1 », ne se transforme en « standardisation de facto » ; ainsi, l'écurie la plus imposante ou la plus rapide proposera ou forcera ses modèles de pièces, basés sur ses besoins ou sur son travail déjà présent, plutôt que de voir des modèles plus performantes ou plus économes mais qui demanderont un travail d'adaptation à ces premières (sans oublier la chaîne de fabrication et de montage, avec formation des techniciens, etc).
Et ainsi, la standardisation serait ici un frein à l’innovation.

« L’enfer est pavé de bonnes intentions. »

Très intéressant comme produit, à voir ça de plus près.

Un article intéressant sur les problèmes que nous risquons encore de rencontrer, à se reposer uniquement sur un seul et unique outil, le tout sur un réseau centralisé, sans oublier que ce dernier est basé sur un logiciel propriétaire.

De mon côté, principalement parce que mes projets ne concernent que moi, je m'efforce d'autohéberger mes propres projets, puis d'utiliser le gestionnaire de sources Mercurial, pas par esprit de contradiction, mais parce que je trouve que cet outil répond tout à fait à mes besoins (je n'ai pas réussi à voir les différences concrètes entre git et mercurial).

Pour un peu plus de détails, voici un petit résumé, basé sur mes connaissances et sur l'ensemble des sources que j'ai lues :

« Heartbleed » est une faille concernant un module d'OpenSSL nommé « HeartBeat », découverte ce lundi 7 avril 2014 ; elle touche certaines versions d'OpenSSL, la branche 1.0.1a à 1.0.1f ainsi que la béta 1.0.2 (1.0.1g corrige cette faille, ainsi que la prochaine monture de la béta).
Toutefois, OpenSSL n'est pas concerné pour les versions en 0.9 ou en 1.0.0, ni les systèmes qui n'ont pas ce module de compilé (sous Gentoo, le module HeartBeat est désactivable).

Cette faille s'inscrit au niveau de TLS (“Transport Layer Security” https://en.wikipedia.org/wiki/Transport_Layer_Security), car le rôle de HeartBeat est de maintenir un “keepalive” au niveau de la session TLS ; ce keepalive permet en autre d'éviter de devoir refaire une renégociation avec une « poignée de mains » (“handshake”), qui est peut être assez lourd en terme de quantité de données échangées et aussi en calculs cryptographiques.
Cette faille permet donc de récupérer une petite quantité d'informations, jusqu'à 64ko de mémoire avec une simple requête, ce qui permet donc théoriquement de récupérer les clefs privées stockées en mémoire et ainsi déchiffrer les communications. D'autres informations peuvent fuiter, comme directement des mots de passe, ou des messages, c'est bien pour ces raisons qu'il est conseillé de mettre à jour vos mots de passe, et pour les administrateurs des services, de générer de nouvelles clefs de chiffrement.

Or, pourquoi autant de serveurs fonctionnent-elles avec ces versions 1.0.1 de OpenSSL ? Car ces versions ont d'implémentée la version 1.2 de TLS. Et vu qu'OpenSSL est très répandu dans le monde du logiciel libre et des serveurs, la faille est ainsi très répandue – on parlerait de deux tiers des services web.

Mais qu'en est-ils des autres services ?
Oui, d'autres services se basant sur l'implémentation de TLS d'OpenSSL, comme emails, XMPP, etc. font du TLS. Cependant, OpenSSH n'utilise pas le protocole TLS pour échanger des données, mais son propre protocole ; OpenSSH se base sur OpenSSL, pas pour le TLS, mais pour les algorithmes de chiffrement.

Comme le dit Bruce Schneier : “"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.”
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Pour plus de lectures, quelques infos sur la normalisation de l'extension HeartBeat dans la RFC 6520 https://www.bortzmeyer.org/6520.html, des infos techniques sur la faille http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html, une critique de Theo de Raadt sur OpenSSL http://thread.gmane.org/gmane.os.openbsd.misc/211952/focus=211963, encore là sur Numérama http://www.numerama.com/magazine/29026-heartbleed-que-faut-il-craindre-de-cette-faille-openssl.html et sur PCINpact http://www.pcinpact.com/news/86941-heartbleed-openssl-et-question-securite-expliques-simplement.htm et enfin l'info depuis le ministère de la défense. http://cert.ssi.gouv.fr/site/CERTFR-2014-AVI-156/

Et vive OSM :-)

Ah ouais, tout de suite, on voit que le principal but de Google, et donc de Chrome, c'est de détruire Apple, vu que WebKit est aussi utilisé par Safari, le navigateur web d'Apple.

La section 1.10 m'a choqué, faire exprès de détruire la compatibilité avec WebKit, et être sûr que Google sera le seul à pouvoir contribuer au projet ... Lamentable.

(via le Hollandais Volant http://lehollandaisvolant.net/index.php?mode=links&id=20130405113822)

@TODO
Franchement, ça me serait bien pratique, car mutt en ligne de commande, c'est bien, mais bon …
(Encore mieux, ce serait de faire ça en IMAP, pour pouvoir les lire avec un vrai client :-D)

À jouer !