freem a écrit 4909 commentaires

Mais non, c'est simplement qu'eux s'entraînent toute l'année pour trouver un truc bien pour le 1er avril, c'est pourtant évident non?

Même pour du code ou autre.

Dans le cas du code, il est quand même 'achement pratique de savoir si oui ou non on peut utiliser ça selon ses contraintes (genre un compilo un peu vieux…).

Dans le cas de "autres" mon préféré, c'est blender. L'interface de ce logiciel peut être comparée à des sables mouvants, et donc savoir l'année de la parution d'une vidéo (c'est moche, mais c'est une des principales sources d'infos…) est très utile.
Bon, je tiens a insister sur le fait que la doc de Blender a été grandement améliorée sur ce sujet, et que de toute façon, je ne suis qu'un béotien qui s'y essaie littéralement 2 jours tous les 3 ans, depuis 15 ans. Pas vraiment celui dont l'avis est important :)
Mais ça reste, je crois, un bon example de l'importance d'avoir les dates.

Mais du coup, pour un bon poisson d'avril, il faut juste sortir un truc tellement banal que personne n'en douterait, non?

Et un dernier souci, c'est à mon avis la difficulté à imposer une norme dans certaines écosystèmes comme le C.

Autotools sont considérés comme obsolète par pas mal de monde, pour le coup. Et a juste raison. Je fais partie des gens qui ont essayé, et qui ont pris leurs touches de clavier à leur cou.
Cmake est largement moins mauvais, et permets même de remplace make par ninja d'un claquement de doigts (c'est pratique, parce que ninja, contrairement à make, sait vraiment gérer le parallélisme, je n'ai jamais eu de logs qui se mélangent avec, alors qu'avec make…).
C'est plus ou moins le standard de fait, bien que, certes, Meson soit aussi assez populaire (probablement parce que python).

Quant aux écosystèmes des langages modernes… moi, ça m'agace prodigieusement de devoir me battre contre mes outils pour qu'ils n'aillent pas télécharger la moitié du grand nain ternet. Je suis un vieux con, je suppose.

utiliser un paradigme déclaratif pour leur buil

Avec un outil comme ninja par exemple? Officiellement, il faut pas l'écrire à la main, mais je fais ça pour mes projets perso. Alors certes, c'est pas porté (mais c'est portable, il suffit d'inclure un fichier que les gens modifierons selon leur système…) mais comparé aux "alternatives" (cmake, meson, make, etc), c'est… reposant.

Je ne suis pas d'accord, parce que justement AD est un élément phare, il y a des gens payés pour le maintenir, et, j'ose espérer, une infrastructure de test.

Certes, il y a un côté historique… sauf que non, mauvaise excuse, MS était déjà riche lors de la création: «Active Directory fut présenté pour la première fois en 1996, mais sa première utilisation remonte à Windows 2000 Server Édition en 1999. » source: https://fr.wikipedia.org/wiki/Active_Directory

AD est composé de kerberos de mémoire, donc oui ils sont au courant que la sécu c'est important.
Vu les moyens a dispo, non, pas trop d'excuse.

Mais bon, on peut parler d'apple et du goto-fail… cette faille est la plus honteuse dont j'aie entendu parler, et pourtant, je ne crois pas que la confiance envers apple ait été rompue? (alors que franchement! Les compilos détectent ça depuis perpette, et le très peu que je connais de MISRA spécifie quand même bien que, bon, on va éviter hein, les "if" sans blocs… pour cette raison.)

Bref, pour moi, ce n'est pas lié a la licence, tous ces problèmes. Et, encore une fois, il semble qu'ici la faille ne soit jamais entrée dans le repo git, donc la faille n'est pas technique, mais humaine, et du côté des distros qui ont accepté une tarball, pas du côté de l'auteur.
Alors que les failles de sécu d'AD ou du TLS d'apple, c'est bien rentré dans leurs repos, à priori.

Non, de BSDauth

Et il y a eu beaucoup de contributions externes? Parce que c'est un peu l'intérêt majeur de sourceforge, github et gitlab, pour moi.

D'ailleurs, c'est lent ton site, non? Un problème de charge, peut-être? Chez moi, cliquer sur un lien semble prendre plusieurs secondes, pourtant les pages ont l'air relativement dénuée de bloat. Je ne sais pas.
En tout cas, j'imagine bien qu'il ne doit pas y avoir système de CI sur tes projets (je t'avoue que sur mes trucs perso, je m'embête pas non plus, hein, mais certains utilisateurs de "forges publiques" raffolent de ça. La plupart, peut-être même)

Sauf que du coup, ça rend la lecture du problème et de l'historique nettement plus compliquée.

