Et pourtant, une mutation relativement importante aurait eu lieu, à priori peu après l'adoption massive de l'agriculture, sur 2 continents, et se serait propagée comme une traînée de poudre: la mutation qui fait que l'on peut consommer du lait après 5 ans.
Les documents que j'ai lus sur le sujet indiquent que les scientifiques supposent (tout en admettant ne pas savoir) que ce serait lié au fait que le lait est l'une des boissons les plus hydratantes (plus que l'eau, parce que bien que constitué de 80% seulement d'eau, les matières grasses et sels minéraux rendraient l'élimination plus lente, donc plus de temps pour l'eau d'être métabolisée), et le lien à l'agriculture serait que l'agriculture, en rompant avec le mode de vie des chasseurs-cueilleurs qui à "manger varier, bouger!" a aussi introduit la notion de ville, ou la concentration est importante, et donc la pollution des eaux.
Je ne suis ni paleo-historien, ni médecin, ni rien de scientifique, mais l'explication me semble crédible, d'autant plus que c'est plus ou moins le même genre que l'explication de pourquoi les anciens coupaient le cidre a l'eau pour les enfants: faibles ressources d'eau potable comparé au besoin. Qui pourrait bien être une légende, évidemment, mais d'un autre côté, pourquoi faire l'effort de produire du cidre et de le mélanger, si l'eau suffit pour vivre au quotidien?
Bref, l'humanité a bel et bien évolué biologiquement du fait de ses développements technologiques et pratiques, même si c'était à priori il y a environ 5000 ans.
Il y a peut-être (probablement, parce que je doute que ce genre de choses n'apparaissent qu'une seule fois!) d'autres mutations de ce type, il faudrait demander a ceux qui savent.
Je suis plus d'avis qu'ils vont réduire les trains sur les lignes surchargées pour mettre la priorité a ceux liés aux J.O..
J'ai toujours trouvé les évènements sportifs mondiaux comme un gâchis phénoménal de fric, qui serait bien mieux utilisé dans, disons, la maintenance (la vraie, hein, pas la communications qui consiste a renommer les agences et changer leurs logo), mais faut pas rêver, priorité aux copains, pas aux travailleurs utiles (surtout s'ils sont smicards).
Après réflexion, c'est sûrement la raison, plus que mon histoire de montage en RO sans /tmp/ ou /run/.
Oui, ça et la capacité a faire transiter des descripteurs de fichiers. Pas besoin des cgroups pour savoir qui envoie un message par contre, ça fait partie des «ancillary data» que l'on peut récupérer.
Mais ceci dit, tu peux aussi passer par une socket abstraite (sous Linux) qui n'est pas sur le disque
Je ne suis pas sûr de ce que tu appelles une socket abstraite, je n'ai pas souvenir avoir vu cette notion avant? Et pour rappel, même si je me doute que tu le sais, avoir un système de fichiers ne nécessite pas d'avoir un périphérique de stockage local, typiquement NFS et les ramdisk sont très utiles pour ça (et l'une des raisons pour lesquelles je mets mes fichiers de runit dans un ramdisk, c'est justement pour permettre de booter avec root en ro. Pas utile dans la plupart des cas, mais mes scripts sont déjà prêts, alors tant qu'a faire, autant réutiliser :D).
Je suis quand même peu convaincu par l'idée que créer un pipe par daemon serait lourd. Le nombre de daemon a créer est connu dès le départ, après tout.
Je pense vraiment que c'est lié au transfert de FDs, vu que je ne vois pas d'autres moyens d'implémenter ce truc:
FDSTORE=1
Store file descriptors in the service manager. File
descriptors sent this way will be held for the service by the
service manager and will later be handed back using the usual
file descriptor passing logic at the next start or restart of
the service, see sd_listen_fds(3).
Pareil pour un socket si ma mémoire est bonne. Les pipes ne sont pas forcément nommés, mais un pipe non nommé serait plus intrusif.
D'un autre côté, je ne vois pas comment exécuter un programme sur un FS sans supporter de FS au préalable, et les gens de systemd ont justement poussé, de mémoire, pour bouger tout /bin et /sbin vers /usr, qui requiert, justement, que /usr soit monté sur /. Si tu peux exécuter un daemon géré par systemd, c'est que systemd a monté les partoches avant. Y compris /dev, qui inclue /dev/shm, qui est un ramdisk.
[edit]
D'ailleurs, le nom attendu dans la variable d'environnement est un fichier, donc oui, clairement, ce point ne change rien comparé à un af_unix tel que fait actuellement. CE point, j'insiste.
Tu noteras que j'ai pas cité sr.ht comme l'endroit ou j'ai envie d'aller. Je l'ai surtout utilisé comme second example, pour montrer que la réponse existe en plusieurs versions.
Ah, je crois que c'est parce qu'un pipe ne permets pas de savoir qui écrit dedans, alors qu'un socket af_unix permets de récupérer pas mal d'info sur le processus qui émets un message, notamment son PID, si ma mémoire me trompe pas. Et les pipes n'ont pas ça.
On peut aussi faire transiter des descripteurs de fichiers via un socket, ce qui semble utilisé par certaines autres fonctionnalités du protocole sd-notify, qui, au final, ne me semble pas si "simple" que prétendu par LP (vu que plus que le strict minimum).
On peut quand même, je pense, regretter que systemd utilise un socket AF_UNIX pour ça, et pas juste un pipe.
Un simple pipe aurait éviter de s'emmerder avec sockaddr_un & co, ça aurait pu éviter ce bloc:
memset(&addr,0,sizeof(addr));addr.sun_family=AF_UNIX;if(strlcpy(addr.sun_path,path,sizeof(addr.sun_path))>=sizeof(addr.sun_path)){error_f("socket path \"%s\" too long",path);gotoout;}/* Support for abstract socket */if(addr.sun_path[0]=='@')addr.sun_path[0]=0;if((fd=socket(PF_UNIX,SOCK_DGRAM,0))==-1){error_f("socket \"%s\": %s",path,strerror(errno));gotoout;}if(connect(fd,&addr,sizeof(addr))!=0){error_f("socket \"%s\" connect: %s",path,strerror(errno));gotoout;}
qui représente une portion non-négligeable du patch d'OpenSSH. J'imagine que le socket est réutilisé pour autre chose par libsystemd0, mais tout de même.
Il y a peut-être (probablement!) d'autres aspects auxquels je ne pense pas, ceci dit. Ca fait longtemps que j'ai pas pratiqué.
Disons qu'au moins, quand libsystemd ne chargera ses dépendances que si elle en a besoin, les systèmes sans systemd serons moins vulnérables aux failles introduites dans la chaîne d'approvisionnement de systemd.
Je ne sais pas si l'attaque qui nous occupe aie pu introduire une faille sur ces systèmes, mais une prochaine aurait très bien être "systemd-agnostic", et du coup il se peut que ça aide.
A noter, je n'ai pas été lire le code de libsystemd0, je ne sais donc vraiment pas.
Le patch est long, car OpenSSH a décidé de faire une option de build pour ne pas l'intégrer à la construction. Si on enlève ce détail, la fonction C static void ssh_systemd_notify(const char *fmt, …) n'est effectivement pas si horrible.
C'est pas horrible, mais j'avoue avoir tendance a tiquer quand je vois des fonctions qui se reposent sur va_args.
Alors, j'ai bien vu l'usage ici, c'est pour refiler le boulot de concaténation/formatage à la libc, mais je suis assez intrigué par la nécessité réelle de ceci, pas tout a fait "just send NOTIFY=1 to an AF_UNIX socket" (ou un truc du genre):
l'exemple détaillé, c'est f-droid, qui n'a pas accepté le code, et qu'il n'y a rien qui parle de "bullying" pour XZ (juste que le dev principal prends des pauses de temps en temps).
Je ne lis pas ça, perso, mais plutôt qu'il y a eu une insistance de la part d'un contributeur pour merger un code, et que ce contributeur a eu le soutien d'un nombre inconnu de vrai utilisateurs (entre 0 et N).
Je trouve en effet le terme bullying de la part de 404 trop fort, par contre. J'imagine que c'est la recherche de retenue qui a échoué sur un 404, comme d'hab avec la "presse" (on pourrait arguer qu'un titre non provocateur ne sera pas lu, parce que noyé dans la masse des infos "choc!". C'est peut-être vrai, je ne sais pas.).
La gestion des contributions externes est loin d'être simple… une chose importante a prendre en compte ici, c'est: est-il possible d'installer la fonctionnalité d'un f-droid forké sur sa machine, ou existe-t-il une dépendance directe à un truc hébergé?
Dans le 2nd cas, on peut effectivement comprendre (en supposant l'auteur de la PR bugguée non pourvu de mauvaises intentions).
A priori, vu le nom du repo, ce n'est pas le cas, par contre.
Pour avoir survolé les changements de la requête de fusion (j'insiste, survolé. Je ne connais pas le code de fdroidclient, et je ne suis pas un dev java alors une analyse complète de ma part serait malvenue), le diff me parait quand même simple. Ce qui me questionne le plus, c'est pourquoi une PR pour changer la fonction de recherche modifie tant d'images? Ca augmente la masse apparente de revue nécessaire, après tout.
Le fait qu'à priori il ne soit pas possible de naviguer entre les commits dans gitlab n'aide pas ( "a priori" != "a fortiori". On utilise le 1er quand on n'a pas poussé assez les recherches. Petit rappel au cas où.).
Je me pose aussi la question de savoir combien de gens sont impliqués dans fdroidclient? A priori (cf plus haut) cette information est bien planquée, si elle existe. En fonction, on peut se poser la question de la disponibilité.
Après, évidemment, il est probable que personne ne soit payé, et donc il est compliqué de demander un travail. Certes. Mais le pendant c'est que l'auteur potentiellement de bonne foi ne l'est pas non plus. Bref, c'est compliqué.
La question principale pour moi ici, c'est: l'utilisateur peut-il utiliser ses modifications sans avoir a ce qu'elles soient fusionnées en amont. Si oui, je suppose qu'en effet l'insistance est mal-venue: rien n'empêche de forker quand les besoins d'infrastructure sont nuls. Bien sûr, un tel fork s'il est annoncé va user les claviers de ceux qui n'ont rien d'autre a faire que dire que ça va encore fragmenter, et bla bla.
Dans l'autre cas, c'est plus compliqué, surtout si le projet parent prétend en effet recevoir aisément les contributions de code.
Je me base sur cet example précis, mais je n'ai creusé, et ma réflexion s'applique plutôt à un cas général.
Pour palier à ça, […] mais la décentralisation [n'aide pas] non plus
Ben, c'est même pire: avec la décentralisation, il est difficile de pointer sur toutes les instances qu'un document joue délibérément sur l'affect, la persuasion, au lieu d'être objectif et convainquant.
Mais bon, je n'ajoute ça que parce que c'est le jour.
Je suis entièrement d'accord que ce truc de monter dans les tours, y compris sur des trucs qui ne nous regardent bien souvent pas, est typique des réseaux sociaux, qui sont simplement la massification des presses «people».
Avant, seuls voici et voila pouvaient vomir leurs âneries et avoir une audience, maintenant, même dédé le pillier peut avoir un public qui dépasse les 10 âmes (en supposant que les mouches n'en aient pas, élément essentiel a garder une certaine moralité dans de nombreux propos tenus sur linuxfr, car autrement on risque de nombreux procès, vu ce qu'elles peuvent prendre parfois).
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.
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.
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.
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)
[^] # Re: Réactionnaire
Posté par freem . En réponse au lien « Impact catastrophique » : le gouvernement explore le bannissement des smartphones des collèges . Évalué à 2 (+1/-1).
Et pourtant, une mutation relativement importante aurait eu lieu, à priori peu après l'adoption massive de l'agriculture, sur 2 continents, et se serait propagée comme une traînée de poudre: la mutation qui fait que l'on peut consommer du lait après 5 ans.
Les documents que j'ai lus sur le sujet indiquent que les scientifiques supposent (tout en admettant ne pas savoir) que ce serait lié au fait que le lait est l'une des boissons les plus hydratantes (plus que l'eau, parce que bien que constitué de 80% seulement d'eau, les matières grasses et sels minéraux rendraient l'élimination plus lente, donc plus de temps pour l'eau d'être métabolisée), et le lien à l'agriculture serait que l'agriculture, en rompant avec le mode de vie des chasseurs-cueilleurs qui à "manger varier, bouger!" a aussi introduit la notion de ville, ou la concentration est importante, et donc la pollution des eaux.
Je ne suis ni paleo-historien, ni médecin, ni rien de scientifique, mais l'explication me semble crédible, d'autant plus que c'est plus ou moins le même genre que l'explication de pourquoi les anciens coupaient le cidre a l'eau pour les enfants: faibles ressources d'eau potable comparé au besoin. Qui pourrait bien être une légende, évidemment, mais d'un autre côté, pourquoi faire l'effort de produire du cidre et de le mélanger, si l'eau suffit pour vivre au quotidien?
Bref, l'humanité a bel et bien évolué biologiquement du fait de ses développements technologiques et pratiques, même si c'était à priori il y a environ 5000 ans.
Il y a peut-être (probablement, parce que je doute que ce genre de choses n'apparaissent qu'une seule fois!) d'autres mutations de ce type, il faudrait demander a ceux qui savent.
[^] # Re: "Mais qui aurait pu prédire"
Posté par freem . En réponse au lien Les promesses pas vraiment tenues des JO 2024 à Paris. Évalué à 10 (+14/-0).
Je suis plus d'avis qu'ils vont réduire les trains sur les lignes surchargées pour mettre la priorité a ceux liés aux J.O..
J'ai toujours trouvé les évènements sportifs mondiaux comme un gâchis phénoménal de fric, qui serait bien mieux utilisé dans, disons, la maintenance (la vraie, hein, pas la communications qui consiste a renommer les agences et changer leurs logo), mais faut pas rêver, priorité aux copains, pas aux travailleurs utiles (surtout s'ils sont smicards).
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 2 (+0/-0).
Oui, ça et la capacité a faire transiter des descripteurs de fichiers. Pas besoin des cgroups pour savoir qui envoie un message par contre, ça fait partie des «ancillary data» que l'on peut récupérer.
Je ne suis pas sûr de ce que tu appelles une socket abstraite, je n'ai pas souvenir avoir vu cette notion avant? Et pour rappel, même si je me doute que tu le sais, avoir un système de fichiers ne nécessite pas d'avoir un périphérique de stockage local, typiquement NFS et les ramdisk sont très utiles pour ça (et l'une des raisons pour lesquelles je mets mes fichiers de runit dans un ramdisk, c'est justement pour permettre de booter avec root en ro. Pas utile dans la plupart des cas, mais mes scripts sont déjà prêts, alors tant qu'a faire, autant réutiliser :D).
Je suis quand même peu convaincu par l'idée que créer un pipe par daemon serait lourd. Le nombre de daemon a créer est connu dès le départ, après tout.
Je pense vraiment que c'est lié au transfert de FDs, vu que je ne vois pas d'autres moyens d'implémenter ce truc:
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 3 (+1/-0). Dernière modification le 07 avril 2024 à 15:47.
Pareil pour un socket si ma mémoire est bonne. Les pipes ne sont pas forcément nommés, mais un pipe non nommé serait plus intrusif.
D'un autre côté, je ne vois pas comment exécuter un programme sur un FS sans supporter de FS au préalable, et les gens de systemd ont justement poussé, de mémoire, pour bouger tout /bin et /sbin vers /usr, qui requiert, justement, que /usr soit monté sur /. Si tu peux exécuter un daemon géré par systemd, c'est que systemd a monté les partoches avant. Y compris /dev, qui inclue /dev/shm, qui est un ramdisk.
[edit]
D'ailleurs, le nom attendu dans la variable d'environnement est un fichier, donc oui, clairement, ce point ne change rien comparé à un af_unix tel que fait actuellement. CE point, j'insiste.
[^] # Re: Réaction de GitHub
Posté par freem . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0).
Tu noteras que j'ai pas cité sr.ht comme l'endroit ou j'ai envie d'aller. Je l'ai surtout utilisé comme second example, pour montrer que la réponse existe en plusieurs versions.
[^] # Re: Réaction de GitHub
Posté par freem . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0).
C'est pas plus mal, parce qu'avoir des tonnes de trucs comme pppd serait un peu gênant :)
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 7 (+5/-0). Dernière modification le 07 avril 2024 à 07:19.
Vous ne passez pas! Bon, dommage alors.
Ah, je crois que c'est parce qu'un pipe ne permets pas de savoir qui écrit dedans, alors qu'un socket af_unix permets de récupérer pas mal d'info sur le processus qui émets un message, notamment son PID, si ma mémoire me trompe pas. Et les pipes n'ont pas ça.
On peut aussi faire transiter des descripteurs de fichiers via un socket, ce qui semble utilisé par certaines autres fonctionnalités du protocole sd-notify, qui, au final, ne me semble pas si "simple" que prétendu par LP (vu que plus que le strict minimum).
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 5 (+3/-0). Dernière modification le 07 avril 2024 à 07:14.
On peut quand même, je pense, regretter que systemd utilise un socket AF_UNIX pour ça, et pas juste un pipe.
Un simple pipe aurait éviter de s'emmerder avec sockaddr_un & co, ça aurait pu éviter ce bloc:
qui représente une portion non-négligeable du patch d'OpenSSH. J'imagine que le socket est réutilisé pour autre chose par libsystemd0, mais tout de même.
Il y a peut-être (probablement!) d'autres aspects auxquels je ne pense pas, ceci dit. Ca fait longtemps que j'ai pas pratiqué.
[^] # Re: C'est quand même très provoc
Posté par freem . En réponse au lien Bullying in Open Source Software Is a Massive Security Vulnerability. Évalué à 2 (+0/-0).
D'où l'éventail large que j'ai utilisé :D
[^] # Re: oups
Posté par freem . En réponse au lien Solution pour ceux qui ne veulent pas lire les licences. Évalué à 2 (+0/-0).
Pas mal! Merci.
[^] # Re: oups
Posté par freem . En réponse au lien Solution pour ceux qui ne veulent pas lire les licences. Évalué à 2 (+0/-0).
Je trouve qu'on ressent bien l’agressivité et le type de relation entre les parties impliquées dans les ToS, oui.
[^] # Re: Et si on réduisait la dépendance à systemd ?
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 3 (+1/-0).
Disons qu'au moins, quand libsystemd ne chargera ses dépendances que si elle en a besoin, les systèmes sans systemd serons moins vulnérables aux failles introduites dans la chaîne d'approvisionnement de systemd.
Je ne sais pas si l'attaque qui nous occupe aie pu introduire une faille sur ces systèmes, mais une prochaine aurait très bien être "systemd-agnostic", et du coup il se peut que ça aide.
A noter, je n'ai pas été lire le code de libsystemd0, je ne sais donc vraiment pas.
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 4 (+2/-0).
C'est pas horrible, mais j'avoue avoir tendance a tiquer quand je vois des fonctions qui se reposent sur va_args.
Alors, j'ai bien vu l'usage ici, c'est pour refiler le boulot de concaténation/formatage à la libc, mais je suis assez intrigué par la nécessité réelle de ceci, pas tout a fait "just send NOTIFY=1 to an AF_UNIX socket" (ou un truc du genre):
Il s'agit peut-être d'une extension d'OpenSSH ceci dit.
# oups
Posté par freem . En réponse au lien Solution pour ceux qui ne veulent pas lire les licences. Évalué à 2 (+0/-0).
Me suis trompé, ce n'est pas les licences, mais les termes de service, désolé!
[^] # Re: C'est quand même très provoc
Posté par freem . En réponse au lien Bullying in Open Source Software Is a Massive Security Vulnerability. Évalué à 4 (+2/-0).
Je ne lis pas ça, perso, mais plutôt qu'il y a eu une insistance de la part d'un contributeur pour merger un code, et que ce contributeur a eu le soutien d'un nombre inconnu de vrai utilisateurs (entre 0 et N).
Je trouve en effet le terme bullying de la part de 404 trop fort, par contre. J'imagine que c'est la recherche de retenue qui a échoué sur un 404, comme d'hab avec la "presse" (on pourrait arguer qu'un titre non provocateur ne sera pas lu, parce que noyé dans la masse des infos "choc!". C'est peut-être vrai, je ne sais pas.).
La gestion des contributions externes est loin d'être simple… une chose importante a prendre en compte ici, c'est: est-il possible d'installer la fonctionnalité d'un f-droid forké sur sa machine, ou existe-t-il une dépendance directe à un truc hébergé?
Dans le 2nd cas, on peut effectivement comprendre (en supposant l'auteur de la PR bugguée non pourvu de mauvaises intentions).
A priori, vu le nom du repo, ce n'est pas le cas, par contre.
Pour avoir survolé les changements de la requête de fusion (j'insiste, survolé. Je ne connais pas le code de fdroidclient, et je ne suis pas un dev java alors une analyse complète de ma part serait malvenue), le diff me parait quand même simple. Ce qui me questionne le plus, c'est pourquoi une PR pour changer la fonction de recherche modifie tant d'images? Ca augmente la masse apparente de revue nécessaire, après tout.
Le fait qu'à priori il ne soit pas possible de naviguer entre les commits dans gitlab n'aide pas ( "a priori" != "a fortiori". On utilise le 1er quand on n'a pas poussé assez les recherches. Petit rappel au cas où.).
Je me pose aussi la question de savoir combien de gens sont impliqués dans fdroidclient? A priori (cf plus haut) cette information est bien planquée, si elle existe. En fonction, on peut se poser la question de la disponibilité.
Après, évidemment, il est probable que personne ne soit payé, et donc il est compliqué de demander un travail. Certes. Mais le pendant c'est que l'auteur potentiellement de bonne foi ne l'est pas non plus. Bref, c'est compliqué.
La question principale pour moi ici, c'est: l'utilisateur peut-il utiliser ses modifications sans avoir a ce qu'elles soient fusionnées en amont. Si oui, je suppose qu'en effet l'insistance est mal-venue: rien n'empêche de forker quand les besoins d'infrastructure sont nuls. Bien sûr, un tel fork s'il est annoncé va user les claviers de ceux qui n'ont rien d'autre a faire que dire que ça va encore fragmenter, et bla bla.
Dans l'autre cas, c'est plus compliqué, surtout si le projet parent prétend en effet recevoir aisément les contributions de code.
Je me base sur cet example précis, mais je n'ai creusé, et ma réflexion s'applique plutôt à un cas général.
[^] # Re: C'est quand même très provoc
Posté par freem . En réponse au lien Bullying in Open Source Software Is a Massive Security Vulnerability. Évalué à 3 (+1/-0).
Ben, c'est même pire: avec la décentralisation, il est difficile de pointer sur toutes les instances qu'un document joue délibérément sur l'affect, la persuasion, au lieu d'être objectif et convainquant.
Mais bon, je n'ajoute ça que parce que c'est le jour.
Je suis entièrement d'accord que ce truc de monter dans les tours, y compris sur des trucs qui ne nous regardent bien souvent pas, est typique des réseaux sociaux, qui sont simplement la massification des presses «people».
Avant, seuls voici et voila pouvaient vomir leurs âneries et avoir une audience, maintenant, même dédé le pillier peut avoir un public qui dépasse les 10 âmes (en supposant que les mouches n'en aient pas, élément essentiel a garder une certaine moralité dans de nombreux propos tenus sur linuxfr, car autrement on risque de nombreux procès, vu ce qu'elles peuvent prendre parfois).
[^] # Re: Donaldville
Posté par freem . En réponse au journal Au sujet des blagues du 1er avril. Évalué à 3 (+1/-0).
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?
[^] # Re: J'apprécie certaines blagues
Posté par freem . En réponse au journal Au sujet des blagues du 1er avril. Évalué à 3 (+1/-0).
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.
[^] # Re: J'apprécie certaines blagues
Posté par freem . En réponse au journal Au sujet des blagues du 1er avril. Évalué à 2 (+0/-0). Dernière modification le 04 avril 2024 à 12:48.
Mais du coup, pour un bon poisson d'avril, il faut juste sortir un truc tellement banal que personne n'en douterait, non?
[^] # Re: Combo glibc/systemd
Posté par freem . En réponse au journal Xz (liblzma) compromis. Évalué à 5 (+3/-0).
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.
[^] # Re: Combo glibc/systemd
Posté par freem . En réponse au journal Xz (liblzma) compromis. Évalué à 3 (+1/-0).
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.
[^] # Re: Confiance
Posté par freem . En réponse au journal Xz (liblzma) compromis. Évalué à 3 (+1/-0).
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.
[^] # Re: Combo glibc/systemd
Posté par freem . En réponse au journal Xz (liblzma) compromis. Évalué à 2 (+0/-0).
Non, de BSDauth
[^] # Re: Réaction de GitHub
Posté par freem . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0). Dernière modification le 04 avril 2024 à 12:07.
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)
[^] # Re: Réaction de GitHub
Posté par freem . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 3 (+1/-0).
Sauf que du coup, ça rend la lecture du problème et de l'historique nettement plus compliquée.