En 2013, ce monsieur https://ryiron.wordpress.com/2013/12/16/argv-silliness/ prévenait sur la possibilité d'exploitation d'une faille dans pkexec parce que les arguments n'étaient pas correctement vérifiés.
Il proposa même un patch: https://pastebin.com/MheuF2UY
Problème, il semble que son mail ne soit jamais arrivé jusqu'à la liste de diffusion…
https://twitter.com/ryiron/status/1486207182404472832
On peut se dire qu'aujourd'hui, heureusement tout a changé, avec la démocratisation des github/gitlab favorisant la communication avec les mainteneurs d'un projet.
Pour ceux qui n'auraient pas suivi: https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034
# Un blog parmis tant d'autres
Posté par Christophe . Évalué à 10.
Manifestement, les mainteneurs de pkexec n'ont pas lu son blog. Et cela n'a rien de bien surprenant…
C'est un peu dommage de se donner la peine de faire cette analyse, un billet de blog, un mail, et de ne pas se demander pourquoi il n'y a aucune réponse au mail. Mais c'est vrai que la mailing-list ne répond peut-être pas à tous les mails d'inconnus, à cause du spam…
Fait amusant: aujourd'hui c'est via Twitter que cette information a réussi à être repérée. Et c'est vrai qu'une PR (ou MR pour Gitlab) est un peu plus visible et plus pratique !
[^] # Re: Un blog parmis tant d'autres
Posté par gouttegd (site web personnel) . Évalué à 10.
Sur la plupart des projets auxquels je contribue, il arrive assez régulièrement qu’un patch soit initialement ignoré, jusqu’à ce que son auteur envoie un second mail après une semaine ou deux pour dire un truc du genre « ping ! juste pour savoir si vous avez bien vu ce patch et le cas échéant ce que vous en pensez ? »
Souvent c’est une pratique qui est d’ailleurs encouragée par les mainteneurs eux-mêmes, qui disent aux nouveaux contributeurs « si votre patch reste sans réponse, peut-être qu’on ne l’a tout simplement pas vu passer, alors n’hésitez pas à nous relancer ! »
Envoyer un mail en mode « fire and forget », franchement sur pas mal de projets ça n’a pas beaucoup de chance d’aboutir à quelque chose.
Et je doute fort que les GitHub & Co y changent fondamentalement quoi que ce soit, parce que les tickets qui passent inaperçus jusqu’à ce que l’auteur poste un commentaire de relance, c’est assez fréquent aussi. C’est plus une question de disponibilités des mainteneurs qu’une question d’outil, à mon avis.
[^] # Re: Un blog parmis tant d'autres
Posté par RoyalPanda . Évalué à 10.
Juste sur ce point précis, je trouve au contraire que les outils de PR/MR facilitent grandement la visibilité et l'intégration des contributions, notamment autour des contraintes que l'on peut imposer en tant que mainteneur.
[^] # Re: Un blog parmis tant d'autres
Posté par gnumdk (site web personnel) . Évalué à 8.
Je reçois parfois des PR que j'ignore pendant plusieurs semaine avant d'aller voir sur le gitlab de mon projet. Plus simple que de faire des recherches sur des mails que j'ai pas lu.
[^] # Re: Un blog parmis tant d'autres
Posté par groumly . Évalué à 10. Dernière modification le 27 janvier 2022 à 18:24.
Heu, ben quand même, si. Ça change plutôt fondamentalement la gestion des bugs. C’est pas pour rien que l’immense majorité de l’industrie gère ses tickets dans un bugtracker que par e-mail, quand même.
Notamment, l’intégration continue permet de tagger les pr automatiquement, et de relancer automatiquement aussi si la pr est oubliée. Tu peux pas faire ça avec des e-mails.
Et ça permet à l’auteur de facilement vérifier si le bug à effectivement été créé, genre ce qui est arrivé ici.
Et un bug tracker reste bien plus simple et pratique à utiliser qu’une boite e-mail. Tu peux faire des filtre pour les tickets en cours de péremption, et avoir bien plus d’info attachées au patch.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un blog parmis tant d'autres
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -2.
Mouais, avoir besoin d'un bug tracker ne veut pas dire avoir besoin de Github & co ; et ça c'est bien fait avant ces boîtes (et ça continue de se faire sans eux.)
Pour la gestion par mails on va dire aux gens du noyau Linux (et ce ne sont pas les seuls) que ça ne fonctionne pas, parole de groumly. Et même que leur outil, Git, est conçu autour de cet aspect…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un blog parmis tant d'autres
Posté par groumly . Évalué à 10.
Bien sûr que ça peut se faire. Tu peux aussi écrire en os entier en carte perforée, c’est pas la question.
C’est pas parce que c’est possible que c’est une bonne idee, ni que les forges ne changent pas fondamentalement le problème.
Une pr ouverte, c’est une pr ouverte. Ça se voit, et ca se ferme pas par accident. Pareil pour un bug.
Un e-mail, ca se lit, et ca s’oublie tres facilement. C’est aussi tres facile de l’effacer par accident, et après le mainteneur le voit plus. Ou de le lire en vacance, l’oublier, et revenir une semaine après avec l’e-mail en question poussé au fond par 200 autres e-mails.
T’as un process qui se base sur des gens qui font des choses à la mano, avec possibilité de ne pas réussir à filer le bug d’un côté et un autre largement automatisé qui ouvre un monde de possibilité (et concret ce monde la, y’a une palanquée d’outils disponibles, et pas que pour github), en plus de rendre très difficile ce qu’il s’est passé ici (a savoir avoir un mail qui bounce et ne pas s’en rendre compte).
En l’occurrence on a une énorme couille dans le potage, qui mène à une cve qui aurait put être corrigée y’a 10 ans.
Soit le mail a été envoyé, les mainteneurs l’ont raté, et c’est 100% la faute d’un process foireux par e-mail qui aurait été beaucoup plus dur à reproduire avec une forge correcte.
Soit le mail a été bouncé, l’auteur n’a pas remarqué et c’est 100% la faute d’un process foireux par e-mail qui aurait été impossible à reproduire avec une forge correcte.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un blog parmis tant d'autres
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -2.
Tu es tellement dans ton truc que tu ne prends pas la peine de ne pas entendre que toi même. :-) Toutes tes explications jusqu'à présent ne justifient pas que Github est incontournable. Au passage, j'en vois sur github des projets où les "issues" ne sont jamais pris en compte. Bref.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un blog parmis tant d'autres
Posté par groumly . Évalué à 4.
Je sais vraiment pas quoi te dire.
L’immense majorité de l’industrie a laissé tomber ce process par e-mail entre autre pour ce genre de raisons.
C’est un enfer de gérer des bugs reports et patches de cette façon. On a un exemple douloureux qui démontre pourquoi ce process marche mal. Et t’es la en train de nous expliquer que si si ça marche très bien.
Linux s’en sort? La belle affaire, c’est bien les seuls. C’est comme si je t’expliquais que git n’est pas vraiment incontournable parce qu’openbsd s’en sort très bien avec cvs.
Est ce que Polkit aurait pu oublier ce bug en utilisant une forge correcte? Peut être, peut être pas.
Probablement pas pendant 10 ans. Et sûrement pas sans documenter pourquoi le patch a été refusé, genre comme ce qu’il s’est passé ici https://bugzilla.kernel.org/show_bug.cgi?id=8408
Le bug aurait peut être toujours existé pendant 10 ans, mais au moins le post mortem aurait pu permettre d’identifier quelle partie du process à foiré et quoi changer pour ne plus que ça arrive à l’avenir. Ou d’estimer si d’autres bug report ont été ignorés de la même façon (parce que oui, si c’est arrivé une fois, c’est potentiellement arrivé plusieurs fois, 10 ans, c’est une éternité à l’échelle d’un projet).
Après, si ton point c’est “‘well akshuall’y, un bug tracker ne rentre pas dans la catégorie forge/GitHub & co”, ok cool.
Super pertinent comme remarque 👍.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un blog parmis tant d'autres
Posté par Zenitram (site web personnel) . Évalué à 8.
Sans vouloir défendre la chose (je ne comprend pas pourquoi les gens restent sur ça, ça semble être du plaisir masochiste), en gros projet il y a aussi FFmpeg.
[^] # Re: Un blog parmis tant d'autres
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Il y a Yocto/Openembedded aussi. D'ailleurs j'ai essayé de leur envoyer un patch. J'ai passé une journée à configurer git send-email puis à trouver sur quelle liste de diffusion envoyer le truc. Mon patch a été complètement ignoré. J'en avais d'autre à envoyer mais si c'est pour que ça tombe direct dans un trou noir, ben… je vois pas l'intérêt…
Vu de l'autre côté, parfois j'ai besoin de savoir si telle fonctionnalité a été intégrée ou pas. Souvent je trouve un thread de mailing list (parce que Google indexe les archives de la mailing list, sinon je pourrais même pas faire ça), mais impossible de savoir si c'est mergé, et dans quelle branche (sachant que yocto c'est une nouvelle branche tous les 6 mois). Donc j'ai plus qu'à aller regarder toutes les versions une par une…
[^] # Re: Un blog parmis tant d'autres
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Fais gaffe, il va quand même penser que tu défends la chose. (après eux y trouvent une certaine facilité et du plaisir que tu trouves masochiste à ton niveau.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un blog parmis tant d'autres
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Idem. Je ne dis plus rien parce-que tu t'évertues à vouloir travestir mes mots et me faire dire ce que je ne dis pas.
Ce que je reproche c'est ce genre de formulation : « l'immense majorité de l'industrie … » immense + majorité …vu de la lorgnette qu'on a, et l'accumulation des mots pour faire croire qu'il n'y a que ça. Et tu poursuis :
Les autres réponses vont dans mon sens ; y a pas que Linux, y aussi FFmpeg et Yocto/Openembedded et bien d'autres qui souvent ne font pas de vague. Tu pars du principe que ça n'existe pas parce-que tu n'en entends pas parler et je dis juste attention à ne pas généraliser trop vite.
Mais comme le mode de pensée du Français est « si tu ne penses pas comme moi c'est que tu es contre moi » alors tu refuses d'entendre toute nuance et déforme tout ce que je pointe et qui ne semble pas aller dans ton sens.
Tu as l'air de penser que je suis en train de défendre bec et ongles le « process par mail » alors que je t'invites juste à prendre de la hauteur… Ma réponse initiale était juste que
Ça tombe bien, j'ai le cas chez un client avec des équipes indépendantes. Une équipe qui utilise Subversion et qui s'en tire bien sur tous ses projets, et une équipe qui utilise Git et même un compte entreprise sur gitlab mais qui n'arrête pas d'accumuler des échecs. La première équipe a mis en place des process bien rodés avec parfois de vieux outils et ça marche. La seconde mise tout sur les outils et utilise les dernières technos, mais au bout de dix ans c'est la dissolution pour arrêter le gouffre financer : les outils ne font pas tout tout seuls, et pourtant cette équipe ne cesse de clamer qu'elle fait ce que « l'immense majorité de l'industrie » fait. Cette équipe est, pour moi, la preuve que les amalgames et raccourcis pour la hype de quelque techno ça résout pas le schmilblick.
Aussi pertinent que ta réponse qui consistait à dire « il leur faut un bug tracker donc github » et quand on te le fait remarquer d'argumenter que « toute l'industrie utilise github et puis si t'es pas d'accord c'est que tu défends leur process par mail » Peut-être qu'on ne peut juste pas se comprendre parce-que je vis dans un monde trop subtile où des glissements évidents pour toi n'ont pas lieu d'être.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un blog parmis tant d'autres
Posté par groumly . Évalué à 1.
T’en tiens une couche toi.
il n’y a que toi que fait ce raccourci. L’auteur du journal mentionne gitlab, le commentaire racine aussi, le commentaire auquel j’ai répondu itou, et j’ai impliqué que y’a pas que github comme forge. J’ai même fait attention à ne pas tout mettre sous github, d’où mon usage du mot “forge”.
c’est marrant quand même, t’as cité presque tout mon message, sauf la partie où je dit exactement ça.
Qu’est ce que tu disais a propos de ne pas écouter les nuances?
T’as franchement pas dit grand chose, à part “les mecs du kernel Linux font tout par e-mail” et “on peut faire du bug tracking sans GitHub”.
lol. Ma première install de Linux etait en 2000. Une mandrake en boite que j’avais acheté à Auchan. Et je m’étais mangé une bonne année de Linux avant ça à la fac. Trac n’existait même pas à cette époque.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un blog parmis tant d'autres
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
gouttegd : Et je doute fort que les GitHub & Co y changent fondamentalement quoi que ce soit
groumly : Heu, ben quand même, si.
[On oublie les questions de process pour se focaliser sur les outils… mais il n'y a pas de glissement, pas de raccourci…]
Gil Cot : Mouais, avoir besoin d'un bug tracker ne veut pas dire avoir besoin de Github & co
[On a beau mettre en garde contre l'association qui a été faite entre forge et bug tracker, ça va quand même se poursuivre avec tentative d'inversion des propos]
groumly : C’est pas parce que c’est possible que c’est une bonne idee, ni que les forges ne changent pas fondamentalement le problème.
[toujours pas d'amalgame forge bug-tracker ? pourtant ça va même dériver loin]
Si tu as perçu ces deux points, et surtout le dernier alors c'est bon. (Le premier point est un contre-exemple de l'amalgame qui devait faire comprendre que le mail n'empêche pas le suivi et grumdk a expliqué que c'est toute une autre machinerie qui va avec, mais faut prendre de la hauteur pour percevoir ce point.)
Ils ont besoin de faire du suivi, c'est le nœud du problème on est tous d'accord je crois. Comment faire ce suivi est une autre affaire à laquelle je me garde de répondre par "forge" c'est tout. (gouttegd dans sa réponse pointait aussi le fait que la forge ne résolvait pas automagiquement les problèmes de suivi parce-qu'il s'agit de processus humains avant tout, quelque soit les outils –même si selon le contexte du projet des outils peuvent rendre les choses plus fluides que d'autres mais il ne faut pas raisonner par rapport à des outils d'abord ni vouloir à tout prix plaquer son écosystème à soi…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un blog parmis tant d'autres
Posté par groumly . Évalué à 3.
Ok, je vais arrêter la.
Soit t’as de graves problèmes de logique et de compréhension du français, soit tu refuses d’admettre que t’as ergoté sur un point de détail dont tout le monde se fout éperdument.
Quoi qu’il en soit, on tourne en rond la.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un blog parmis tant d'autres
Posté par gnumdk (site web personnel) . Évalué à 2.
Euh, la plupart des projets libres n'ont absolument pas la force de frappe du noyau Linux ou beaucoup de devs sont justement juste là pour lire, faire corriger et intégrer les "Merge Request".
Tu compares des trucs incomparables là.
[^] # Re: Un blog parmis tant d'autres
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Tu as tout à fait raison. :-)
Comme tu le décris, ils ont des « process » et font du suivi… Le point est là : il faut du bug-tracking et on doit se donner les moyens en accord avec la chaîne d'outillage qu'on choisi de mettre en œuvre. L'erreur est d'opposer courriel et suivi, qui ne sont pas des mots antinomiques.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un blog parmis tant d'autres
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Ah il faut venir peurer et supplier pour qu'un mainteneur daigne simplement dire "ok on va regarder"?
Désolé mais j'ai autre chose à faire, moi aussi…
Quand je reçois une contribution à un de mes projets, je l'oublie pas et je fais en sorte de répondre même si ça peut prendre quelques jours. Je m'attends à ce que la personne qui a envoyé le patch puisse éventuellement prendre en compte des commentaires et proposer une version améliorée (ou si c'est pas le cas, je fais le nettoyage moi-même).
Mais je vais pas demander aux gens d'envoyer leur patch plusieurs fois, jusqu'à que quelqu'un l'attrape au vol, parce qu'il y a aucun outil sérieux pour gérer les patchs proposés et s'assurer qu'ils le sont pas juste oubliés.
C'est assez frustrant de prendre le temps de prépamer un patch, de le mettre au propre, de trouver où il faut l'envoyer, pour que au final ce soit juste ignoré. Moi ça me donne pas envie de courir après les projets dans lesquels ça arrive pour qu'ils intègrent mes patches à tout prix. Tant pis pour eux, je vais maintenir ma branche moi-même…
[^] # Re: Un blog parmis tant d'autres
Posté par ff9097 . Évalué à 10.
C'est pas bête, je me demande si quelqu'un y a pensé avant.
[^] # Re: Un blog parmis tant d'autres
Posté par windu.2b . Évalué à 3.
Il ne suffit pas d'y avoir pensé : encore faut-il ne pas oublier d'y (re)penser !
[^] # Re: Un blog parmis tant d'autres
Posté par Christophe . Évalué à 10.
Et après ces nombreuses contributions passées à la trappe par erreur, personne ne se dit que le process doit être amélioré ?
Je ne suis pas de cet avis. Tu as deux problèmes distincts:
GitHub & co ne va pas régler le premier problème. Aucun process ne le pourra: quand il y a trop de boulot, il faut trier. Et encore, ce tri est bien facilité avec un système de tickets ! Donc même si la bande passante reste la même, elle est sûrement mieux utilisée.
Par contre, le second problème est largement amélioré. Car un email, comme tu l'as dit, ça s'oublie ou se manque facilement. Le ticket, lui il reste là, dans la liste. Si des tickets plus récents sont créés puis résolus, il va redevenir plus visible.
Pour moi il n'y a pas photo: un système de tickets est une énorme amélioration pour gérer les demandes.
# "heureusement tout a changé"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Mais oui, maintenant certains projets ont des robots qui ferment automatiquement les issues et les merge requests sur leur compte github/gitlab si personne ne répond au bout de 15 jours.
Certes, gérer les patches avec une mailing list, c'est tout pourri, mais il n'y a peut-être pas qu'un problème de choix d'outils.
[^] # Re: "heureusement tout a changé"
Posté par Philippe F (site web personnel) . Évalué à 5.
Les PR ne font pas tout. Pour un projet populaire comme mypy (vérification de typage pour Python), il y a plus de 2000 issues ouvertes et 140 PR. L'équipe derrière est une petite équipe, c'est pas forcément gérable d'avoir autant de choses à revoir et possiblement intégrer.
[^] # Re: "heureusement tout a changé"
Posté par groumly . Évalué à 7.
Non, c’est sur, le tooling ne peut magiquement rallonger les jours de 48 heures.
Par contre, gérer 2000 bugs et 140 pull request par e-mail ne me parait pas le plus efficace. Je suis sur que ça peut être fait (genre le kernel), mais ça demande beaucoup plus de boulot, et surtout, ça veut pas dire que ça doit être fait. #jurassicpark
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: "heureusement tout a changé"
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 5.
Mauvais exemple car justement j’arrive à suivre certaines PR sur MyPy parce que les tickets sont dans une forge, qu’on faire des référence entre PRs et tickets et suivre tout ça.
Ça m’empêche pas de recevoir des emails sur les tickets/PRs suivis, mais si je loupe le mail, je peux quand même suivre l’information sur la forge.
Aparté :
matchde Python 3.10, c’est pas une mince affaire à faire avaler à Mypy ![^] # Re: "heureusement tout a changé"
Posté par barmic 🦦 . Évalué à 4.
Je vois pas en quoi c'est particulièrement problématique (le choix de 15 plutôt qu'une autre durée peut être discutable, mais c'est un choix). Ce qui est utile c'est que tout le monde vois le choix qui est fait pour cette MR ou issue.
Quitte à critiquer github et consort, il y a des problématiques de spam importante comme l'hacktoberfest (après on pourra se demander si c'est vraiment un problème résolu dans les listes de diffusion avec le problème du journal).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: "heureusement tout a changé"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Le problème de hacktoberfest est réglé hein. Maintenant les projets qui souhaitent participer doivent s'inscrire (en ajoutant un tag spécifique sur leur dépôt git).
Et ça n'a effectivement rien à voir avec github/gitlab si ce n'est que ces outils centralisés permettent à digitalocean (l'organisateur de hacktoberfest) de vérifier si des pull requests ont bien été faites par un compte github/gitlab avec une API de façon automatique.
Et puis, pas de problème de spam dans un système basé sur les e-mails? Sérieusement?
[^] # Re: "heureusement tout a changé"
Posté par barmic 🦦 . Évalué à 4.
J'ai vu des projets se faire spamer ou harceler sur github. Le fait d'avoir déjà le compte et d'avoir un contrôle limité sur les interactions ne permet pas de l'empêcher.
Comme je le dis dans ma dernière phrase, non. Mais le fait d'avoir un contrôle potentiellement total sur le système te donne la responsabilité à toi en tant que projet de trouver ta solution.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Un alias pour les soucis de sécurité
Posté par Misc (site web personnel) . Évalué à 10.
Alors il reste aussi la solution de l'alias pour les soucis de sécurité, genre security@.
Sauf qu'au dela du souci de spam et de mail, il y a les gens qui envoient des mails pour dire "le code de votre application est dispo sur cette url" (véridique, moins depuis que le projet a bougé sur github), ou "votre jenkins est exposé sur 8.43.85.184" (d’où le fait d'avoir maintenant une bannière sur le jenkins).
Mon favori, c'est "regardez, j'ai pu spoofé le from de cete email, il faut mettre dmarc, merci de me filer une récompense pour le bug" alors que l'email n'est pas spoofé (et quand je réponds parce que je suis un mec sympa, ignore mon email et envoie ça 3 fois d'affilé).
C'est pas grand chose, mais je suppose que par rapport au nombre moyen de souci de sécurité, ça fait un ratio signal/bruit assez haut.
Et du coup, l'avantage d'une forge par rapport à une liste de discussion, c'est que tu es sur que ton patch est soumis au projet, contrairement à ce qui s'est passé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.