Je ne suis pas d'accord, l'auto-hébergement c'est une plaie, surtout quand il faut commencer a trouver un moyen pour que les autres puissent faire des rapports de bugs ou envoyer des contributions (non, de nos jours, les mails ne sont plus la solution préférée de la plupart, va falloir s'y faire).
Moi, mes projets de dev, c'est pour les coder, la forge, c'est un moyen pas une fin.
D'un point de vue pragmatique, je pense qu'il est plus efficace d'utiliser une forge existante avec un minimum d'éthique moins liée au pognon (il y a toujours un lien, faut bien payer l'infra, et quelqu'un doit le faire. Tant que la finance est la, ça marche, mais ça peut toujours tomber… exactement comme pour l'auto-hébergement, en fait!).
Je me permets d'en citer 2 qui sont intéressantes:

• codeberg ressemble plutôt pas mal à GH/GL, bien que l'interface (et le code, évidemment) change, forcément;
• sourcehut est une forge intéressante, mais de mon point de vue, c'est un peu le souk;

Et pour la forme, une forge certes libre mais à éviter (selon moi) parce que sérieux, j'ai essayé il y a quelques années, mais… je vous laisse juster le cas de savannah (il fut un temp ou il y avait une non-gnu aussi, je sais pas si ça existe encore).

J'ai du mal a voir le troll dans un ensemble d'informations vérifiées et clairement explicitée par le fameux mail qui informe, pour le coup.
Même si ça ne va pas plaire a tous, ça reste la vérité pure.

Bon, je ne doute pas que musl pourrais aussi avoir ses propres failles (c'est juste tellement moins utilisé, que c'est moins rentable a attaquer, je suppose), mais du côté systemd, ce n'est pas la première fois qu'il y a de sérieux problèmes de sécurité réseau qui y sont liés.
Et, oui, pour un init+watchdog, ça interroge.
init+watchdog, (et même d'autres fonctions je crois) parce que systemd n'est pas juste l'init, c'est aussi et surtout un watchdog/gestionnaire de services, et le PID2 est tout aussi critique que le PID1, donc l'argument de diviser pour réduire les problèmes de sécu potentiels est un peu foireux pour moi (mais! ça permets d'avoir runsvdir qui tourne sans avoir a être suid ou lancé par root).

Puisque je répond a un essai de troll, je me permets d'ajouter que, oui, je trouve ennuyeux que les systèmes d'authentification utilisent des bibliothèques dynamiques (i.e. PAM) au lieu d'avoir un daemon qui file les descripteurs de fichiers via AF_UNIX comme le font plan9 ou OpenBSD (enfin, c'est ce que j'ai compris).
Vu que je n'ai pas lu en grands détails le descriptif de la faille, je suis probablement à côté de la plaque, et vu que je tape un peu n'importe ou, ça me fait 2 bons gros points de troll :)

mais dans le monde opensource, des briques essentielles maintenues par des acteurs vulnérables, c'est quelque chose d'endémique

Bon, alors parlons de microsoft, et d'active directory. Il suffit de lire misc magazine, même avec une faible fréquence, pour comprendre que ce truc ressemble quand même vachement à un sacré gruyère.
Et pourtant, MS est l'un des acteurs majeurs du non-libre, et AD un de ses éléments phares…

Je ne connais pas grand chose a ce sujet, mais très clairement, des quelques misc que j'ai, un ratio assez élevé mentionne AD, et ça exclue les titres que je n'ai pas achetés mais dont j'ai feuilleté les pages (quand je ne suis pas capable de comprendre assez d'articles, je n'achète pas :))

Certes, mais l'analyse me semble évidemment largement facilitée de par cette propriété du logiciel libre: code source disponible (je sais que des logiciels non libres ont aussi cette propriété, mais ce n'est pas trop la norme des logiciels non libres faits par Apple ou Microsoft, et ici, on parle bien d'OS).

Je trouve que renoncer à toute la confiance qu’on a pu établir avec un projet, avec ces développeurs/mainteneurs, précisément lors d’un coup dur de ce type, c’est le comble de la bêtise.

Très clairement. Perso, j'ai toujours confiance, et je ne compte pas patcher mon système pour supprimer cet outil extrêmement utile.
L'auteur n'y es pour rien, maintenir seul un outil critique bourré de crypto et de maths ne doit pas être simple, l'erreur est humaine, et se faire arnaquer peut arriver à tout le monde.
Je n'accepterais d'envisager l'idée qu'il est a tort que s'il est effectivement payé pour son travail sur xz, et ce, sur son temps professionnel. Et encore… ici, il n'est pas l'auteur de la faille, qui n'est d'ailleurs apparemment pas arrivé dans l'historique du code. Je ne vois vraiment pas comment lui en vouloir.

