Ouais enfin, il faut 1) être root sur la machine en face 2) avoir quelqu'un qui utilise un forward d'agent.
Si 1 et 2 sont remplis, il faut bien voir que tu es déjà dans la merde vu que root peut juste taper dans ton socket et utiliser ta clé, et par exemple, dans des cas hypothétiques, faire un ssh pour revenir vers ta propre machine avec ton compte, ou ce genre de choses.
Je dit pas qu'il faut pas corriger, mais clairement, je pense qu'il n'y a pas trop lieu de paniquer dans la grande majorité des cas.
Dans la mesure ou il a été en prison (pour des crimes relativement sans victime autre que "on a du dépensé de l'argent", càd "on a des gens qui ont été occupé 2 mois à faire des réunions"), il a purgé sa peine.
Je ne veux pas proposer de passer en mode "droit à l'oubli" complet, mais je trouve déjà que la prison pour un crime de ce genre, c'est beaucoup. Encore une fois, la privation de liberté, c'est une exception aux divers textes sur les droits humains fondamentaux (je vais m'autoriser une autocitation). C'est pas pour rien que certains partis d’extrême droite militent pour ne plus les appliquer (exemple, les Patriotes, le parti de Florian Philippot, qui a "sortie de la CEDH" dans son programme totalement hors sol et démago).
Si quelqu'un a payé le prix de ses actes (ce qui est rarement le cas pour beaucoup de morts, donc je ne veux pas généraliser), je trouve que c'est quand même être plus royaliste que le roi que de venir ressortir ça.
De plus, si on considère que regarder le casier judiciaire à l'embauche est illégal en France, et que par exemple, aux USA, c'est un mécanisme qui maintient certaines populations défavorisées (les latinos, les afroaméricains) dans la pauvreté à un niveau quasi générationnel, alors je pense qu'on peut légitimement se poser la question de savoir si c'est aussi une forme de prolongement/augmentation de la peine.
Je dit "se poser la question", car bien sur, tout les cas ne sont pas équivalents.
L'attaquand doit être root sur la machine en face (pour accéder à la socket transmise), et il faut avoir assez de libs sur la machine cible afin de construire un exploit spécifique en combinant des chargements/déchargements.
Je connais aucune des libs détaillés par qualys dans la démonstration, j'imagine à dessein pour ne pas rendre ça trop facile à utiliser. Mais du coup, c'est pas clair si c'est faisable facilement en dehors du cas spécifique d'ubuntu 20.04 par défaut.
(et à mon grand regret, ssh-agent n'est pas confiné avec selinux sur ma Fedora)
A la limite, personnellement, les chiffres je m'en moque un peu
C'est la le souci. Se moquer des chiffres, c'est risquer de prendre des cas exceptionnels et en faire des généralités.
C'est ce qui est arrivé avec les paniques morales sur les enlèvements (ou les viols) dans la rue. On imagine que le probléme, c'est des étrangers dans la rue, alors que les chiffres vont montrer le contraire (à savoir les proches).
Ça veut pas dire que les premiers n'arrivent pas, mais comme c'est beaucoup plus présent dans la culture populaire, on oublie que les seconds sont bien plus présents.
Mais quel est le rapport ?
Que visiblement, les accusations justifiées ne détruisent pas des vies, et sans preuve d'accusations injustifiées qui détruisent des vies (car tu n'en donne pas, et tu ne donne pas de chiffres), on ne peut pas être d'accord avec ta conclusion.
Et tu focalises sur le viol, mais tu oublies les autres exemples.
Les autres exemples que le viol, comme le fait d'avoir Johnny Depp à Cannes, Dave Chappel sur Netflix, Elon Musk devant Macron ?
Ou tu veux parler des exemples qui appuient ton point, exemples que tu ne donnes pas ?
Car bon, si tu penses que pointer la misogynie et le racisme est un souci car ça risque de détruire des vies (combien, le discours ne le dit pas), il faut mettre ça en balance avec la destruction causé par le racisme et la misogynie.
elles peuvent aussi aller jusqu'à détruire la vie de certaines personnes
Je pense que cette affirmation manque de chiffres et de sources, parce que c'est aussi ce que certains disent pour les accusations de viol, et pourtant, il suffit de voir que Polenski n'est pas en tôle, que Woody Allen fait encore des films, PPDA n'a pas trop été inquiété, Louis CK fait encore des seuls-en-scène, (etc, etc je vais pas faire la liste).
Donc si les accusations graves ne changent pas grand chose, et sont rarement suivis de condamnations par la justice, j'ai du mal à voir de combien exactement de vies brisés on parle ?
Et comme personne ne donne jamais le moindre chiffre, ni même le moindre exemple, donc ça me semble plus être un argument par l'émotion (et donc, un peu manipulatoire au minimum) qu'une vérité vérifiable et quantifiable.
Un juriste au taf a fait remarqué que la licence n'est pas vraiment open source.
Le point 2 "Additional Commercial Terms" par exemple, est le premier qui pose souci (et qui, contrairement aux autres plus loin, est sans controverse).
Je sais pas qui a utilisé le terme opensource entre le journaliste et Meta/FB, mais c'est une erreur grossière au mieux, au pire de l'openwashing manifeste.
Alors que si ça avait été limité depuis le début, personne n'aurait rien dit.
C'est toujours amusant de voir que ce n'est pas tant l'état d'arrivé qui fait râler que le changement et la sensation de perte qui s'accompagne.
Et c'est d'autant plus intéressant que c'est une sensation de perte de quelque chose qui était vu comme gratuit, donc soit perçu comme sans valeur (au sens économique, cad que les gens ne veulent pas payer pour), soit payé par quelqu'un d'autre (dans le sens ou quelqu'un paye pour la maintenance).
si tu ouvres un ticket chez redhat ou un vendeur tiers, la première chose qu'ils vont te demander de faire, c'est une update des paquets et reproduire le problème.
Oui, parce qu'on sait jamais si le probléme n'est pas déjà corrigé. Beaucoup de gens font pareil sur les projets libres en général, et ça n'a rien à voir avec la compatibilité, juste l'envie de ne pas perdre de temps sur ça.
Et en pratique, quand un programme tierce marche sur une distro X à un moment T et pas le lendemain d'une mise à jour, les clients râlent d'abord sur le dernier truc qui a changé en disant "vous avez cassé quelque chose". Et parfois, tu découvres que le logiciel dépend d'un comportement qui a en effet changé, mais qui n'était pas spécifié (et qui ne fait pas parti de l'ABI). Ou qui dépend d'un bug de sécurité, comme j'ai eu le cas ce matin avec woodpecker (j'ai un peu honte de ça).
la majorité des boites qui utilisent du redhat / centos utilisent des solutions comme redhat satellite/foreman pour avoir des snapshots des repos à un instant T et procèdent en général à du patching par lots, ce qui fait que toutes leurs machines vont souvent être à un même niveau de patch à tout instant.
Mais ça veut juste dire que tu as les mêmes paquets installés sur ton parc, pas que tu as les mêmes que le parc du voisin, ni le parc utilisé par les tests à un moment T par les vendeurs tierces ou les testeurs de RHEL. Ni même qu'ils ont été installés dans le même ordre ou au même moment.
Les installations de paquets ne sont pas déterministes, car l'ordre d'installation n'est pas forcément garanti (vu que les structures sous jacentes ne le sont pas forcément), et si des scripts de post installations sont impliqués, c'est encore pire.
C'était sauf erreur de ma part la conclusion d'un travail de recherche présenté lors d'une conférence en 2010 au FOSDEM, ou le présentateur a expliqué tout les soucis qui découlent d'avoir bash ou lua pour des scripts. Il est revenu l'année après avec une solution ou il remplace les scripts par un DSL d'actions limités et réversibles.
Et en fait, même la date d'installation du serveur peut jouer.
Les devs Openstack du bureau m'ont raconté un jour un bug épique. Je n'ai pas le détail, mais le contournement est détaillé ici. Le client avait fait les upgrades de tout son cluster depuis plusieurs versions, et à un moment, ça n'a pas marché. La QA n'a pas réussi à reproduire, on voyait bien que c'était un souci vis à vis de docker et du filesystem, mais c'est tout.
La solution est venu quand quelqu'un a tenté de refaire exactement le même parcours que le client (donc 6 ou 7 upgrades d'affilés) et a réussi à reproduire le souci. Et en effet, l'équipe QA a découvert que les partitions XFS déployéees en RHEL 7.0 n'était pas compatible avec ce que demande Docker (qui avait besoin d'overlayfs, qui a besoin d'autres choses, etc). L'intégration de docker a impliqué de faire un backport d'une fonction spécifique de XFS, fonctionnalité activé par défaut à l'installation des nouvelles versions (donc > RHEL 7.3) mais fonctionnalité manquante sur les serveurs du client car installés il y a trop longtemps (en 7.0).
C'est un cas extrême, mais ça montre bien qu'avoir exactement les mêmes binaires, ça peut ne pas suffire.
Et je suis sur que des cas comme ça (mais moins épique), mes collègues ont du en croiser souvent (moi, j'ai juste des bugs de merde comme le jour ou les tests de Gluster ont échoués car j'ai relancé Jenkins et le serveur a basculé en francais).
Et je parle pas des bugs dépendant du hardware, ou ce genre de trucs.
La compat bug pour bug, ça n'a aucun sens quand les bugs peuvent venir de partout en pratique.
Avec les corrections de bug en tout genre, RHEL à un instant T n'est pas compatible bug pour bug avec RHEL à un instant T+1 ou T-1 car les paquets changent à cause des correctifs de bug. Et comme les clients appliquent les correctifs à leur vitesse et font un mix, il n'y a pas de garantie possible de toute façon.
Donc quand RHEL ne peut pas être compatible bug pour bug avec elle même (car les bugs sont corrigés tout les jours), je ne vois pas exactement ce que Rocky compte viser avec.
C'est pour ça que la doc de RHEL parle d'ABI stable, que les ingés vérifient ça avec des tests sur l'ABI (via une CI dont le code est sur le gitlab que j'ai pointé). Et si le but est de viser une ABI stable, Alma vise ça aussi, à partir de Centos Stream comme RHEL.
Ensuite, si tu veux dire quelque chose d'autre quand tu parles de 1:1 et que j'ai mal compris, je veux bien comprendre la différence et ce que tu mets derrière les mots, car plus je lit, moins je comprends pourquoi les gens râlent exactement (car j'ai pas le sentiment que grand monde sait exactement comment une distro est buildé en pratique, ni comment les changements sont gérés).
La vraie question, c'est aussi de savoir de quoi on parle par "le code source".
Les patchs sont sur https://gitlab.com/redhat/centos-stream/rpms car les rpms de RHEL sont buildés à partir de Centos Stream (genre, les patchs vont d'abord dans Stream sauf de façon temporaire le temps d'un embargo de sécurité).
Les fichiers specs sont aussi la, dans le même dépôt (et pareil que les patchs, ça va d'abord dans stream).
On va me dire "et les tarballs". Les tarballs sont sur le même système que Fedora, ça utilise un serveur nommé "Lookaside Cache" (et j'imagine que c'est le même, pas de raison de dupliquer les fichiers entre toutes les distros, les disques sont pas gratuits).
Que je sache, il n'y a pas de page d'index sur le serveur mais les sources sont dispos via l'outil centpkg (le pendant de fedpkg), outil libre et dispo sur https://git.centos.org/centos/centpkg/tree/develop
Et on peut scripter ça avec curl vu que les tarballs sont en https, si on a le hash et le nom pour adresser le fichier. Et dispo sans mot de passe.
Tout les logiciels sont libres.
Donc, quelle code source est manquant exactement ?
Mais ton example, c'est un souci si l'attaquant peut choisir le nom entier du fichier, mais est ce le cas ? Et est ce qu'on peut vraiment mettre une URL complète dans un message activitypub sans que ça contredise la spec ?
Car si c'est le cas (eg, que ke nom d'un attachement est non filtré sous le controle complet d'un attaquant) alors il y a le cas de ffmpeg:
ffmpeg qui est dans la même catégorie que magick en terme de risque: "couteau suisse, parse des tonnes de format, écrit en C, va lire des trucs de l'internet".
ffmpeg -i https://foo.example.org/image.jpg est valide. Du coup, si la spec permet d'avoir un fichier avec un nom qui commence par http pour les attachements, il faut filtrer plus que magick, mais ça n'est pas adressé.
Et comme tu le dit, magick peut utiliser le coder "screenshot" ou "x" pour taper ailleurs que dans les fichiers, et sauf erreur de ma part, ça n'est pas filtré (ensuite, c'est sans doute non fonctionnel).
Donc non, je tente vraiment de comprendre mais pour ça, il faut visiblement plus que le patch, car je ne trouve pas le souci en pratique (en partie car le patch fait 4 choses différentes).
Si je comprends bien, tu parles de la policy (fichier policy.xml), mais justement, c'est ça que je pige pas.
Je m'attends à ce que ImageMagick, sauf faille de sécurité, soit utilisable sans avoir de fichier policy.xml. Avoir une sandbox est une bonne chose, mais on parle d'ImageMagick, si le logiciel sans fichier policy.xml est troué par défaut, c'est un souci.
Donc quand j'examine le patch en détail, il touche 8 fichiers.
On peut retirer les tests et le mp3 de test qui va avec, ainsi que la modif de application.rb qui est la pour charger un autre fichier.
Il reste 5 modifs. Une est le fichier policy.xml, une pour utiliser le fichier en question. On va mettre ça de coté.
Il reste donc les 3 derniers bouts, à savoir:
- une classe MediaTypeSpoofDetectorExtensions
- une modif de transcoder.rb
- une modif de attachmentable.rb
De ce que je comprends, la derniére modif change juste la validation pour utiliser le type MediaTypeSpoofDetectorExtensions, ce qui permet de ne pas laisser passer certains mp3 mal détectés. C'est curieux d'avoir 2 libs pour trouver le type mime, mais on.
Et il reste que transcoder.rb, qui va échouer si on ne peux pas faire de transcoding au lieu de laisser passer ça à ImageMagick.
Donc on a:
- une meilleur vérification des fichiers transcodés (notament les mp3)
- on arrête le traitement si le transcodage échoue (mais quel traitement ? que fait mastodon à part du retaillage ?)
- une policy qui va bloquer le traitement de tout sauf les fichiers d'images, et qui va interdire le module URL.
Mais donc, les modules en questions, est ce que ImageMagick va les appeler sans demande explicite de l'utilisateur ?
Les fonctions des coders (plutôt des encodeurs et décodeurs) implique aussi de demander de les utiliser. Si je dit "transforme ce jepg en pdf", ça va appeler le coder pdf. Mais ça se fait pas sans une demande explicite via la CLI. Donc je pige pas, surtout que ImageMagick n'est pas directement appelé par le code, mais via paperclip (de ce que je comprends), donc il y a déja une couche d'astraction qu'on peut supposer sur (ou qui n'est pas documenté comme non sure).
Est ce que passer un fichier spécifique à ImageMagick dans sa config par défaut va être un souci de sécurité, ou est ce qu'il s'agit d'une faille dans l'instance si il y a une faille dans IM (auquel cas, il y a pas d'urgence sauf timing de merde, mais je vois personne dire "faut mettre à jour IM tout de suite")
J'ai relu 3 fois mon commentaire, je ne croit pas avoir construit d’hypothèses sur les annonces, j'ai construit des hypothèses sur ce que j'ai constaté depuis des années pour Centos.
Ensuite, effectivement, j'imagine qu'on peut extrapoler des suppositions crédibles pour le futur de Rocky et Alma à partir du passé de Centos, si rien de substantiel ne change.
Et bien sur, peut être que je me trompe, et je serait ravi d'avoir des hypothèses alternatives sur ce qui est arrivé à Centos. Mais je crois que personne ne s'est vraiment penché sur ça, justement car la communauté n'avait pas d'appétence pour l'introspection, étant sans doute trop le nez dans le guidon avec une copie d'une RFC trouvé au Vatican pour en discuter en buvant du thé et échangeant des blagues en Francais.
L'ordre n'importe pas tellement, vu que dans les 2 cas, le résultat est le même, un certain contrôle du board qui va à l'encontre des objectifs affichés d'indépendance.
C'est bien d'avoir une calsue sur les votes, mais bon, la démocracie, c'est pas juste les votes, c'est aussi les discussions sur savoir ce qui est voté, la transparence, etc.
C'est ni la première fois, ni la dernière que ce genre de chose arrive dans le libre (ou ailleurs). Réussir à fédérer des entreprises concurrentes est une tache complexe et difficile. Le chemin choisi en général, c'est de passer par une fondation tierce déjà établie, mais C'est aussi quelque chose qui va te ralentir, donc pas forcément désirable d'un point de vue commercial (et on en revient aux visées commerciales de CIQ, une fois encore). Ou non désirable d'un point de vue fiscal (car il y a des considérations à filer une tonne de thunes à une organisation sans but lucratif qui produit un produit que tu es le seul à vendre, l'IRS n'aime pas ça)
La balance entre faire en sorte que le projet grandisse vite et que le projet grandisse de façon durable est encore une fois dur à atteindre, surtout quand c'est ton premier essai. Contrairement au board d'Almalinux (qui a benny Vasquez, Simon Phipps et Jack Aboutboul au bureau), j'ai pas le sentiment qu'il y a grand monde avec ce genre d'expérience chez Rockylinux. Leur CM me semble plus faire du marketing que de la communauté au sens ou les librites l'entendent (et elle n'est pas au board, ce qui est aussi une bonne indication de l'importance du sujet).
Et si le but est d'avoir un fonctionnement un peu plus communautaire et avec une séparation plus visible, il y a des étapes simples qui ne vont rien changer de substantiel à court terme tout en permettant de donner la bonne direction.
Par exemple, il suffit que CIQ file de l'argent à la RESF pour embaucher certaines personnes qui bossent sur Rockylinux. Ce qui me vient en tête, c'est ce que fait la fondation GNOME, ou la PSF en embauchant des sysadmins.
Autre example, faire en sorte que SUSE file l'argent à la RESF au lieu de prendre un contrat avec CIQ aiderais aussi pas mal sur la question de la diversité et de l'ISF mentionné plus haut.
Ou publier les comptes de façon plus régulières que le minimum légal, et de façon plus visible serait aussi un pas dans la bonne direction.
Il y a plein de choses qui pourraient être fait sans remettre en cause le modèle, mais qui ne sont pas encore faites malgré les 2 ans et demi depuis l'annonce de décembre 2020.
Bah, avant IBM, le méchant, c'était "la bourse" ou "les actionnaires", comme si nos salaires n'avaient rien à voir avec le reste (sauf dans les boites rachetés, auquel cas le méchant, c'était RH, en bref, toujours un truc plus gros et moins humain, jamais son ancien patron).
Ce qui me fait rire avec les allégations à la sauce techrights, c'est à quel point ça simplifie le fonctionnement d'une grande boite.
Franchement, si une grande entreprise avait une hiérarchie aussi efficace et rapide qu'il l'imagine, on le saurait depuis longtemps. Il faut 6 mois pour faire valider l'utilisation d'un hébergement wordpress, mais à coté de ça, la boite a largement le temps de prévoir le truc le plus diabolique possible (comme systemd) juste pour prendre le controle des serveurs en retirant des bouts de bash que personne ne veut maintenir.
(et je le voit aussi avec le fedivers, voir les idées claquées au sol sur les histoires avec threads était assez révélateur)
Encore une fois, la différence entre RockyLinux/CIQ et AlmaLinux me semble assez révélatrice des différences pratiques des 2 groupes.
CIQ profite de l'annonce pour choper 10 millions d'US$ chez un concurrent (car SUSE est un concurrent de CIQ, les 2 visent à fournir du support sur une distro RHEL compatible), et Rockylinux, fortement contrôlée par CIQ (comme on a pu le voir plus haut), décide de viser la compatibilité bug pour bug, un des arguments utilisé commercialement par CIQ. La compat bug pour bug, ça n'a d'importance que pour les vendeurs tierces, le reste du monde est content de voir les bugs corrigés en général (sinon, pourquoi payer le support si c'est.
De manière que je trouve plus maligne sur le long terme, Alma décide de ne pas suivre RockyLinux, et de permettre à la communauté de faire vraiment ce qu'elle veut.
Car viser le "bug pour bug compatible", ça implique aussi de ne jamais rien changer par rapport à RHEL (sinon, c'est plus du bug pour bug), de ne pas fournir de correctif de bug ou de fonction en plus, et donc que la gouvernance technique reste entièrement chez Red Hat. Pour moi, c'est un antipattern de distribution communautaire, ça décourage assez vite les bonnes volontés.
Dans le cas de Centos, venir ouvrir des bugs et qu'on te réponde "on ne corrige rien, faut aller voir avec Red Hat", ça a vite impulsé une dynamique problématique sous forme de découragement.
C'est selon moi un des facteurs principaux de l'état de la communauté Centos vers 2014, à savoir surtout des gens la pour utiliser, et pas des gens pour contribuer au cœur de la distribution (ou ailleurs). Et après 2014, ça s'est aggravé, car quand RH a payé quelqu'un pour organiser les dojos Centos, la communauté a arrêté de s'en occuper après 2 ans en mettant les pieds sous la table.
"RESF shall be structured and governed in a way that ensures that no single entity, organization, corporation, association, etc. will be permitted to have a controlling influence over the RESF or its projects"
C'est une bonne chose, et traduit dans le point 18 de l'article II des statuts, donc on ne peux pas dire que c'est du flan.
Mais malgré ça, en pratique, CIQ emploie plus d'une moitié du bureau affiché sur le site web.
Si on regarde le meeting de mars, ou il y a eu le vote du président, il y a eu 2 membres qui n'ont pas pris par au vote, car affiliés à CIQ. Et donc, en plus des 4 que j'ai listé, je voit que Sherif Negy bosse aussi chez CIQ (ce qui n'est pas sur Linkedin ), ce qui fait donc un total de 5 personnes maintenant au bureau pour le même employeur.
Le meeting du mois de janvier est aussi intéressant, car il n'y a presque personne de CIQ à ce moment (à part Gregory Kurster en tant que membre fondateur, et Brian Clemens en tant qu'externe), donc en 2 mois, il y a eu un quasi takeover du board.
Et je constate que les minutes de meeting de RESF sont globalement vides, publiées avec un retard croissant. Les minutes de mai sont arrivés début juillet, il n'y a rien pour celui de juin sur github. Personne ne semble mettre à jour le site web, car la liste ne montre que 3 mois et s’arrête à mars 2023, (voir en bas de la page). Donc c'est un peu les MM&S brun pour la transparence. Si les trucs sans importances ne sont pas fait, qu'est ce que ça va donner pour le reste :/
Quand je compare avec AlmaLinux, la différence est flagrante. Le board est beaucoup plus diversifié chez Alma, (cf la page sur le wiki ), le poste des membres du bureau clairement affiché (enfin, sauf pour Jack Aboutboul, qui ne dit pas que Moshe Bar, son PDG/ancien PDG, est aussi au board).
On voit aussi que les minutes des meetings sont détaillées, et à jour. Il y a des liens vers les différents documents discutés, et l'agenda du meeting suivant (août 2023) est déjà la. On voit qu'il y a des réunions depuis 2 ans, et que les membres de la communauté peuvent devenir membre du bureau via des élections ouvertes.
Ça me parait beaucoup plus propre et plus communautaire que Rockylinux. Et ça, c'est sans me pencher sur le focus constant sur le fondateur de la distro (Gregory Kurster), qui est pour moi un antipattern comme on a pu le voir avec la FSF en 2021.
Ce qui revient à avoir une faille arbitraire dans ImageMagick, non ?
Le patch semble juste empêcher de faire passer un média arbitraire à ImageMagick.
Je vois bien comment ça pourrait poser probléme parce qu'ImageMagick a régulièrement des soucis (et donc, suffit de passer un fichier vérolé dans un format pourri, et voila), mais en pratique, quel attaque possible ne s'appuie pas sur une faille d'ImageMagick (et je compte le fait d'avoir un write arbitraire d'IM comm une faille d'IM ) ?
Et si on regarde qui est aussi au bureau, le team lead sur l'infra, Neil Hanlon, est développeur chez CIQ, d’après son profil Linkedin. Mustafa Gezen, team lead sur la partie release engineering, est employé par CIQ (toujours linkedin).
Donc sur 8 membres du bureau, 4 sont dans la même boite, avec 3 qui ont un lien de subordination avec le fondateur et président de l'assoce et PDG du sponsor principal. Je sais que quand il y a un sponsor principal, c'est souvent ce qui arrive, car les non employés n'ont pas le temps de faire ce que les employés peuvent faire en terme de réunion et de travail, mais c'est quand même curieux que ça soit le cas pour un projet si récent.
L'investisseur est Two Bear Capital, une boite fondé par un ancien de Sequoia Capital (qui a été une des premières boites à investire dans Facebook, d'aprés WP), et qui a aussi investi dans la biotechnologie.
26 millions, ça semble pas mal, mais CIQ a 77 employés (cf linkedin), donc ça ne fait que 330k par personne, ce qui permet de tenir 1 ou 2 ans. Ça me semble pas ouf niveau finance. Et avec les conditions économiques, il me semble assez clair qu'un autre tour de table ne va pas arriver tout de suite.
Ce qui explique aussi pour CIQ tente à tout prix de se diversifier sur les HPC (le rebranding de Singularity en Apptainer, une offre autour de Warewulf via fuzzball), parce que clairement, c'est pas en offrant un OS gratos que les investisseurs vont être content, surtout en ce moment.
[^] # Re: Bonnes pratiques
Posté par Misc (site web personnel) . En réponse au lien CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent. Évalué à 4.
Ouais enfin, il faut 1) être root sur la machine en face 2) avoir quelqu'un qui utilise un forward d'agent.
Si 1 et 2 sont remplis, il faut bien voir que tu es déjà dans la merde vu que root peut juste taper dans ton socket et utiliser ta clé, et par exemple, dans des cas hypothétiques, faire un ssh pour revenir vers ta propre machine avec ton compte, ou ce genre de choses.
Je dit pas qu'il faut pas corriger, mais clairement, je pense qu'il n'y a pas trop lieu de paniquer dans la grande majorité des cas.
[^] # Re: Une moralité discutable
Posté par Misc (site web personnel) . En réponse au journal Kevin Mitnick bronsonisé. Évalué à 10.
Dans la mesure ou il a été en prison (pour des crimes relativement sans victime autre que "on a du dépensé de l'argent", càd "on a des gens qui ont été occupé 2 mois à faire des réunions"), il a purgé sa peine.
Je ne veux pas proposer de passer en mode "droit à l'oubli" complet, mais je trouve déjà que la prison pour un crime de ce genre, c'est beaucoup. Encore une fois, la privation de liberté, c'est une exception aux divers textes sur les droits humains fondamentaux (je vais m'autoriser une autocitation). C'est pas pour rien que certains partis d’extrême droite militent pour ne plus les appliquer (exemple, les Patriotes, le parti de Florian Philippot, qui a "sortie de la CEDH" dans son programme totalement hors sol et démago).
Si quelqu'un a payé le prix de ses actes (ce qui est rarement le cas pour beaucoup de morts, donc je ne veux pas généraliser), je trouve que c'est quand même être plus royaliste que le roi que de venir ressortir ça.
De plus, si on considère que regarder le casier judiciaire à l'embauche est illégal en France, et que par exemple, aux USA, c'est un mécanisme qui maintient certaines populations défavorisées (les latinos, les afroaméricains) dans la pauvreté à un niveau quasi générationnel, alors je pense qu'on peut légitimement se poser la question de savoir si c'est aussi une forme de prolongement/augmentation de la peine.
Je dit "se poser la question", car bien sur, tout les cas ne sont pas équivalents.
# Une précision (sans jeu de mot)
Posté par Misc (site web personnel) . En réponse au lien 15 lignes de code Python ≥ Google BERT. Évalué à 8. Dernière modification le 20 juillet 2023 à 10:34.
Il semble que le papier de recherche ne soit pas correct:
https://kenschutte.com/gzip-knn-paper/
[^] # Re: Bonnes pratiques
Posté par Misc (site web personnel) . En réponse au lien CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent. Évalué à 4. Dernière modification le 20 juillet 2023 à 10:27.
L'attaquand doit être root sur la machine en face (pour accéder à la socket transmise), et il faut avoir assez de libs sur la machine cible afin de construire un exploit spécifique en combinant des chargements/déchargements.
Je connais aucune des libs détaillés par qualys dans la démonstration, j'imagine à dessein pour ne pas rendre ça trop facile à utiliser. Mais du coup, c'est pas clair si c'est faisable facilement en dehors du cas spécifique d'ubuntu 20.04 par défaut.
(et à mon grand regret, ssh-agent n'est pas confiné avec selinux sur ma Fedora)
[^] # Re: "open source"
Posté par Misc (site web personnel) . En réponse au lien IA : Meta met la pression sur OpenAI et Google avec un modèle open source. Évalué à 5.
C'est la le souci. Se moquer des chiffres, c'est risquer de prendre des cas exceptionnels et en faire des généralités.
C'est ce qui est arrivé avec les paniques morales sur les enlèvements (ou les viols) dans la rue. On imagine que le probléme, c'est des étrangers dans la rue, alors que les chiffres vont montrer le contraire (à savoir les proches).
Ça veut pas dire que les premiers n'arrivent pas, mais comme c'est beaucoup plus présent dans la culture populaire, on oublie que les seconds sont bien plus présents.
Que visiblement, les accusations justifiées ne détruisent pas des vies, et sans preuve d'accusations injustifiées qui détruisent des vies (car tu n'en donne pas, et tu ne donne pas de chiffres), on ne peut pas être d'accord avec ta conclusion.
Les autres exemples que le viol, comme le fait d'avoir Johnny Depp à Cannes, Dave Chappel sur Netflix, Elon Musk devant Macron ?
Ou tu veux parler des exemples qui appuient ton point, exemples que tu ne donnes pas ?
Car bon, si tu penses que pointer la misogynie et le racisme est un souci car ça risque de détruire des vies (combien, le discours ne le dit pas), il faut mettre ça en balance avec la destruction causé par le racisme et la misogynie.
[^] # Re: "open source"
Posté par Misc (site web personnel) . En réponse au lien IA : Meta met la pression sur OpenAI et Google avec un modèle open source. Évalué à 3.
Je pense que cette affirmation manque de chiffres et de sources, parce que c'est aussi ce que certains disent pour les accusations de viol, et pourtant, il suffit de voir que Polenski n'est pas en tôle, que Woody Allen fait encore des films, PPDA n'a pas trop été inquiété, Louis CK fait encore des seuls-en-scène, (etc, etc je vais pas faire la liste).
Donc si les accusations graves ne changent pas grand chose, et sont rarement suivis de condamnations par la justice, j'ai du mal à voir de combien exactement de vies brisés on parle ?
Et comme personne ne donne jamais le moindre chiffre, ni même le moindre exemple, donc ça me semble plus être un argument par l'émotion (et donc, un peu manipulatoire au minimum) qu'une vérité vérifiable et quantifiable.
[^] # Re: "open source"
Posté par Misc (site web personnel) . En réponse au lien IA : Meta met la pression sur OpenAI et Google avec un modèle open source. Évalué à 7.
tout comme ça dépendrais de leur définition de "free software", le logiciel est gratuit :)
Visiblement, il n'y a pas que le monde qui a repris les termes de FB, cf ce tweet qui parle du souci pour ars technica:
https://meshed.cloud/@webmink/110737631559136143
L'OSI pointe aussi le souci.
# "open source"
Posté par Misc (site web personnel) . En réponse au lien IA : Meta met la pression sur OpenAI et Google avec un modèle open source. Évalué à 9.
Un juriste au taf a fait remarqué que la licence n'est pas vraiment open source.
Le point 2 "Additional Commercial Terms" par exemple, est le premier qui pose souci (et qui, contrairement aux autres plus loin, est sans controverse).
Je sais pas qui a utilisé le terme opensource entre le journaliste et Meta/FB, mais c'est une erreur grossière au mieux, au pire de l'openwashing manifeste.
Mais bon, ça semble déranger personne.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 3.
Alors que si ça avait été limité depuis le début, personne n'aurait rien dit.
C'est toujours amusant de voir que ce n'est pas tant l'état d'arrivé qui fait râler que le changement et la sensation de perte qui s'accompagne.
Et c'est d'autant plus intéressant que c'est une sensation de perte de quelque chose qui était vu comme gratuit, donc soit perçu comme sans valeur (au sens économique, cad que les gens ne veulent pas payer pour), soit payé par quelqu'un d'autre (dans le sens ou quelqu'un paye pour la maintenance).
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 4.
Oui, parce qu'on sait jamais si le probléme n'est pas déjà corrigé. Beaucoup de gens font pareil sur les projets libres en général, et ça n'a rien à voir avec la compatibilité, juste l'envie de ne pas perdre de temps sur ça.
Et en pratique, quand un programme tierce marche sur une distro X à un moment T et pas le lendemain d'une mise à jour, les clients râlent d'abord sur le dernier truc qui a changé en disant "vous avez cassé quelque chose". Et parfois, tu découvres que le logiciel dépend d'un comportement qui a en effet changé, mais qui n'était pas spécifié (et qui ne fait pas parti de l'ABI). Ou qui dépend d'un bug de sécurité, comme j'ai eu le cas ce matin avec woodpecker (j'ai un peu honte de ça).
L'exemple connu, c'est ce vieux bug avec flash et la glibc: https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
Le cas de Windows 95 et Simcity est un autre exemple connu, il a encore été cité en 2022.
Mais ça veut juste dire que tu as les mêmes paquets installés sur ton parc, pas que tu as les mêmes que le parc du voisin, ni le parc utilisé par les tests à un moment T par les vendeurs tierces ou les testeurs de RHEL. Ni même qu'ils ont été installés dans le même ordre ou au même moment.
Les installations de paquets ne sont pas déterministes, car l'ordre d'installation n'est pas forcément garanti (vu que les structures sous jacentes ne le sont pas forcément), et si des scripts de post installations sont impliqués, c'est encore pire.
C'était sauf erreur de ma part la conclusion d'un travail de recherche présenté lors d'une conférence en 2010 au FOSDEM, ou le présentateur a expliqué tout les soucis qui découlent d'avoir bash ou lua pour des scripts. Il est revenu l'année après avec une solution ou il remplace les scripts par un DSL d'actions limités et réversibles.
Et en fait, même la date d'installation du serveur peut jouer.
Les devs Openstack du bureau m'ont raconté un jour un bug épique. Je n'ai pas le détail, mais le contournement est détaillé ici. Le client avait fait les upgrades de tout son cluster depuis plusieurs versions, et à un moment, ça n'a pas marché. La QA n'a pas réussi à reproduire, on voyait bien que c'était un souci vis à vis de docker et du filesystem, mais c'est tout.
La solution est venu quand quelqu'un a tenté de refaire exactement le même parcours que le client (donc 6 ou 7 upgrades d'affilés) et a réussi à reproduire le souci. Et en effet, l'équipe QA a découvert que les partitions XFS déployéees en RHEL 7.0 n'était pas compatible avec ce que demande Docker (qui avait besoin d'overlayfs, qui a besoin d'autres choses, etc). L'intégration de docker a impliqué de faire un backport d'une fonction spécifique de XFS, fonctionnalité activé par défaut à l'installation des nouvelles versions (donc > RHEL 7.3) mais fonctionnalité manquante sur les serveurs du client car installés il y a trop longtemps (en 7.0).
C'est un cas extrême, mais ça montre bien qu'avoir exactement les mêmes binaires, ça peut ne pas suffire.
Et je suis sur que des cas comme ça (mais moins épique), mes collègues ont du en croiser souvent (moi, j'ai juste des bugs de merde comme le jour ou les tests de Gluster ont échoués car j'ai relancé Jenkins et le serveur a basculé en francais).
Et je parle pas des bugs dépendant du hardware, ou ce genre de trucs.
La compat bug pour bug, ça n'a aucun sens quand les bugs peuvent venir de partout en pratique.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 8.
Alors je ne sais pas ce que tu veux dire dans 1:1, mais si c'est semblable au "bug for bug" promis par Rocky, ça n'existe pas.
Comme l'a expliqué mieux que moi ma collègue qui a bossé sur ça:
https://quantum-integration.org/the-curse-of-bug-to-bug-compatibility
Avec les corrections de bug en tout genre, RHEL à un instant T n'est pas compatible bug pour bug avec RHEL à un instant T+1 ou T-1 car les paquets changent à cause des correctifs de bug. Et comme les clients appliquent les correctifs à leur vitesse et font un mix, il n'y a pas de garantie possible de toute façon.
Donc quand RHEL ne peut pas être compatible bug pour bug avec elle même (car les bugs sont corrigés tout les jours), je ne vois pas exactement ce que Rocky compte viser avec.
C'est pour ça que la doc de RHEL parle d'ABI stable, que les ingés vérifient ça avec des tests sur l'ABI (via une CI dont le code est sur le gitlab que j'ai pointé). Et si le but est de viser une ABI stable, Alma vise ça aussi, à partir de Centos Stream comme RHEL.
Ensuite, si tu veux dire quelque chose d'autre quand tu parles de 1:1 et que j'ai mal compris, je veux bien comprendre la différence et ce que tu mets derrière les mots, car plus je lit, moins je comprends pourquoi les gens râlent exactement (car j'ai pas le sentiment que grand monde sait exactement comment une distro est buildé en pratique, ni comment les changements sont gérés).
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 5.
La vraie question, c'est aussi de savoir de quoi on parle par "le code source".
Les patchs sont sur https://gitlab.com/redhat/centos-stream/rpms car les rpms de RHEL sont buildés à partir de Centos Stream (genre, les patchs vont d'abord dans Stream sauf de façon temporaire le temps d'un embargo de sécurité).
Par exemple, https://gitlab.com/redhat/centos-stream/rpms/dnsmasq est ce qui est utilisé pour dnsmasq.
Les fichiers specs sont aussi la, dans le même dépôt (et pareil que les patchs, ça va d'abord dans stream).
On va me dire "et les tarballs". Les tarballs sont sur le même système que Fedora, ça utilise un serveur nommé "Lookaside Cache" (et j'imagine que c'est le même, pas de raison de dupliquer les fichiers entre toutes les distros, les disques sont pas gratuits).
Que je sache, il n'y a pas de page d'index sur le serveur mais les sources sont dispos via l'outil centpkg (le pendant de fedpkg), outil libre et dispo sur https://git.centos.org/centos/centpkg/tree/develop
Et on peut scripter ça avec curl vu que les tarballs sont en https, si on a le hash et le nom pour adresser le fichier. Et dispo sans mot de passe.
Tout les logiciels sont libres.
Donc, quelle code source est manquant exactement ?
[^] # Re: Quelques remarques
Posté par Misc (site web personnel) . En réponse au journal Vous hébergez un serveur Mastodon ? Mettez-le à jour !. Évalué à 3.
Mais ton example, c'est un souci si l'attaquant peut choisir le nom entier du fichier, mais est ce le cas ? Et est ce qu'on peut vraiment mettre une URL complète dans un message activitypub sans que ça contredise la spec ?
Car si c'est le cas (eg, que ke nom d'un attachement est non filtré sous le controle complet d'un attaquant) alors il y a le cas de ffmpeg:
https://github.com/mastodon/mastodon/blob/d0f00206dc115cb3a21281b532c59a166c21ce71/lib/paperclip/transcoder.rb
ffmpeg qui est dans la même catégorie que magick en terme de risque: "couteau suisse, parse des tonnes de format, écrit en C, va lire des trucs de l'internet".
ffmpeg -i https://foo.example.org/image.jpg est valide. Du coup, si la spec permet d'avoir un fichier avec un nom qui commence par http pour les attachements, il faut filtrer plus que magick, mais ça n'est pas adressé.
Et comme tu le dit, magick peut utiliser le coder "screenshot" ou "x" pour taper ailleurs que dans les fichiers, et sauf erreur de ma part, ça n'est pas filtré (ensuite, c'est sans doute non fonctionnel).
J'ai testé la policy via https://imagemagick-secevaluator.doyensec.com/ et il y a pas mal de manque. Par exemple, pas de limite de mémoire, de disque, rien.
Donc non, je tente vraiment de comprendre mais pour ça, il faut visiblement plus que le patch, car je ne trouve pas le souci en pratique (en partie car le patch fait 4 choses différentes).
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 4. Dernière modification le 17 juillet 2023 à 15:33.
Dans mon souvenir, les équipes RHEL et Centos ont essayés de limiter les problèmes à ce niveau.
Quand tu regardes la doc de Centos sur ça pour Centos 7 et Centos 8, il y a eu beaucoup moins de problèmes avec Centos 8.
Ou il suffit de voir le fichier de Rocky, qui a moins à patcher sur Rocky 9 (13) que sur Rocky 8 (26):
https://git.rockylinux.org/rocky/metadata/-/blob/main/patch.yml
ou a debrander (voir la fin du fichier)
[^] # Re: Quelques remarques
Posté par Misc (site web personnel) . En réponse au journal Vous hébergez un serveur Mastodon ? Mettez-le à jour !. Évalué à 3.
Si je comprends bien, tu parles de la policy (fichier policy.xml), mais justement, c'est ça que je pige pas.
Je m'attends à ce que ImageMagick, sauf faille de sécurité, soit utilisable sans avoir de fichier policy.xml. Avoir une sandbox est une bonne chose, mais on parle d'ImageMagick, si le logiciel sans fichier policy.xml est troué par défaut, c'est un souci.
Donc quand j'examine le patch en détail, il touche 8 fichiers.
On peut retirer les tests et le mp3 de test qui va avec, ainsi que la modif de application.rb qui est la pour charger un autre fichier.
Il reste 5 modifs. Une est le fichier policy.xml, une pour utiliser le fichier en question. On va mettre ça de coté.
Il reste donc les 3 derniers bouts, à savoir:
- une classe MediaTypeSpoofDetectorExtensions
- une modif de transcoder.rb
- une modif de attachmentable.rb
De ce que je comprends, la derniére modif change juste la validation pour utiliser le type MediaTypeSpoofDetectorExtensions, ce qui permet de ne pas laisser passer certains mp3 mal détectés. C'est curieux d'avoir 2 libs pour trouver le type mime, mais on.
Et il reste que transcoder.rb, qui va échouer si on ne peux pas faire de transcoding au lieu de laisser passer ça à ImageMagick.
Donc on a:
- une meilleur vérification des fichiers transcodés (notament les mp3)
- on arrête le traitement si le transcodage échoue (mais quel traitement ? que fait mastodon à part du retaillage ?)
- une policy qui va bloquer le traitement de tout sauf les fichiers d'images, et qui va interdire le module URL.
Mais donc, les modules en questions, est ce que ImageMagick va les appeler sans demande explicite de l'utilisateur ?
Les fonctions des coders (plutôt des encodeurs et décodeurs) implique aussi de demander de les utiliser. Si je dit "transforme ce jepg en pdf", ça va appeler le coder pdf. Mais ça se fait pas sans une demande explicite via la CLI. Donc je pige pas, surtout que ImageMagick n'est pas directement appelé par le code, mais via paperclip (de ce que je comprends), donc il y a déja une couche d'astraction qu'on peut supposer sur (ou qui n'est pas documenté comme non sure).
Est ce que passer un fichier spécifique à ImageMagick dans sa config par défaut va être un souci de sécurité, ou est ce qu'il s'agit d'une faille dans l'instance si il y a une faille dans IM (auquel cas, il y a pas d'urgence sauf timing de merde, mais je vois personne dire "faut mettre à jour IM tout de suite")
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 4.
J'ai relu 3 fois mon commentaire, je ne croit pas avoir construit d’hypothèses sur les annonces, j'ai construit des hypothèses sur ce que j'ai constaté depuis des années pour Centos.
Ensuite, effectivement, j'imagine qu'on peut extrapoler des suppositions crédibles pour le futur de Rocky et Alma à partir du passé de Centos, si rien de substantiel ne change.
Et bien sur, peut être que je me trompe, et je serait ravi d'avoir des hypothèses alternatives sur ce qui est arrivé à Centos. Mais je crois que personne ne s'est vraiment penché sur ça, justement car la communauté n'avait pas d'appétence pour l'introspection, étant sans doute trop le nez dans le guidon avec une copie d'une RFC trouvé au Vatican pour en discuter en buvant du thé et échangeant des blagues en Francais.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 2.
Les sources sont sur https://gitlab.com/redhat/centos-stream/ depuis la release, non ?
[^] # Re: État des lieux
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 6.
L'ordre n'importe pas tellement, vu que dans les 2 cas, le résultat est le même, un certain contrôle du board qui va à l'encontre des objectifs affichés d'indépendance.
C'est bien d'avoir une calsue sur les votes, mais bon, la démocracie, c'est pas juste les votes, c'est aussi les discussions sur savoir ce qui est voté, la transparence, etc.
C'est ni la première fois, ni la dernière que ce genre de chose arrive dans le libre (ou ailleurs). Réussir à fédérer des entreprises concurrentes est une tache complexe et difficile. Le chemin choisi en général, c'est de passer par une fondation tierce déjà établie, mais C'est aussi quelque chose qui va te ralentir, donc pas forcément désirable d'un point de vue commercial (et on en revient aux visées commerciales de CIQ, une fois encore). Ou non désirable d'un point de vue fiscal (car il y a des considérations à filer une tonne de thunes à une organisation sans but lucratif qui produit un produit que tu es le seul à vendre, l'IRS n'aime pas ça)
La balance entre faire en sorte que le projet grandisse vite et que le projet grandisse de façon durable est encore une fois dur à atteindre, surtout quand c'est ton premier essai. Contrairement au board d'Almalinux (qui a benny Vasquez, Simon Phipps et Jack Aboutboul au bureau), j'ai pas le sentiment qu'il y a grand monde avec ce genre d'expérience chez Rockylinux. Leur CM me semble plus faire du marketing que de la communauté au sens ou les librites l'entendent (et elle n'est pas au board, ce qui est aussi une bonne indication de l'importance du sujet).
Et si le but est d'avoir un fonctionnement un peu plus communautaire et avec une séparation plus visible, il y a des étapes simples qui ne vont rien changer de substantiel à court terme tout en permettant de donner la bonne direction.
Par exemple, il suffit que CIQ file de l'argent à la RESF pour embaucher certaines personnes qui bossent sur Rockylinux. Ce qui me vient en tête, c'est ce que fait la fondation GNOME, ou la PSF en embauchant des sysadmins.
Autre example, faire en sorte que SUSE file l'argent à la RESF au lieu de prendre un contrat avec CIQ aiderais aussi pas mal sur la question de la diversité et de l'ISF mentionné plus haut.
Ou publier les comptes de façon plus régulières que le minimum légal, et de façon plus visible serait aussi un pas dans la bonne direction.
Il y a plein de choses qui pourraient être fait sans remettre en cause le modèle, mais qui ne sont pas encore faites malgré les 2 ans et demi depuis l'annonce de décembre 2020.
[^] # Re: Comment vont-ils faire ?
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 5.
Bah, avant IBM, le méchant, c'était "la bourse" ou "les actionnaires", comme si nos salaires n'avaient rien à voir avec le reste (sauf dans les boites rachetés, auquel cas le méchant, c'était RH, en bref, toujours un truc plus gros et moins humain, jamais son ancien patron).
Ce qui me fait rire avec les allégations à la sauce techrights, c'est à quel point ça simplifie le fonctionnement d'une grande boite.
Franchement, si une grande entreprise avait une hiérarchie aussi efficace et rapide qu'il l'imagine, on le saurait depuis longtemps. Il faut 6 mois pour faire valider l'utilisation d'un hébergement wordpress, mais à coté de ça, la boite a largement le temps de prévoir le truc le plus diabolique possible (comme systemd) juste pour prendre le controle des serveurs en retirant des bouts de bash que personne ne veut maintenir.
(et je le voit aussi avec le fedivers, voir les idées claquées au sol sur les histoires avec threads était assez révélateur)
[^] # Re: Selon Insider Intelligence (mai 2023)
Posté par Misc (site web personnel) . En réponse au lien Twitter a perdu près de la moitié de ses revenus publicitaires - letemps.ch. Évalué à 6.
Avec ou sans les dépenses pour procès ?
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 7.
Encore une fois, la différence entre RockyLinux/CIQ et AlmaLinux me semble assez révélatrice des différences pratiques des 2 groupes.
CIQ profite de l'annonce pour choper 10 millions d'US$ chez un concurrent (car SUSE est un concurrent de CIQ, les 2 visent à fournir du support sur une distro RHEL compatible), et Rockylinux, fortement contrôlée par CIQ (comme on a pu le voir plus haut), décide de viser la compatibilité bug pour bug, un des arguments utilisé commercialement par CIQ. La compat bug pour bug, ça n'a d'importance que pour les vendeurs tierces, le reste du monde est content de voir les bugs corrigés en général (sinon, pourquoi payer le support si c'est.
De manière que je trouve plus maligne sur le long terme, Alma décide de ne pas suivre RockyLinux, et de permettre à la communauté de faire vraiment ce qu'elle veut.
Car viser le "bug pour bug compatible", ça implique aussi de ne jamais rien changer par rapport à RHEL (sinon, c'est plus du bug pour bug), de ne pas fournir de correctif de bug ou de fonction en plus, et donc que la gouvernance technique reste entièrement chez Red Hat. Pour moi, c'est un antipattern de distribution communautaire, ça décourage assez vite les bonnes volontés.
Dans le cas de Centos, venir ouvrir des bugs et qu'on te réponde "on ne corrige rien, faut aller voir avec Red Hat", ça a vite impulsé une dynamique problématique sous forme de découragement.
C'est selon moi un des facteurs principaux de l'état de la communauté Centos vers 2014, à savoir surtout des gens la pour utiliser, et pas des gens pour contribuer au cœur de la distribution (ou ailleurs). Et après 2014, ça s'est aggravé, car quand RH a payé quelqu'un pour organiser les dojos Centos, la communauté a arrêté de s'en occuper après 2 ans en mettant les pieds sous la table.
[^] # Re: État des lieux
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 8.
Avoir une B-corp, ç'est classique (la Linux Foundation fait ça, AlmaLinux aussi, ainsi que l'OSI , mais pas la FSF que je sache).
Par contre, le bureau non élu, ça me parait pas super niveau communautaire :/
Et plus je regarde RockyLinux, plus ça me semble un peu louche.
Par exemple, sur la page web de la charte, on peut lire:
"RESF shall be structured and governed in a way that ensures that no single entity, organization, corporation, association, etc. will be permitted to have a controlling influence over the RESF or its projects"
C'est une bonne chose, et traduit dans le point 18 de l'article II des statuts, donc on ne peux pas dire que c'est du flan.
Mais malgré ça, en pratique, CIQ emploie plus d'une moitié du bureau affiché sur le site web.
Si on regarde le meeting de mars, ou il y a eu le vote du président, il y a eu 2 membres qui n'ont pas pris par au vote, car affiliés à CIQ. Et donc, en plus des 4 que j'ai listé, je voit que Sherif Negy bosse aussi chez CIQ (ce qui n'est pas sur Linkedin ), ce qui fait donc un total de 5 personnes maintenant au bureau pour le même employeur.
Le meeting du mois de janvier est aussi intéressant, car il n'y a presque personne de CIQ à ce moment (à part Gregory Kurster en tant que membre fondateur, et Brian Clemens en tant qu'externe), donc en 2 mois, il y a eu un quasi takeover du board.
Et je constate que les minutes de meeting de RESF sont globalement vides, publiées avec un retard croissant. Les minutes de mai sont arrivés début juillet, il n'y a rien pour celui de juin sur github. Personne ne semble mettre à jour le site web, car la liste ne montre que 3 mois et s’arrête à mars 2023, (voir en bas de la page). Donc c'est un peu les MM&S brun pour la transparence. Si les trucs sans importances ne sont pas fait, qu'est ce que ça va donner pour le reste :/
Quand je compare avec AlmaLinux, la différence est flagrante. Le board est beaucoup plus diversifié chez Alma, (cf la page sur le wiki ), le poste des membres du bureau clairement affiché (enfin, sauf pour Jack Aboutboul, qui ne dit pas que Moshe Bar, son PDG/ancien PDG, est aussi au board).
On voit aussi que les minutes des meetings sont détaillées, et à jour. Il y a des liens vers les différents documents discutés, et l'agenda du meeting suivant (août 2023) est déjà la. On voit qu'il y a des réunions depuis 2 ans, et que les membres de la communauté peuvent devenir membre du bureau via des élections ouvertes.
Ça me parait beaucoup plus propre et plus communautaire que Rockylinux. Et ça, c'est sans me pencher sur le focus constant sur le fondateur de la distro (Gregory Kurster), qui est pour moi un antipattern comme on a pu le voir avec la FSF en 2021.
[^] # Re: Quelques remarques
Posté par Misc (site web personnel) . En réponse au journal Vous hébergez un serveur Mastodon ? Mettez-le à jour !. Évalué à 4.
Ce qui revient à avoir une faille arbitraire dans ImageMagick, non ?
Le patch semble juste empêcher de faire passer un média arbitraire à ImageMagick.
Je vois bien comment ça pourrait poser probléme parce qu'ImageMagick a régulièrement des soucis (et donc, suffit de passer un fichier vérolé dans un format pourri, et voila), mais en pratique, quel attaque possible ne s'appuie pas sur une faille d'ImageMagick (et je compte le fait d'avoir un write arbitraire d'IM comm une faille d'IM ) ?
[^] # Re: État des lieux
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 6. Dernière modification le 16 juillet 2023 à 11:34.
Ça va un peu plus loin, car RESF (Rockylinux Entreprise Software Foundation), l'association qui gère Rockylinux, a pour président Gregory Kurtzer, fondateur de CIQ. Le project manager, listé aussi dans la catégorie Leadership est Brian Clemens, technico-commercial chez CIQ. Les 2 sont membres du bureau de l'assoce, qui contient 8 personnes.
Et si on regarde qui est aussi au bureau, le team lead sur l'infra, Neil Hanlon, est développeur chez CIQ, d’après son profil Linkedin. Mustafa Gezen, team lead sur la partie release engineering, est employé par CIQ (toujours linkedin).
Donc sur 8 membres du bureau, 4 sont dans la même boite, avec 3 qui ont un lien de subordination avec le fondateur et président de l'assoce et PDG du sponsor principal. Je sais que quand il y a un sponsor principal, c'est souvent ce qui arrive, car les non employés n'ont pas le temps de faire ce que les employés peuvent faire en terme de réunion et de travail, mais c'est quand même curieux que ça soit le cas pour un projet si récent.
CIQ a fait un premier tour de table de 26 millions de dollars en 2022, en plus des 4 millions initiales en 2021.
L'investisseur est Two Bear Capital, une boite fondé par un ancien de Sequoia Capital (qui a été une des premières boites à investire dans Facebook, d'aprés WP), et qui a aussi investi dans la biotechnologie.
26 millions, ça semble pas mal, mais CIQ a 77 employés (cf linkedin), donc ça ne fait que 330k par personne, ce qui permet de tenir 1 ou 2 ans. Ça me semble pas ouf niveau finance. Et avec les conditions économiques, il me semble assez clair qu'un autre tour de table ne va pas arriver tout de suite.
Ce qui explique aussi pour CIQ tente à tout prix de se diversifier sur les HPC (le rebranding de Singularity en Apptainer, une offre autour de Warewulf via fuzzball), parce que clairement, c'est pas en offrant un OS gratos que les investisseurs vont être content, surtout en ce moment.
[^] # Re: Comment vont-ils faire ?
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 5.
Faut arrêter le FUD sur ça et de reprendre les points de techrights.org, le blog complotiste de Roy Schestowitz.
Comme l'a dit un de mes ex-collègues (Ben Cotton)
"I wish folks would stop blaming everything on IBM. Red Hat is perfectly capable of making our own bad decisions."