J'ai vu qu'il y a un .o dispo dans le mail d'origine: https://www.openwall.com/lists/oss-security/2024/03/29/4 et le mail dit: "Florian Weimer first extracted the injected code in isolation, also attached, liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks!"
La backdoor était sous la forme de code binaire caché dans les données de test, donc il n'y a que le .o pour le moment. Je ne doute pas que dans quelque jours, quelqu'un va coller le dump en assembleur avec une analyse. Il y a 87 ko de code compilé, avec du code existant, donc ça doit pas être non plus trop gros.
Il y a une version dans le thread avec plus de symboles, ça peut aider pour le débogage.
pour savoir si sshd dépend de liblzma, et savoir si la vulnérabilité est potentiellement présente.
Modulo le fait que pam charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine). Et que libsystemd aussi depuis 1 mois, comme l'a souligné Lennart P sur HN à un moment.
Quand je lit les commentaires sur la sophistication de la backdoor, et le fait que l'attaquant a visé spécifiquement les paquets de distros, ainsi que d'autres libs, je pense que la cible n'était pas sshd.
Je pense que l'idée était de rajouter une backdoor pour signer des paquets rpms/debian avec une clé arbitraire. Ça expliquerait pourquoi il y a eu un souci avec sshd, car l'attaquant n'avait pas du tester ce cas de figure (vu que la dépendance est transitive via systemd, et ça ne semble être actif que via des options bien spécifiques).
mais liblzma est utilisé aussi par librpm et par dpkg. Le fait de modifier des trucs du coté des fonctions RSA me fait penser aux signatures des paquets, et ça me semble plus probable, ça laisse moins de trace.
Il y a eu des discussions ici et ici, mais je pense que c'est plus parce que Madelyn Olson s'est focalisé sur trouver un endroit ou mettre le projet (eg, la LF) pour faire collaborer les industriels (eg, AWS, Alibaba, Google, etc) alors que Drew a juste dit "fuck it, qui m'aime me suive" et il est parti sur Codeberg, un point que je trouve assez discutable.
Je suppose qu'implicitement, il y a aussi le coté un peu rugeux du dit Drew (je sais pas ce qu'il a fait, mais j'ai eu plusieurs échos).
Comme le souligne Madelyn, la LGPL ne change rien pour les boites qui proposent du Redis en tant que service hébergé, donc je trouve ça assez curieux de dire que ça ne leur convient pas.
Oui, je dit parfois que le logiciel libre est la par le surplus de productivité de certaines personnes. On a du code libre parce qu'il y a des bénévoles, on a du code libre parce qu'on a des gens payés qui sont plus productif en reprenant du code libre qu'en codant de 0 (tout les softs écrit par des admins de facs, surtout au début, mais aussi sans doute l'embarqué d'une manière général). Et la, ton exemple rentre aussi la dedans, on a du code libre par les hyperscaleurs parce qu'ils ont du coder ça de toute façon, donc autant le libérer.
Mouais, ensuite, si tu regardes la timeline de tout ça, c'est plus compliqué.
Redis le projet (2009) est plus ancien que Redis l'entreprise (ex Redis-labs) qui a été crée en 2011 sous le nom Garantia Data par 2 entrepreneurs, aucun n'étant fondateur de Redis le projet. Le créateur n'a rejoint Redis l'entreprise qu'en 2015 (après avoir quitté pivotal, si je me souviens bien), et il a quitté la boite en 2020.
AWS propose AWS Elasticache depuis… 2011 avec un support de Redis depuis septembre 2013 (et Memcached avant). Redis la boite/Redislabs/Garantia Data ont sorti leur offre plus tôt (février 2013), mais c'était pas les seuls sur le marché, vu que Myredis, qu'ils ont achetés en octobre 2013, proposait déjà le même service en 2012 en beta, et en février 2013 en GA ( cf la date de https://news.ycombinator.com/item?id=5294122 ). Donc à quelques mois prêt, tout le monde a eu la même idée (vu que Garantia Data avait aussi une offre de SaaS pour Memcached, soit la même chose qu'AWS, quelques temps après AWS).
Je veux bien dire du mal d'Amazon, mais quand Garantia Data a décidé de se renommer en Redislabs puis en Redis puis de prendre du capital risque 7 ou 8 fois d'affilés pour devenir éditeur, ils savaient qu'AWS était la depuis le début, et ils n'avaient pas trop l'excuse d'avoir fondé le projet eux même vu qu'ils ont fondé la boite puis décidé de devenir le sponsor principal pour rajouter des plugins pour leur business modéle de l'époque (aka, la marketplace) .
La boite aurait parfaitement pu être comme la plupart des boites qui font du support sur Postgresql et du consulting, mais c'est pas le choix qui a été fait, sans doute parce qu'à un moment, faut avoir du ROI.
Redis la boite a choisi de faire de l'édition son gagne pain, sans doute parce que ça rapporte plus que les autres types de gagne pain. Et quand ils ont fait ce choix, AWS et co était déjà la. Donc bon, ils ont tentés de jouer gros, et visiblement, ils n'ont pas gagner.
Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).
Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.
J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.
Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.
Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.
Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.
Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.
Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).
Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.
c'est très pratique pour mettre en place un environnement de développement qui n'affecte pas le reste du système.
À condition de lancer pip/npm/etc en root, car si tu passes par toolbox (qui est l'outil de moindre résistance), tu va partager le /home. Je suppose que ça dépend de ce que tu appelles "environnement de développement", vu que ça va des compilos aux config des éditeurs de code en passant par les libs dispos.
Après, ça signifie que certaines applications ont du mal à fonctionner.
Le fait de ne pas pouvoir facilement lancer tcpdump ou des outils bas niveau de ce genre dans un conteneur (notamment celui de toolbox) font que je pense que je repasserait sur une distro normal pour mon prochain PC.
Je peux avoir toolbox et flatpak sur une Fedora normale, donc le seul avantage, c'est le système en read-only, et j'ai pas le sentiment que ça m'apporte assez pour justifier les limitations que j'ai constaté. Je sais que je peux faire un rpm-ostree install --live, mais je sais aussi que le dev upstream voit ça comme un hack qui va contre la vision du déploiement par image. C'est assez clairement écrit dans la doc de bootc, et j'attends de voir comment tout va se mettre en place en pratique avant de repartir pour 3/4 ans avec ce genre d'OS sur mon portable pro.
Ça dépend du site, mais j'ai entendu que l'offre OVH est pas cher (genre 2€ par mois). De ce qu'on m'a raconté, ça fait l'affaire pour un site statique et je sais qu'il y a du 2FA, de l'IP v6, etc.
J'avais regardé aussi les différentes offres à base de S3 chez les différents providers cloud, mais ça coûtait vite plus cher qu'OVH, avec moins de garantie sur les coûts en cas de DDoS. Dans mon souvenir, AWS était le plus abouti et le moins cher, mais je voulais autre chose. Azure était à 20€ à cause d'un composant de reverse proxy, Digital Ocean était à 5€ minimum (voir plus), et j'ai pas réussi à piger la doc de GCP.
J'avais aussi fait des tests avec fly.io et scaleway, avec un site statique dans un binaire statique mis dans un conteneur. C'était drôle, mais j'avais finalement pas l'usage.
Les GAFAM sont de gros exemples de distorsion de concurrence.
Je pense que ça dépend des domaines. Par exemple, pour les questions d'IaaS et de cloud, il y a une concurrence entre les 3 gros et pas mal de petits acteurs. Il y a aussi des conditions qui font que ce n'est pas trivial de rentrer sur le marché à cause des investissements requis pour le capital, donc on va pas s'attendre à des miracles non plus. 3/4 gros et plein de petits, c'est aussi l'état du marché des abonnements mobiles en France et ailleurs (je pense à ça avec la fusion de 2 opérateurs en Espagne, et la position de la commission européenne pour dire "oui, ça devrait aller" vu que le numéro 4 et le 5 fusionne) pour les mêmes raisons d'avoir besoin de capital.
Je sais pas si Redis est ou a était un monopole et il a beaucoup de concurrents qui lui tiennent à minima la dragée haute et son API est vraiment simple à implémenter ce qui fait que tu peut trouver assez facilement des drop-in replacement.
Ouais, je pense que monopole n'est pas le bon terme en effet, je n'ai pas exprimé ma pensée correctement. Je pense que le terme "brique de base standard" est plus proche de ce que je voulais exprimer.
Postgresql est une brique de base car il y a beaucoup de logiciels qui s'en servent. Redis est dans la même position, je l'utilise pour pretalx, pour discourse, pour nextcloud.
Mongo etait à mon sens moins une brique de base pour moi, car j'ai jamais eu besoin de l'utiliser.
Je doute qu'AWS déploie Garnet, principalement parce c'est un projet issue de Microsoft Research, donc avec du code de chercheurs. Je suppose que soit AWS va essayer de faire comme Microsoft et partager l'argent avec Redis-la-boite (ex Redislabs), soit prendre un des forks qui tient la route et allouer des ressources dessus.
Il y a d'autres projets compatible Redis comme KeyDB, Infinispan, en plus des forks récents.
Mais c'est du coup la preuve qu'il est possible de collaborer.
Ensuite, ça pose la question de ce qui serait une collaboration "juste", mais c'est un débat bien plus compliqué. Si ton logiciel est suffisant pour la plupart des cas (comme Redis), pas grand monde ne va contribuer des correctifs ou des features.
Tu pointes que pg est un commun, mais qu'est ce qui fait qu'un logiciel soit plus un commun qu'un autre, et comment est ce qu'on mesure ça (ou plutôt, voit ça) ?
Je sais qu'il y a des efforts comme les conditions pour devenir projet chez Apache ou sur Openstack. Je sais aussi que parfois, ça coince après. Par exemple, si tu as des commiteurs de 2 entreprises et qu'une fait faillite, ça devient de facto un projet qui n'est plus dans les clous si tu as une condition de diversité. Tu as aussi le fait que même si tu fais des efforts pour devenir un commun avec des sources de contributions variés, c'est parfois impossible si le marché ne permet pas d'avoir plusieurs boites de façon saine.
Finalement, je pense qu'il y a eu pas mal d'écrit sur la question de la concurrence non faussée dans les marchés économiques, et c'est peut être quelque chose à explorer.
Comment est ce qu'on s'assure qu'un logiciel évite une forme de monopole sur sa niche comme c'est arrivé avec Redis ? Est ce qu'on veut tendre vers ça ?
Ça dépend des boites. Google a publiquement dit de ne pas l'utiliser et ne va pas y toucher sauf avec un bâton de plusieurs mètres. Ça a sans doute du faire de l'effet dans l'industrie.
Mais comme pas mal de membres de l'équipe en charge de tout ça (l'Open SOurce Program Office, OPSO) ont découvert un matin de 2023 que leur badge n'était plus valable pour aller à la cafet (et au reste du bâtiment), il est possible que l'influence de l'équipe sur le sujet se dissipe peu à peu (c'est l'avis des juristes chez nous, qui sont d'un avis contraire).
Postgresql est rebrandé par AWS (au moins 2 fois), c'est pas devenu proprio par exemple. Les 3 gros (GCP, AWS, Azure) proposent Kubernetes, et c'est pas devenu proprio non plus. Cassandra, proposé par Azure, c'est pas devenu proprio. GCP propose Tekton et Knative, c'est pas devenu des produits proprios.
Par contre, les projets qui sont majoritairement soutenus par des boites qui ont pris des financements par des boites de capital risques, c'est déjà plus proche de la réalité.
Elasticsearch a fait plusieurs levés de fonds en 2012, 2013, et 2014. Redis a fait des levées de fonds en 2020, en 2021 et avait prévu une entrée en bourse. Mongodb a fait des levées de fond en 2013 et en 2015.
la possibilité qu’un binaire compilé d’un côté ne fonctionne pas de l’autre et quand même très très mince
Le "très très mince" fait tout le boulot ici, et c'est pas exactement une réponse qui veut dire grand chose. En pratique, même avec des distros qui ne s'estiment pas "binairement compatible", ça marche:
$ ssh debian.example.org grep PRETTY_NAME= /etc/os-release ; scp debian.example.org:/bin/ls /tmp/ ; grep PRETTY_NAME= /etc/os-release ; /tmp/ls /
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
ls 100% 144KB 2.9MB/s 00:00
PRETTY_NAME="Fedora Linux 39.20240222.0 (Silverblue)"
bin boot dev etc home lib lib64 media mnt opt ostree proc root run sbin srv sys sysroot tmp usr var
Je viens de prendre le binaire de ls d'une debian, et je l'ai lancé sur Fedora, et ça marche out of the box, malgré des versions relativement différentes de tout. Alors oui, j'ai pris un binaire trivial qui bouge pas beaucoup, mais je pense qu'il y a pas énormément besoin de grand chose pour que ça marche "la plupart du temps".
Par exemple, les efforts pour faire pareil avec les wheels de python montre que tu peux faire des choses si tu te restreint niveau lib. L'usage des conteneurs (que ça soit Docker ou flatpak ou autre) sans se préoccuper du noyau sous jacent la plupart du temps montre que venir avec ses libs est largement suffisant pour une grande partie des cas.
Mais si tu veux un truc qui marche 100% du temps, c'est impossible. Par définition, RHEL n'est pas 100% binairement compatible avec elle même d'une version mineure à une autre.
Trivialement, un exploit qui permet de devenir root qui ne marche plus suite à un correctif, c'est une rupture de la compatibilité entre 2 versions de RHEL, et c'est pareil pour les correctifs de bugs.
Et c'est pas que les exploits, vu que le souci se pose aussi avec les pilotes externes du noyau, malgré la présence d'un ABI réduite plus ou moins garantie par RHEL (voir les histoires de kABI, pour Kernel ABI).
Et c'est justement le fait que le 100% est impossible, et que le "dans pas mal de cas" est trivial qui fait que je pense que ça veut rien dire. Si on définit ni ce qui doit être compatible (eg, quel classe de binaire est affectée ou pas), ni compatible avec quoi exactement (eg, quel version de RHEL, quel ABI non documentée, etc), ç'est creux.
Ça ne veut rien dire peut-être pour toi je te garantie que ça fait sens pour un tas de personnes.
L'humain va trouver du sens la ou il y en a pas. On voit des formes dans les nuages et ailleurs, toutes les civilisations ont développés des religions de façon indépendantes, et si j'en crois la fin d'un article du Monde de hier qui cite Elia Girauldon, même des personnes que les religions refusent se retrouvent à mettre en place des formes de spiritualités comme l'astrologie.
Donc oui, je suis pas étonné que des gens voient du sens la ou il y en a pas. Mais que ça fasse sens pour des gens ne veut pas dire que les gens soient capables de définir exactement, ni que ça résiste à un examen critique.
Tiens d’ailleurs, intéressant que tu parles de Fedora, qu’est-ce qui n’allait pas pour qu’elle remplisse le rôle attribué à CentOS Stream ?
Pour les mêmes raisons qu'Ubuntu n'est pas Debian (ou du moins, certaines raisons). Il y a d'une part des questions de cycles de releases (Fedora sort tout les 6 mois, RHEL mets sans doute plus de 6 mois pour décider quand sort la prochaine distro et avec quoi), mais aussi l'envie de ne pas forcer la communauté à suivre les désirs de RH avec des gros sabots, et ne pas faire un seul produit quand il y a des besoins opposés (à savoir d'un coté "avoir quelque chose qui ne bouge que lentement" et de l'autre "quelque chose qui bouge plus").
Vu que RH s'engage commercialement sur le support de RHEL, il y a un besoin légitime de dire non à certaines modifications, de contrôler les versions, etc. Et ce besoin ne passerait pas vraiment dans une distro communautaire, car la gouvernance serait satisfaisante ni pour les gens des équipes RHEL, ni pour les gens qui bossent sur Fedora. C'est pour ça qu'avant, les équipes de RHEL prenait un snapshot de Fedora, changeait des paquets, puis créait RHEL à partir de ça.
Maintenant, cette distribution qui était interne est publiée sous le nom de Centos Stream. Elle est publié avant RHEL X.0, et reste mise à jour après RHEL X.0 pour devenir RHEL X.1, X.2, X.3, etc.
Je suis étonné sur la partie Consommation instantanée
d’électricité des Box FttH avec boîtier fibre externe supérieure
à celle des Box FttH avec ONT intégré.
Vu qu'il faut deux transfos au lieu d'un, ça me parait pas déconnant.
Mais de ce que j'ai vite vu de l'annexe, je sais pas si on peut en conclure grand chose vu que les boîtiers ne sont pas non plus détaillés. Peut être que la variable "ONT intégré" est un proxy pour "carte plus récente", avec une conso plus réduite.
Mais le réseau 4G ne passe pas sur le réseau fixe à un moment (genre, l'interco entre les antennes, ça se fait via la fibre), du coup, qu'est ce qui est mesuré exactement ?
Ensuite, il y a sans doute plusieurs facteurs qui peuvent expliquer comme le fait qu'un portable est prévu pour réduire la consommation autant que possible, et pas la plupart des routeurs fixe (genre, avoir de l'ARM ne suffit pas à ce que ça consomme rien, même si ça aide).
Ceci dit, ça a l'air d'être un truc de chercheurs. Par exemple, Infinispan aussi supporte le protocole de Redis depuis quelque temps, mais je sais que c'est une coïncidence (dans le sens ou on était pas au courant).
[^] # Re: Le code de la backdoor?
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 4 (+1/-0).
J'ai vu qu'il y a un .o dispo dans le mail d'origine: https://www.openwall.com/lists/oss-security/2024/03/29/4 et le mail dit: "Florian Weimer first extracted the injected code in isolation, also attached, liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks!"
La backdoor était sous la forme de code binaire caché dans les données de test, donc il n'y a que le .o pour le moment. Je ne doute pas que dans quelque jours, quelqu'un va coller le dump en assembleur avec une analyse. Il y a 87 ko de code compilé, avec du code existant, donc ça doit pas être non plus trop gros.
Il y a une version dans le thread avec plus de symboles, ça peut aider pour le débogage.
[^] # Re: Annonce chez Red Hat
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 3 (+0/-0).
Thread sur Fedora:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IJRW6X34BBJQLAQ64G53S7XPRU35U7KN/
[^] # Re: Réaction du projet Python
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 6 (+3/-0).
Modulo le fait que pam charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine). Et que libsystemd aussi depuis 1 mois, comme l'a souligné Lennart P sur HN à un moment.
[^] # Re: Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 9 (+6/-0).
En effet, j'avais complètement zappé ce point (alors que je l'ai lu). Ça fait tombé mon analyse à l'eau :(
# Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 6 (+5/-2).
Quand je lit les commentaires sur la sophistication de la backdoor, et le fait que l'attaquant a visé spécifiquement les paquets de distros, ainsi que d'autres libs, je pense que la cible n'était pas sshd.
Je pense que l'idée était de rajouter une backdoor pour signer des paquets rpms/debian avec une clé arbitraire. Ça expliquerait pourquoi il y a eu un souci avec sshd, car l'attaquant n'avait pas du tester ce cas de figure (vu que la dépendance est transitive via systemd, et ça ne semble être actif que via des options bien spécifiques).
mais liblzma est utilisé aussi par librpm et par dpkg. Le fait de modifier des trucs du coté des fonctions RSA me fait penser aux signatures des paquets, et ça me semble plus probable, ça laisse moins de trace.
# Sur HN, LWN et ailleurs
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 7 (+4/-0).
https://news.ycombinator.com/item?id=39865810
https://lobste.rs/s/uihyvs/backdoor_upstream_xz_liblzma_leading_ssh
https://lwn.net/Articles/967180/
[^] # Re: Valkey
Posté par Misc (site web personnel) . En réponse au lien Linux Foundation Launches Open Source Valkey Community. Évalué à 4 (+1/-0).
Il y a eu des discussions ici et ici, mais je pense que c'est plus parce que Madelyn Olson s'est focalisé sur trouver un endroit ou mettre le projet (eg, la LF) pour faire collaborer les industriels (eg, AWS, Alibaba, Google, etc) alors que Drew a juste dit "fuck it, qui m'aime me suive" et il est parti sur Codeberg, un point que je trouve assez discutable.
Je suppose qu'implicitement, il y a aussi le coté un peu rugeux du dit Drew (je sais pas ce qu'il a fait, mais j'ai eu plusieurs échos).
Comme le souligne Madelyn, la LGPL ne change rien pour les boites qui proposent du Redis en tant que service hébergé, donc je trouve ça assez curieux de dire que ça ne leur convient pas.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3 (+0/-0). Dernière modification le 28 mars 2024 à 21:17.
Oui, je dit parfois que le logiciel libre est la par le surplus de productivité de certaines personnes. On a du code libre parce qu'il y a des bénévoles, on a du code libre parce qu'on a des gens payés qui sont plus productif en reprenant du code libre qu'en codant de 0 (tout les softs écrit par des admins de facs, surtout au début, mais aussi sans doute l'embarqué d'une manière général). Et la, ton exemple rentre aussi la dedans, on a du code libre par les hyperscaleurs parce qu'ils ont du coder ça de toute façon, donc autant le libérer.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3 (+0/-0).
Mouais, ensuite, si tu regardes la timeline de tout ça, c'est plus compliqué.
Redis le projet (2009) est plus ancien que Redis l'entreprise (ex Redis-labs) qui a été crée en 2011 sous le nom Garantia Data par 2 entrepreneurs, aucun n'étant fondateur de Redis le projet. Le créateur n'a rejoint Redis l'entreprise qu'en 2015 (après avoir quitté pivotal, si je me souviens bien), et il a quitté la boite en 2020.
AWS propose AWS Elasticache depuis… 2011 avec un support de Redis depuis septembre 2013 (et Memcached avant). Redis la boite/Redislabs/Garantia Data ont sorti leur offre plus tôt (février 2013), mais c'était pas les seuls sur le marché, vu que Myredis, qu'ils ont achetés en octobre 2013, proposait déjà le même service en 2012 en beta, et en février 2013 en GA ( cf la date de https://news.ycombinator.com/item?id=5294122 ). Donc à quelques mois prêt, tout le monde a eu la même idée (vu que Garantia Data avait aussi une offre de SaaS pour Memcached, soit la même chose qu'AWS, quelques temps après AWS).
Je veux bien dire du mal d'Amazon, mais quand Garantia Data a décidé de se renommer en Redislabs puis en Redis puis de prendre du capital risque 7 ou 8 fois d'affilés pour devenir éditeur, ils savaient qu'AWS était la depuis le début, et ils n'avaient pas trop l'excuse d'avoir fondé le projet eux même vu qu'ils ont fondé la boite puis décidé de devenir le sponsor principal pour rajouter des plugins pour leur business modéle de l'époque (aka, la marketplace) .
La boite aurait parfaitement pu être comme la plupart des boites qui font du support sur Postgresql et du consulting, mais c'est pas le choix qui a été fait, sans doute parce qu'à un moment, faut avoir du ROI.
Redis la boite a choisi de faire de l'édition son gagne pain, sans doute parce que ça rapporte plus que les autres types de gagne pain. Et quand ils ont fait ce choix, AWS et co était déjà la. Donc bon, ils ont tentés de jouer gros, et visiblement, ils n'ont pas gagner.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 7 (+4/-0).
Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).
Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.
J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.
Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.
Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.
Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.
Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.
Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).
Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 4 (+1/-0).
Oui, mais du coup, pipenv et co, ça marche sans silverblue, non ?
Du coup, je pige pas quel est l'apport pour ton workflow, à part d'être sur que tu installes rien en root par erreur.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 6 (+3/-0).
À condition de lancer pip/npm/etc en root, car si tu passes par toolbox (qui est l'outil de moindre résistance), tu va partager le /home. Je suppose que ça dépend de ce que tu appelles "environnement de développement", vu que ça va des compilos aux config des éditeurs de code en passant par les libs dispos.
Le fait de ne pas pouvoir facilement lancer tcpdump ou des outils bas niveau de ce genre dans un conteneur (notamment celui de toolbox) font que je pense que je repasserait sur une distro normal pour mon prochain PC.
Je peux avoir toolbox et flatpak sur une Fedora normale, donc le seul avantage, c'est le système en read-only, et j'ai pas le sentiment que ça m'apporte assez pour justifier les limitations que j'ai constaté. Je sais que je peux faire un rpm-ostree install --live, mais je sais aussi que le dev upstream voit ça comme un hack qui va contre la vision du déploiement par image. C'est assez clairement écrit dans la doc de bootc, et j'attends de voir comment tout va se mettre en place en pratique avant de repartir pour 3/4 ans avec ce genre d'OS sur mon portable pro.
[^] # Re: La mienne marche encore
Posté par Misc (site web personnel) . En réponse au lien Webmail + pages perso free aux non abonnés, c'est terminé. Évalué à 3 (+0/-0).
Ça dépend du site, mais j'ai entendu que l'offre OVH est pas cher (genre 2€ par mois). De ce qu'on m'a raconté, ça fait l'affaire pour un site statique et je sais qu'il y a du 2FA, de l'IP v6, etc.
J'avais regardé aussi les différentes offres à base de S3 chez les différents providers cloud, mais ça coûtait vite plus cher qu'OVH, avec moins de garantie sur les coûts en cas de DDoS. Dans mon souvenir, AWS était le plus abouti et le moins cher, mais je voulais autre chose. Azure était à 20€ à cause d'un composant de reverse proxy, Digital Ocean était à 5€ minimum (voir plus), et j'ai pas réussi à piger la doc de GCP.
J'avais aussi fait des tests avec fly.io et scaleway, avec un site statique dans un binaire statique mis dans un conteneur. C'était drôle, mais j'avais finalement pas l'usage.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4 (+1/-0).
Je pense que ça dépend des domaines. Par exemple, pour les questions d'IaaS et de cloud, il y a une concurrence entre les 3 gros et pas mal de petits acteurs. Il y a aussi des conditions qui font que ce n'est pas trivial de rentrer sur le marché à cause des investissements requis pour le capital, donc on va pas s'attendre à des miracles non plus. 3/4 gros et plein de petits, c'est aussi l'état du marché des abonnements mobiles en France et ailleurs (je pense à ça avec la fusion de 2 opérateurs en Espagne, et la position de la commission européenne pour dire "oui, ça devrait aller" vu que le numéro 4 et le 5 fusionne) pour les mêmes raisons d'avoir besoin de capital.
Ouais, je pense que monopole n'est pas le bon terme en effet, je n'ai pas exprimé ma pensée correctement. Je pense que le terme "brique de base standard" est plus proche de ce que je voulais exprimer.
Postgresql est une brique de base car il y a beaucoup de logiciels qui s'en servent. Redis est dans la même position, je l'utilise pour pretalx, pour discourse, pour nextcloud.
Mongo etait à mon sens moins une brique de base pour moi, car j'ai jamais eu besoin de l'utiliser.
[^] # Re: Pendant ce temps-là chez Microsoft
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4 (+1/-0).
Je doute qu'AWS déploie Garnet, principalement parce c'est un projet issue de Microsoft Research, donc avec du code de chercheurs. Je suppose que soit AWS va essayer de faire comme Microsoft et partager l'argent avec Redis-la-boite (ex Redislabs), soit prendre un des forks qui tient la route et allouer des ressources dessus.
Il y a d'autres projets compatible Redis comme KeyDB, Infinispan, en plus des forks récents.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4 (+1/-0).
Mais c'est du coup la preuve qu'il est possible de collaborer.
Ensuite, ça pose la question de ce qui serait une collaboration "juste", mais c'est un débat bien plus compliqué. Si ton logiciel est suffisant pour la plupart des cas (comme Redis), pas grand monde ne va contribuer des correctifs ou des features.
Tu pointes que pg est un commun, mais qu'est ce qui fait qu'un logiciel soit plus un commun qu'un autre, et comment est ce qu'on mesure ça (ou plutôt, voit ça) ?
Je sais qu'il y a des efforts comme les conditions pour devenir projet chez Apache ou sur Openstack. Je sais aussi que parfois, ça coince après. Par exemple, si tu as des commiteurs de 2 entreprises et qu'une fait faillite, ça devient de facto un projet qui n'est plus dans les clous si tu as une condition de diversité. Tu as aussi le fait que même si tu fais des efforts pour devenir un commun avec des sources de contributions variés, c'est parfois impossible si le marché ne permet pas d'avoir plusieurs boites de façon saine.
Finalement, je pense qu'il y a eu pas mal d'écrit sur la question de la concurrence non faussée dans les marchés économiques, et c'est peut être quelque chose à explorer.
Comment est ce qu'on s'assure qu'un logiciel évite une forme de monopole sur sa niche comme c'est arrivé avec Redis ? Est ce qu'on veut tendre vers ça ?
[^] # Re: Rectification à propos des licences
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3 (+0/-0).
Sinon, suffit de voir ce que l'OSI ou Debian ou Fedora accepte.
Par exemple, pour Fedora, il y a cette PR et cette page de wiki, que j'ai trouvé dans ce fichier.
[^] # Re: Changement de licence
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3 (+0/-0).
Ça dépend des boites. Google a publiquement dit de ne pas l'utiliser et ne va pas y toucher sauf avec un bâton de plusieurs mètres. Ça a sans doute du faire de l'effet dans l'industrie.
Mais comme pas mal de membres de l'équipe en charge de tout ça (l'Open SOurce Program Office, OPSO) ont découvert un matin de 2023 que leur badge n'était plus valable pour aller à la cafet (et au reste du bâtiment), il est possible que l'influence de l'équipe sur le sujet se dissipe peu à peu (c'est l'avis des juristes chez nous, qui sont d'un avis contraire).
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 6 (+4/-1).
Alors tout les projets, non, pas vraiment.
Postgresql est rebrandé par AWS (au moins 2 fois), c'est pas devenu proprio par exemple. Les 3 gros (GCP, AWS, Azure) proposent Kubernetes, et c'est pas devenu proprio non plus. Cassandra, proposé par Azure, c'est pas devenu proprio. GCP propose Tekton et Knative, c'est pas devenu des produits proprios.
Par contre, les projets qui sont majoritairement soutenus par des boites qui ont pris des financements par des boites de capital risques, c'est déjà plus proche de la réalité.
Elasticsearch a fait plusieurs levés de fonds en 2012, 2013, et 2014. Redis a fait des levées de fonds en 2020, en 2021 et avait prévu une entrée en bourse. Mongodb a fait des levées de fond en 2013 et en 2015.
[^] # Re: Le mot manquant
Posté par Misc (site web personnel) . En réponse au lien Pour que chance & joie de s’informer n’aient d’égales que celles d’éduquer aux médias et à l’info. Évalué à 3 (+0/-0).
Ouais, j'ai aussi parfois le probléme. Je suis un peu contre le fait de changer les titres donc je sais pas quoi faire quand ça m'arrive.
Et je sais qu'augmenter la limite ne va faire que repousser le probléme, mais bon…
# Le mot manquant
Posté par Misc (site web personnel) . En réponse au lien Pour que chance & joie de s’informer n’aient d’égales que celles d’éduquer aux médias et à l’info. Évalué à 3 (+0/-0).
le mot manquant du titre est "information".
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 5 (+2/-0).
Le "très très mince" fait tout le boulot ici, et c'est pas exactement une réponse qui veut dire grand chose. En pratique, même avec des distros qui ne s'estiment pas "binairement compatible", ça marche:
Je viens de prendre le binaire de ls d'une debian, et je l'ai lancé sur Fedora, et ça marche out of the box, malgré des versions relativement différentes de tout. Alors oui, j'ai pris un binaire trivial qui bouge pas beaucoup, mais je pense qu'il y a pas énormément besoin de grand chose pour que ça marche "la plupart du temps".
Par exemple, les efforts pour faire pareil avec les wheels de python montre que tu peux faire des choses si tu te restreint niveau lib. L'usage des conteneurs (que ça soit Docker ou flatpak ou autre) sans se préoccuper du noyau sous jacent la plupart du temps montre que venir avec ses libs est largement suffisant pour une grande partie des cas.
Mais si tu veux un truc qui marche 100% du temps, c'est impossible. Par définition, RHEL n'est pas 100% binairement compatible avec elle même d'une version mineure à une autre.
Trivialement, un exploit qui permet de devenir root qui ne marche plus suite à un correctif, c'est une rupture de la compatibilité entre 2 versions de RHEL, et c'est pareil pour les correctifs de bugs.
Et c'est pas que les exploits, vu que le souci se pose aussi avec les pilotes externes du noyau, malgré la présence d'un ABI réduite plus ou moins garantie par RHEL (voir les histoires de kABI, pour Kernel ABI).
Et c'est justement le fait que le 100% est impossible, et que le "dans pas mal de cas" est trivial qui fait que je pense que ça veut rien dire. Si on définit ni ce qui doit être compatible (eg, quel classe de binaire est affectée ou pas), ni compatible avec quoi exactement (eg, quel version de RHEL, quel ABI non documentée, etc), ç'est creux.
L'humain va trouver du sens la ou il y en a pas. On voit des formes dans les nuages et ailleurs, toutes les civilisations ont développés des religions de façon indépendantes, et si j'en crois la fin d'un article du Monde de hier qui cite Elia Girauldon, même des personnes que les religions refusent se retrouvent à mettre en place des formes de spiritualités comme l'astrologie.
Donc oui, je suis pas étonné que des gens voient du sens la ou il y en a pas. Mais que ça fasse sens pour des gens ne veut pas dire que les gens soient capables de définir exactement, ni que ça résiste à un examen critique.
Pour les mêmes raisons qu'Ubuntu n'est pas Debian (ou du moins, certaines raisons). Il y a d'une part des questions de cycles de releases (Fedora sort tout les 6 mois, RHEL mets sans doute plus de 6 mois pour décider quand sort la prochaine distro et avec quoi), mais aussi l'envie de ne pas forcer la communauté à suivre les désirs de RH avec des gros sabots, et ne pas faire un seul produit quand il y a des besoins opposés (à savoir d'un coté "avoir quelque chose qui ne bouge que lentement" et de l'autre "quelque chose qui bouge plus").
Vu que RH s'engage commercialement sur le support de RHEL, il y a un besoin légitime de dire non à certaines modifications, de contrôler les versions, etc. Et ce besoin ne passerait pas vraiment dans une distro communautaire, car la gouvernance serait satisfaisante ni pour les gens des équipes RHEL, ni pour les gens qui bossent sur Fedora. C'est pour ça qu'avant, les équipes de RHEL prenait un snapshot de Fedora, changeait des paquets, puis créait RHEL à partir de ça.
Maintenant, cette distribution qui était interne est publiée sous le nom de Centos Stream. Elle est publié avant RHEL X.0, et reste mise à jour après RHEL X.0 pour devenir RHEL X.1, X.2, X.3, etc.
[^] # Re: Complément
Posté par Misc (site web personnel) . En réponse au lien Enquête annuelle "Pour un numérique soutenable" - édition 2024 (données 2022). Évalué à 3 (+0/-0).
Vu qu'il faut deux transfos au lieu d'un, ça me parait pas déconnant.
Mais de ce que j'ai vite vu de l'annexe, je sais pas si on peut en conclure grand chose vu que les boîtiers ne sont pas non plus détaillés. Peut être que la variable "ONT intégré" est un proxy pour "carte plus récente", avec une conso plus réduite.
[^] # Re: Complément
Posté par Misc (site web personnel) . En réponse au lien Enquête annuelle "Pour un numérique soutenable" - édition 2024 (données 2022). Évalué à 3 (+0/-0).
Mais le réseau 4G ne passe pas sur le réseau fixe à un moment (genre, l'interco entre les antennes, ça se fait via la fibre), du coup, qu'est ce qui est mesuré exactement ?
Ensuite, il y a sans doute plusieurs facteurs qui peuvent expliquer comme le fait qu'un portable est prévu pour réduire la consommation autant que possible, et pas la plupart des routeurs fixe (genre, avoir de l'ARM ne suffit pas à ce que ça consomme rien, même si ça aide).
[^] # Re: Et Microsoft était visiblement au courant
Posté par Misc (site web personnel) . En réponse au lien Redis Adopts Dual Source-Available Licensing. Évalué à 3 (+0/-0).
Ceci dit, ça a l'air d'être un truc de chercheurs. Par exemple, Infinispan aussi supporte le protocole de Redis depuis quelque temps, mais je sais que c'est une coïncidence (dans le sens ou on était pas au courant).