Il serait plus justifié d'en vouloir aux distributions qui ont empaqueté un blob de sources sans vérifier que le blob proviens bien du référentiel commun. Pour moi, c'est de ce côté que la sécurité est à améliorer au vu de ce que j'ai lu de cette faille.
Et ça serait, ici aussi, plutôt malvenu, parce qu'encore une fois, au moins dans le cas de Debian (et bien d'autres distros), ce travail est fourni gratuitement, c'est un service au monde, un coup de main.
Que celui qui n'a jamais merdé lance la première pierre.

Oui, je sais, c'est mal de laisser les autres essuyer les merdes :)

Ce qui veut bien dire que je suis content que certains le fassent. Si personne ne le faisait, cette backdoor aurait pu avoir des conséquences dramatiques.

Honnêtement, je ne voulais pas "crâner", mais juste préciser que seule unstable est touchée (le titre induit en erreur sur ce point).

Tu noteras notamment ces éléments dans mon message:

Oui, je sais, c'est mal de laisser les autres essuyer les merdes :)
…
Ceci dit, je suis surpris que Debian ne construise pas ses paquets à partir du repo, justement

Je pensais ces éléments explicites sur le fait que je n'incendie pas l'auteur de xz, et que je ne considère pas Debian comme toute blanche pour cette vulnérabilité, j'ai manifestement manqué d'insistance.

Je plains sincèrement l'auteur de xz, qui se retrouve a nouveau seul, et en plus il est fort probable qu'il se fasse aussi attaquer indirectement, genre "bouh, t'as pas fait ton taf de vérif ce que les contribs[…]".

Je sais que Debian a son lot de problème. D'ailleurs, celui-ci en est aussi un, du moins, il semblerait que ce soit à cause de patch pour supporter systemd que sshd est compromis, et systemd dépends de xz (mais! dpkg aussi, qui est au coeur du système. Pas d'accès réseau, cela dit, mais ça reste dangereux, ce genre de trucs peut probablement avoir des conséquences non voulues (y compris par l'auteur du malware).
Non, ce n'est pas la faute de systemd (je le dis clairement, trolldi c'était hier, et si on précise pas, ça risque de partir en sucette ce type d'élément) mais: «openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma».

Du coup, j'en déduit qu'un openssh non patché, vanilla, comme je pourrais supposer que Archlinux (bleeding edge, pour le coup) utilise (il paraît qu'ils ne patchent pas après tout?) n'est pas affectée.

Je ne sais pas si cette backdoor peut avoir d'autres points d'entrée?

Oui, ça à l'air de déchirer! Un simple "pertinent" ne me suffisait pas, même si ce commentaire n'ajoute rien. Je tiens à préciser qu'en général, je me méfie des trucs en python (ne pas chercher de raison a un truc subjectif, merci), mais ici, l'intérêt me semble largement dépasser mon habituelle résistance (au changement?).

Dans ce cas, ils auraient juste a demander que les commits soient signés, ce qui se fait de manière automatique facilement, sans avoir a se faire chier à ajouter des étapes.
La seule chose qui importe vraiment, ce sont les commits dans les PRs, pas les tickets ni les PRs elles-mêmes.

Au pire, laisser aux projets le choix de forcer cet usage ou non, mais pour les 90% (au jugé) des projets, non, c'est stupide de faire ça, ça ajoute juste des étapes pour ce qui est, vraiment, un loisir (utile à la société, certes, mais et alors?).

Voila. Improbable n'est pas impossible, je pensais que cette notion serait plutôt maîtrisée, ici, mais à priori je me trompais.

Sache que je perçois bien l'ironie de ton message, mais moi, ça m'énerve au plus haut point ce gâchis, que je qualifies volontiers de corruption.
Ces mêmes ordures (oui, c'est le bon mot) qui veulent réduire les droits des travailleurs licenciés ou dont le contrat n'a pas été renouvelé, sont 100 fois moins utiles à la sociétés que ceux qu'ils écrasent, et touchent mille fois plus.

Ces parasites ne méritent que mon mépris. Et, vraiment, France-travail, ça me rappelle Vichy. Il suffirait d'ajouter le culte du paternel président, et on a la totale: France, travail, patriarche, ou dit autrement: travail, famille, patrie.

J'ai peur à ma France, celle dont le fronton des mairies continue malgré tout d'afficher des valeurs auxquelles j'adhère… pour combien de temps?

particulièrement si vous êtes avec un debian ou dérivée. Debian a une version corrigée "5.6.1+really5.4.5-1", Arch Linux une version 5.6.1-2.

Euh…. non? Pas Debian stable, en tout cas, celle qui est recommandée pour les utilisateurs normaux ou les power users qui ne veulent plus se prendre trop la tête:

i A  --\ libsystemd0                                                                                                                
[...]
--\ Dépend (6)
    --- libc6 (>= 2.34)
    --- libcap2 (>= 1:2.10)
    --- libgcrypt20 (>= 1.10.0)
    --- liblz4-1 (>= 0.0~r122)
    --- liblzma5 (>= 5.1.1alpha+20120614)                                                                                                                      
    --- libzstd1 (>= 1.5.2)

Donc, même si j'utilise pas systemd, et que je considère ce truc over-engineered, non, c'est faux, il n'est pas affecté, au moins dans la lib 0.

Ensuite, de toute façon:

i A  --\ xz-utils                                                                                                                   
[...]
--\ Dépend (2)
    --- libc6 (>= 2.34)
    --\ liblzma5 (>= 5.4.0)
i A   5.4.1-0.2                                                                                

Alors, si le sujet était Debian testing ou Debian unstable, merci de le préciser. Parce que je suis prêt à parier une tournée dans mon pub préféré que la majorité des debianneux utilisent la stable. Justement pour éviter ce genre de problèmes, en fait.

Ceci dit, merci pour l'info, ça me conforte… dans mon choix de ne pas utiliser de distro bleeding edge. Oui, je sais, c'est mal de laisser les autres essuyer les merdes :)

Ceci dit, je suis surpris que Debian ne construise pas ses paquets à partir du repo, justement, je trouve ça très surprenant, compte tenu du fait que de nombreux paquets ont leurs propres patchs, que ce soit pour dé-veroller (chromium, et plein d'autres qui téléphonnent à la maison) ou pour améliorer l'intégration.
Le lien fournit par la réponse au sujet d'Ubuntu confirme d'ailleurs mon intuition première: Debian Unstable. C'est la porte d'entrée, hein, les trucs la dedans ne sont pas considérés fiables, et cette histoire montre pourquoi, du coup.

Ca ne serait acceptable pour moi que si et seulement si ça inclue un accès gratuit pour les citoyens a la version limitée/lente, un peu dans le modèle des autoroutes vs routes.
Et bien sûr, la limitation doit ne jamais s'appliquer aux sites gouvernementaux ou permettant l'accès aux comptes bancaires, entres autres éléments critiques.

Maintenant, pour implémenter ça, bonne chance, quand on voit le niveau de connerie naturelle qui est habituellement déployé par les politiciens français en matière de technologie… Parce que hein, ils ont pas fait les grandes écoles pour rien, ces gens la.

c'est assez peu fondé.

Il faut dire aussi que la religion chrétienne n'est pas super amatrice de la sexualité avec le fondement. Pourtant, ça éviterais l'usage de préservative, eux aussi pas très catholiques selon certains intégristes.

Je faisais ça… quand j'étais au lycées, parce que je n'avais pas d'ordi portable (et puis ça serait sûrement pas passé à l'époque).

Ca se fait, c'est sûr, mais c'est pénible. Par contre il y a une étape qui se fait très bien sur papier, et je dirais même mieux que sur PC: les divers diagrammes qui décrivent les grosses lignes de l'architecture. Peut-être qu'il existe des logiciels vachement adaptés pour ça, mais j'ai pas encore trouvé perso. J'ai bien testé bouml, dia ou même des scripts basés sur graphviz (c'est ce qui marche le mieux pour moi en logiciels, jusqu'a présent, et c'est pratique a versionner) mais rien à faire: une feuille, un gomme, un critérium, ça marche juste mieux.

C’est vraiment mon avis de béotien en développement logiciel que je donne là mais je trouve dommage de fermer le développement par principe. Je veux dire, c’est pas parce que tu acceptes les contributions que tu t’engages à toutes les considérer, à t’investir pour chacune.

Perso, je pense qu'il vaut mieux que les projets soient clairs sur leur politique de ce point de vue, justement pour éviter:

Alors c’est sûr qu’à un moment les contributeurs vont se dire : « Mais qu’il aille bien se faire foutre ce projet si on se casse le cul, qu’on propose des patches, et qu’on a même pas une réponse ! »

Si le projet est clair sur la politique et les objectifs, moins de frustration pour ceux qui s'en servent et ont besoin de le modifier.

La seule raison que je vois de, typiquement, garder privé les rapports de bug, c’est chercher à les dérober à la vue des utilisateurs potentiels.

Pour moi, les contributions de patch et de rapport de bug sont très, très différentes. Un rapport de bug, bien que déjà utile (enfin, ça dépend, on voit nombre de rapports de "bug" sur github ou le rapporteur a juste la flemme de lire la doc… et ne parlons pas des feature requests complètement à l'ouest…), ce n'est qu'une description d'un comportement erroné. C'est relativement rapide a faire, comparé à un patch.