Bonjour Ô journal,
bien qu'épuisée par de nombreuses lectures en ligne je m'en viens faire un effort exceptionnel pour rapporter ces nouvelles effrayantes : tous nos systèmes sont vulnérables, libres ou non libres, surtout parmi ceux les plus couramment utilisés. Ce qui inclut aussi les ordiphones (en français dans le texte).
https://www.cert.ssi.gouv.fr/alerte/CERTFR-2017-ALE-014/
les systèmes affectés, je cite, sont
- Windows
- Linux
- Android
- Apple
Évidemment… tant qu'ils utilisent du wifi. Que faire ? Lire cet article (en anglais), https://www.krackattacks.com/ éventuellement à la suite de cette lecture, passer à BSD – pas très pratique… quand on ne l'a pas dans le smartphone ! Changer le type de connexion wpa… Lire l'annonce, agir en conséquence.
En guise de premier pas, comme mon ordiphone est hors d'âge et non éligible à LineageOS, je vais me contenter du forfait data lorsque proche d'un hotspot.
# Déjà traité ici
Posté par Christophe HENRY (site web personnel) . Évalué à 10.
La nouvelle a déjà été publiée ici : https://linuxfr.org/users/ckiller/journaux/wpa2-est-bronsonise
# déjà corrigé
Posté par elf32 . Évalué à 9.
wpa_supplicant est déjà patché, et ce depuis peu de temps après la découverte de la faille. Il suffit de mettre ce paquet à jour sur ta Linux.
[^] # Re: déjà corrigé
Posté par Marotte ⛧ . Évalué à 10.
wpa_supplicant est déjà patché, et ce depuis peu de temps après la
découvertepublication de la faille.[^] # Re: déjà corrigé
Posté par elf32 . Évalué à 3.
Oui, tout à fait, désolé pour l'imprécision ;)
# Bonjour
Posté par Marotte ⛧ . Évalué à 10.
Ce qui est généralement le cas, les données sont chiffrées au niveau applicatif…
La faille permet il est vrai de tenter ce genre d’attaque mais le ton alarmant de ton journal est pas vraiment justifié.
[^] # Re: Bonjour
Posté par anaseto (site web personnel) . Évalué à 7.
En défense du journal, je dirais quand même que les sources officielles font aussi preuve d'un peu d'alarmisme, comme on peut en juger par la médiatisation de la chose. Ce qui explique aussi sans doute pourquoi c'est pas si surprenant qu'on se retrouve avec un journal doublon, journal qui se fait à mon avis trop sévèrement moinser, ça arrive à tout le monde de rater un journal.
[^] # Re: Bonjour
Posté par Maclag . Évalué à 10.
C'est une faille dans le processus de vérification de journaux rapportant les publications de failles.
Je publie immédiatement un journal avec une solution pour remédier au problème!
-------------> [ ]
[^] # Re: Bonjour
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 29 octobre 2017 à 09:29.
Oui mais quand il s'agit de relater un fait d'actualité (vieux de qques jours), on peut aussi aussi faire l'effort de rechercher un journal précédent.
Bon, c'est pas toujours facile avec les titres parfois assez éloignés, mais en l'occurrence, un journal contenant WPA2 dans le titre, datant de moins de 2 semaines… c'était faisable.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Bonjour
Posté par anaseto (site web personnel) . Évalué à 10.
C'est bien ce que je dis, on n'a visiblement pas droit au moindre faux pas : je ne suis pas en train de dire qu'il faut trouver le journal pertinent. Le précédent journal de l'auteur du journal date visiblement d'il y a trois ans : c'est pas comme s'il s'agissait de réprimander un contributeur turbulent. Un petit commentaire bon enfant pour dire, youhou, t'as raté le réveil, ça date d'il y a deux semaines, et pis c'est la mort, les BSDs aussi sont affectés, mais t'inquiète c'est pas si grave, c'est suffisant et plus contributeur-friendly, je trouve :)
Et puis j'ai l'impression que la note du journal a fait des hauts et des bas, donc peut-être qu'il n'a pas été si inutile que ça et que certains qui avaient raté le précédent, assez éloigné, ont appris la nouvelle maintenant :)
Bref, ça s'offusque un peu vite pour pas grand chose parfois par ici, un peu d'optimisme ! ;)
[^] # Re: Bonjour
Posté par freem . Évalué à 10.
Faut bien trouver une excuse pour utiliser les 100 avis quotidiens :)
[^] # Re: Bonjour
Posté par gUI (Mastodon) . Évalué à 7.
Mettre un journal "inutile" c'est pas non plus balancer un mec à la rivière.
Personnellement je trouve objectif de dire que son journal est inutile. Donc je "moinsse", c'est tout. Après j'ai rien contre lui, c'est sûrement un gentil garçon :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Bonjour
Posté par freem . Évalué à 10.
Probablement pas, vu le genre employé dans l'écrit :D
# En parlant de lire ...
Posté par GnunuX (site web personnel) . Évalué à 10.
Lisons donc l'article …
Bien bien bien …
[^] # Re: En parlant de lire ...
Posté par dyno partouzeur du centre . Évalué à 8.
Et puis ne pas rater le paragraphe "Why did OpenBSD silently release a patch before the embargo?" où on explique qu'OpenBSD est un mauvais citoyen qui refuse de respecter l'embargo collectif et qui publie le patch trop tôt, mettant en péril tous les utilisateurs d'autres systèmes en révélant l'existance de la faille.
Du coup OpenBSD ne fera plus partie de la liste restreint de disclosure et ne seront informés qu'une fois que tout le monde aura un patch, au risque de ne pas être prêt à temps quand la faille sera publique. Bien joué les gars !
[^] # Re: En parlant de lire ...
Posté par Christophe . Évalué à 2.
En effet, mais on peut comprendre leur frustration: finalement, les mises à jour de binaires pourront se faire au plus tôt chez tous les OS privateurs. Et alors que les OS libres ont souvent un délai de réaction rapide, ils doivent attendre le dernier jour pour effectivement protéger leurs utilisateurs.
Notons quand même qu'ils ont publié la correction avec l'accord de la personne à l'origine de l'embargo.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à -1.
On fait doublon avec le précédent journal, mais pour reciter le développeur OpenBSD chargé du truc : d'un, ils avaient l'accord, de deux, ils n'ont pas besoin de trois ou quatre mois pour préparer un patch, 2h en l'occurrence pour adapter le patch fourni, donc c'est pas comme si ça va changer grand chose, et de trois, attendre presque deux mois après que CERT et donc les agences gouvernementales soient au courant, ça montre un peu les limites de ce genre d'embargo à rallonge : de quoi laisser largement le temps à ceux qui voudraient en profiter parmi les nombreux acteurs au courant. Trois mois (ou plus pour certains en fait), c'est pour les gros vendeurs, en particulier les négligents et paresseux, et pour assurer la médiatisation, ça n'a pas grand chose à voir avec la sécurité.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . Évalué à 10.
Certes, mais apparemment ils ont pas mal insisté pour l'obtenir.
Et comme OpenBSD semble contre le processus des embargo, les gens ne leur font plus assez confiance pour l'avenir d'où cette décision.
Un embargo n'a de sens que si les acteurs travaillent conjointement et sont d'accord avec ces règles.
Bah si, si OpenBSD délivre un correctif en lien avec la sécurité, des gens vont l'analyser si cela n'impacte pas d'autres systèmes et donc générer des attaques contre les dits systèmes qui n'ont pas encore corrigé la faille.
Oui, le méchant gouvernement est au courant donc ils vont profiter de l'embargo pour attaquer tous azimuts.
Déjà, la faille est surfaite, elle n'est pas si critique que présentée. En réalité si tu as un chiffrement applicatif, ce qui est de plus en plus le cas (HTTPS, chiffrement SMTP/IMAP, VPN, etc.) ces flux ne sont pas concernés. Et les actions possibles restent malgré tout assez limitée. Donc l'urgence selon moi n'était pas non plus de mise.
C'est vraiment naïf je pense de présenter cela ainsi.
Je ne dis pas que les 4 mois sont nécessaires, je n'en sais rien, mais cela ne demande pas deux jours non plus.
Car bon, le développeur OpenBSD qui fait son correctif à l'arrache en 4h n'a pas les mêmes contraintes (ni la même qualité de service) qu'une entreprise comme Microsoft, Samsung ou Apple. Ces entreprises ont souvent beaucoup de versions de leur logiciel à maintenir. Entre les différents Windows (3 sont encore maintenus), macOS, iOS, et pour Samsung c'est plusieurs versions d'Android et de Tizen à toucher pour des dizaines de périphériques (avec leur propre version du système).
Bref, les entreprises commerciales ont une certaine inertie pour ce genre de correctifs mais c'est justifié. Ils doivent reproduire le soucis, trouver le correctif adéquat, le tester sur tous les appareils concernés (quand tu as une vraie QA, cette étape prend du temps). Car bien entendu, on doit être sûr que la MaJ ne casse rien pour personne car ma grand mère ne va pas déboguer et faire un rapport de bogue pour sa machine auprès de ses entreprises (ce que l'utilisateur d'OpenBSD moyen saurait faire). Ensuite il faut générer la mise à jour et en faire la diffusion (et étant donné leur infra, cela ne se fait pas en une minute). Sans compter que comme les MaJ ça coûte à en faire, ils vont probablement intégrer ce changement avec d'autres qui étaient prévus. Ce qui ralenti le processus.
Donc bon, non ils ne sont pas fainéants, paresseux ou incompétents. Mais assurer une qualité de service pour des millions / milliards de produits diffusés dans le monde, utilisés par des non informaticiens, cela ne s'improvise pas. Même un changement banal nécessite de gros efforts pour éviter des problèmes. Du coup ils ne peuvent pas se permettre de faire comme OpenBSD ou Debian de faire un correctif rapidement et de le diffuser dans la foulée ou presque.
C'est difficile de concilier toutes ces contraintes à la fois.
[^] # Re: En parlant de lire ...
Posté par Psychofox (Mastodon) . Évalué à 0.
Le problème ce n'est pas les gouvernements, c'est qu'en 4 mois vu le nombre d'acteur t'es certain que la faille a fuité, et que l'information est forcément arrivé chez des gens qui ont envie de l'utiliser à mauvais escient.
Du reste cette faille a une solution de contournement très simple et facile : ne pas utiliser le wifi.
Reproduire le souçis, trouve le correctif adéquoit. Ce sont des étapes qui ne prennent pas plus de temps à GROSSEMEGACORPORATION qu'à un dev openbsd ou wpa_suppliquant.
Il n'y a que la partie test et contrôle qualité qui prend un temps supplémentaire.
Et après je serais tenté de dire qu'il faut se donner les moyens de ses ambitions. Si tu affirmes pouvoir supporter et assurer la sécurité de x milliers/millions/millards de devices différents , tu dois aussi faire les investissements nécessaire pour assurer un contrôle qualité dans un temps raisonnable pour une faille jugée critique. Sinon tu ne vends que du mensonge. Parce que non un embargo long ça n'assure pas la sécurité.
Et j'ajouterai que dans certains cas la correction de failles jugées importantes doit pouvoir primer sur le fait que x milliers de devices pourraient éventuellemnent être briqués si MEGACORPORATIONTARTANPION n'a pas trouvé moyen d'en assurer un contrôle qualité en un temps raisonnable (et à charge du fournisseur d'en assurer la réparation ou le remplacement). C'est un peu comme quand dans des traitements médicamenteux pour soigner des maladies potentiellement mortelles. Tu sais qu'il va y avoir des effets secondaires indésirables mais la finalité de la guérison du plus grand mal prime sur le bon fonctionnement, momentané ou pas, de certains organes. Un ordinateur/smartphone, ça se sauvegarde et peut se remplacer, on le fait tout le temps quand ils tombent en panne où qu'on les casse. Un vol d'identité c'est potentiellement bien plus emmerdant par exemple.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . Évalué à 7.
Mouais, il ne doit pas y avoir beaucoup de gens impliqués dans ce genre de procédures, et malgré tout 4 mois c'est court pour exploiter une faille qui a finalement pas un si grand impact que cela.
Ou chiffrer de manière applicative les communications (car de toute façon, si tout est en clair en filaire ce n'est pas terrible non plus).
Et grâce aux efforts de tout le monde sur cette question, c'est de plus en plus le cas.
Bah figure toi que si.
Microsoft, Apple et Samsung gèrent des dizaines de produits logiciels et matériels en simultanées. Donc il faut vérifier qui est concerné, comment, établir le correctif pour chacun.
Puis étant donné que ce sont de grosses structures, je suppose que l'employé qui a accès aux données des embargo n'a pas accès à tous les dépôts de la boîte et n'est pas expert en tout. Donc il va falloir probablement contacter du monde, prévenir la hiérarchie aussi pour savoir la marche à suivre, le calendrier des opérations. Il va falloir synchroniser les MaJ des différents produits ce qui demande du travail de planification.
Je suppose aussi que les employés sécurité chez eux ne se contentent pas de juste corriger le bogue pour faire le correctif. Très probable qu'ils analysent si ce genre de failles ne peut pas se retrouver ailleurs. Ou s'il n'y a pas une faille cachée proche de cette faille dans la gestion du Wifi.
Quand tu ne gère qu'un OS, utilisé par des débrouillards en informatique sans structure hiérarchique ou équipes de développement, tu peux aller plus vite à tous les étapes. Ce n'est pas pour autant une bonne chose.
1-Cette faille n'est pas si critique que cela, franchement des failles révélées en grande pompe ces dernières années, c'est sans doute la moins inquiétante que j'ai vu.
2-Ce n'est pas qu'une question de budget et du nombre d'employés, tu as des délais incompressibles pour bien faire les choses. Tu sais remplir complètement un cahier de tests, et réaliser ces tests, ça demande pas mal de temps (pour l'avoir fait une fois)… Et étant donnés la diversité du matériel et des logiciels impliqués, ça en fait du boulot pour tout valider.
Il faut je pense arrêter que sous prétexte de la sécurité tout doit être corrigé dans la seconde. C'est le meilleur moyen de se louper quelque part. Ils me semblent avoir vu que le noyau Linux en voulant corrigé une faille, une autre a été introduite par mégarde. C'est con non ?
Oui bien sûr, tu achètes un produit 1000€ (cas de certains téléphones je le rappelle) pour qu'il tombe en rade suite à une MaJ ? Bonjour l'image de marque et la satisfaction de l'utilisateur !
Ouais, faut encore démontrer que cette faille dans la vraie vie permette de faire ça facilement. De ce que j'en ai compris, ce n'est pas si évident que cela, surtout si tu chiffres tes communications au dessus du WPA2 (et j'espère que les gens ne transmettent pas en clair des données sensibles du genre, Wifi ou non, WPA2 ou pas).
[^] # Re: En parlant de lire ...
Posté par Psychofox (Mastodon) . Évalué à -1.
Faudrait arrêter de faire passer le truc comme s'il y'avait une personne unique dans chacune de ces boites qui allait devoir se palucher tous les repos de sources de sa boite.
Ben non pour chaque produit il y'a un product owner, avec une équipe derrière.
Et oh magie ils ont plus qu'une place de travail et peuvent travailler à plusieurs en même temps !
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . Évalué à 7.
Oui, et ?
Malgré tout tout ce beau monde doit communiquer, se synchroniser, faire ses tests, peut être introduire d'autres changements avec, etc. C'est beaucoup de temps de faire ça.
Et vu la non-criticité de cette faille (car bon, honnêtement, tu dois avoir des failles bien plus importantes corrigées dans les mises à jour habituelles de ton OS et navigateur), je peux comprendre que cela ne justifie pas de se précipiter.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 4.
Cet argument, que tu répètes plus d'une fois, n'est pas convainquant, car utilisable dans le sens contraire : vu que c'est pas critique, c'est pas grave si les plus lents patchent un peu en retard.
[^] # Re: En parlant de lire ...
Posté par claudex . Évalué à 4.
Et c'est justement ce qui a été fait. Mais vu qu'ils ont montrés qu'ils n'étaient pas capable de tenir un embargo pour une faille non critique, il y a peu de chance qu'ils y arrivent pour un truc vraiment grave.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 5. Dernière modification le 01 novembre 2017 à 10:18.
Je trouve assez curieux cet acharnement pour défendre la longueur de l'embargo et interdire à OpenBSD de se plaindre : parce que c'est la seule chose qu'ils ont fait sans accord, se plaindre sur la longueur, l'erreur de donner l'accord (Edit: qui est une erreur, et une illustration des risques de faiblesse avec les embargos) ne leur appartient tout simplement pas ; ou alors se plaindre, c'est être coupable aujourd'hui :) D'ailleurs, ce post de tedu pour Heartbleed montre bien leur position que, même s'ils n'aiment pas, ils respectent les embargos si ce n'est pas leur bug et qu'ils n'ont pas la permission.
Et ce n'est pas comme si du côté de Linux ça aime plus les embargos, je dirais même que Linus Torvalds est bien plus extrême en la matière, si ça ne tenait qu'à lui il n'y aurait même pas d'embargo court, et les embargos pour Linux, arrivés malgré Linus, ont actuellement une limite très faible (entre 14 et 19 jours max, avec préférence pour moins de 7 jours, d'après un lwn d'il y a quelques années).
[^] # Re: En parlant de lire ...
Posté par claudex . Évalué à 4.
Personnellement, je trouve que c'est un embargo un peu long. Mais, vu qu'on parle d'une faille qui est là depuis 10 ans, et qui, dans le contexte actuel n'est pas si critique que ça, on n'est pas à 2 mois près. Surtout si on critique la longueur car ça permet à la NSA de l'exploiter, il y a des chances que ça fasse longtemps qu'ils étaient au courant.
Sauf qu'il est possible que les auteurs aient donner leur accord de peur qu'OpenBSD publie le patch avec les explications de la faille, ce qui aurait été pire question embargo.
Ce n'est pas vraiment comparable, OpenBSD, c'est un OS complet. Pas juste un noyau. Les failles qui impactent plusieurs noyaux différents, il ne doit pas y en avoir des masses (à part Stack Clash, je n'ai pas d'exemple récent en tête et l'embargo a été de plus d'un mois, alors qu'il y avait moins de monde concerné). Par contre, du côté OS, il y a beaucoup plus de code ou de protocole commun, et donc plus de chance d'avoir des failles avec beaucoup d'acteurs impliqués.
Donc, si on prends une grosse faille comme DirtyCow, on n'est dans un cas avec une poignée d'acteurs (les dev kernel et quelques distributions majeures ayant accès à ces embargo) qui bossent plus ou moins sur la même base de code. C'est donc normal que ça aille beaucoup plus vite. Par exemple, l'embargo sur oss-sec est de 14 à 19 jours normalement.
Cela dit, il est bien possible que le comportement de Linus n'aide pas le kernel à être inclus dans ces embargo multi OS. Et il est bien possible que si ça s'était présenté avec Linux dans la boucle, les même critiques se seraient tourner sur Linus. Et d'ailleurs, j'ai l'impression que les gens se tournent vers les équipes de sécurités des distributions plutôt que vers l'équipe du kernel directement quand il s'agit de parler de faille.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 4. Dernière modification le 01 novembre 2017 à 11:57.
C'est plus une illustration de ce que la peur dans le secret peut conduire à faire comme extrapolations et erreurs humaines, qu'un argument pour faire culpabiliser OpenBSD, qui de mon point de vue, a juste permis de mettre en lumière dans le cas d'une faille non critique qu'il ne faut pas grand chose (juste se plaindre par mail) pour parfois réussir à faire faire des bêtises au propre initiateur de l'embargo, erreur qu'il reconnaît lui-même et qui montre que le secret dans ce genre d'embargos ne tient qu'à un fil et, entre-temps, tout le monde est dans le doute dans une atmosphère de méfiance, se demandant si une bêtise similaire ou fuite a déjà été commise ou non.
[^] # Re: En parlant de lire ...
Posté par flagos . Évalué à 6.
Oui enfin bon, beaucoup de nous travaillent dans une boite, on sait qu'en pratique, le souci n'est pas vraiment la.
Le souci, c'est que les priorités sont tries par des PO qui s'en tamponnent de ce genre de bugs. Eux, ils veulent la derniere feature qui va leur permettre de faire une demo 'amazing' ou rajouter un super bouton qui, pour sur, va sauver la boite.
Alors ton bug super critique la, tu es bien gentil, mais il peut bien pourrir dans le backlog et personne ne va travailler dessus. On s'en inquiétera lorsque les clients s'en inquiéteront.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 0.
Ma phrase est probablement ambigüe, je voulais dire que ça va pas changer grand chose pour OpenBSD d'être prévenu deux jours avant, ou d'être prévenu trois mois à l'avance et de devoir attendre (le commentaire laissait sous-entendre qu'OpenBSD aller pâtir significativement du fait d'être prévenu plus tard).
Je suis bien d'accord :)
J'ai dit « en particulier pour les paresseux », je conçois bien que pour certains, c'est honnêtement compliqué. Toujours est-il, qu'il y a un part de jugement éthique subjectif sur la chose et qu'il est difficile d'être tous d'accord. Pour toi, rallonger significativement l'embargo si ça peut être utile aux gros systèmes non libres (donc à beaucoup plus de monde) justifie un avantage par rapport à une minorité (les systèmes libres, qui doivent attendre la publication avant de patcher, ainsi que les acteurs plus méconnus qui ne seront même pas prévenus), plutôt que de donner le même temps (idéalement le même, ou embargo court à défaut) de réaction pour tous, quitte à que ce soit moins bien pour la majorité. C'est une position qui se défend et que je comprends, mais que je ne réussis pas à partager, je penche plus du côté des minorités.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . Évalué à 7.
Il reste à démontrer si dans les entreprises prévenues, il y avait des paresseux. Je pense que non, mais c'est à toi de démontrer qu'ils le sont.
Non, il y a des critères objectifs.
Tu as d'un côté de grandes entreprises avec une inertie forte car ils ont énormément de clients et de produits et de l'autre des petites communautés qui réagissent plus vite.
Il y a des critères non subjectifs pour favoriser, avec l'embargo, les entreprises du premier cas :
Je ne vois aucun avantage objectif à ce que les petits projets type OpenBSD soit privilégié dans ce dossier.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 0.
Ça c'était la partie légèrement trollesque d'un commentaire écrit un peu vite (pas vraiment voulu, et plus sorti d'un sentiment qu'autre chose, mais ça a eu son effet ^^).
Il y a deux faits objectifs. D'un côté plus de produits, plus d'utilisateurs (tes critères). D'un autre, des minorités libres ou non prévenues qui ont tout à perdre avec un embargo long accompagné de possibles fuites (mes critères). Il est à noter que si toutes les minorités sont prévenues, la fuite est assurée, donc le procédé est intrinsèquement impossible à rendre équitable.
Après, il y a l'argument subjectif : le mieux pour la majorité (tes critères) prime sur l'équité (mon critère). En tous cas, perso, je vois pas comment tu peux dire qu'il n'y a aucune part de subjectivité à ce raisonnement.
[^] # Re: En parlant de lire ...
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 30 octobre 2017 à 14:56.
Ben voila, c'est bien le soucis, avec tes critères, que ce soit impossible.
Si on parlait du possible?
Et dans le possible, les faits sont que les gens ne respectant l'embargo sont capables de le faire… Qu'une fois.
Objectivement, des fois on peut aussi se dire que ses critères sont peut-être à changer plutôt que de dire que ses critères ont une quelconque utilité (surtotu quand ses critères sont par définition impossibles)
Disons qu'en effet si on décide qu'une minorité de gens a le droit à la sécurité, ça devient subjectif.
Perso je pensais qu'il était assez admis dans ce domaine qu'il vaut mieux que le plus de monde soit protégé, du coup effectivement si on n'a pas ça ça devient subjectif, mais la il faut alors d'abord se demander qui on doit protéger le plus (99% de la population ou 1%), c'est un autre débat que celui du journal (mais pas sûr que tu trouves beaucoup d'amis à vouloir laisser 99% des gens sur le carreau).
Ont-elles plus à gagner à ne pas suivre les embargos et à s'exclure des infos? C'est toute la question, que tu évites. Quand on fait des choix, il faut les assumer, y compris les conséquences.
Comme tu as l'air de t'en foutre des autres sous excuse d'équité, je dirai que le mieux à faire, si j'étais celui qui décide, pour les 99% est de ne pas te prévenir, et puis on n'en parle plus. Si toi minorité ne souhaite pas prendre en compte les problèmes de la majorité, pourquoi la majorité t’inclurai dans leur gestion? Tout à perdre, absolument rien à y gagner, c'était par souhait de ne pas foutre la merde dans ta minorité qu'elle t'a contacté, mais si tu leur craches à la gueule ben…
PS : j'ai réagi en prenant comme supposition que ton critère est celui que tu décris, mais en fait j'ai de gros doutes que ce que tu dis ai un lien quelconque avec l'équité… Faudrait encore démontrer ça.
PPS :
Avec des amis comme ça, on n'a pas besoin d'ennemi. Demande-toi si ces minorités apprécient les conséquences factuelles de tes idées/critères.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 1.
Je pense qu'on est plutôt d'accord, donc :)
Ceci dit, je me pose la question si ton 99% est vraiment un 99%. Que je sache, c'est pas exactement toutes les entreprises et agences gouvernementales de tous les pays du monde qui sont prévenues non plus. Suivant le type de faille ça sera plus ou moins pertinent, mais ça n'a pas l'air si évident comme estimation.
[^] # Re: En parlant de lire ...
Posté par Zenitram (site web personnel) . Évalué à 3.
Il y a plein de problèmes avec les longs embargos (par exemple en plus des risques de fuite, ça laisse 90 jours à la NSA au courant d'en profiter pour pirater, ils ont une longue expérience en la matière) et on ne peut allonger la liste des gens prévenus à l'infini, mais pour commencer à débattre de ces points (qui, combien de temps), il faut déjà flinguer les problèmes sur les principes (par exemple exclure les personnes disant explicitement qu'elles ne respecteront pas les décisions communes, et surtout ne pas nous personnes de l'extérieur juger ça défendable, pour citer une personne ;-) "je penche plus du côté des minorités" est plutôt à éviter, car minorité ou pas ce n'est pas le sujet, le sujet est la vie en communauté).
Bref, je trouve non constructif de revenir à chaque fois à la base à reprendre les trucs genre "oui quelques mois c'est trop long", car ça ne change pas le problème (qu'il y en a besoin pour certains).
tu parles de délai, mais comme pour la Catalogne (ben oui, on retrouve les principes partout), je penche plus pour convaincre à long terme bien plus de la moitié des gens avant d'aller de l'avant avec des règles claires décidées ensemble, car sinon c'est juste le bordel (et si on décide seul des règles alors qu'on est 1%, c'est juste une blague).
Un délai de 60 jours? Pourquoi pas, si plein de monde est d'accord pour… Juste pas tout seul "parce que nous on sait faire avec nos 1%".
99% était pour discuter par rapport à 1%, je doute aussi que ce soit le cas, rien que parce qu'il y a plein de gens qui ne mettent pas à jour (j'ai toujours quelque % de visiteurs sous WinXP… Gloups) même sans compter sur les constructeurs avec des machines de moins de quelques années.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 1.
Je pense effectivement que c'est le mieux en cas d'embargo long : ça évite à la personne d'avoir à attendre de façon d'incompatible avec son éthique (ne pas savoir est une solution parfois). Après, en l'occurrence, c'est un embargo rallongé, donc c'est plus difficile à prévoir, j'imagine.
En effet, c'est pourquoi je pense que la solution de prévenir OpenBSD plus tard est plus en accord avec l'éthique des deux parties, plutôt que celle de prévenir trop tôt, rallonger l'embargo, puis conflit prévisible étant donné la position du projet sur ces choses. Je ne sais pas exactement comment marchent ces diffusions de failles, mais la possibilité de demander à ne pas être prévenu trop tôt aurait du sens à mon avis.
Et je suis assez de ton avis que, pour la Catalogne, c'est juste le bordel, mais on est un peu dans la méthaphore HS, quand même :)
[^] # Re: En parlant de lire ...
Posté par Zenitram (site web personnel) . Évalué à 5.
accord mis à part (c'est un autre sujet de débat, plus complexe), et on fait doublon avec le précédent journal, mais il va falloir un jour expliquer bien posément, avec des arguments prenant en compte le fait que certains déploient sur 1 milliard de machines dont des machines qui ne doivent pas avoir de régressions, comment tu déploies sur 1 milliard de machines en 2 heures sans aucun risque.
Parce que la, ça ressemble quand même vachement à des piliers de bar "il n'y a qu'à, regarde moi chez moi ça marche" qu'à une explication sérieuse.
En attendant, si j'ai bien suivi BSD aura l'info après les autres, je ne vois alors pas en quoi ça va changer la sécurité de BSD par rapport à avoir l'info 2 mois à l'avance sans droit de patcher (oui, des fois il faut s'adapter au plus lent, c'est le deal de la vie en commun pour avoir les rapports de problème en avance, et vaut mieux ne pas être seul ou ne pas être petit si on veut "casser les règles", déjà que ça clashe sur 90 jours entre Google qui ne veut pas dépasser ce nombre et Microsoft qui voudrait dépasser ce nombre…).
[^] # Re: En parlant de lire ...
Posté par Psychofox (Mastodon) . Évalué à 0.
Échelles de valeurs, toussa. OpenBSD n'a pas patché immédiatement non plus. Entre 2h et 4 mois il y'a bien moyen de trouver un juste milieu non ?
[^] # Re: En parlant de lire ...
Posté par Zenitram (site web personnel) . Évalué à 4.
D'une, je t'ai déjà mis une limite dans mon texte, qui semble (ce n'est pas moi qui le dit, mais une entité qui gère 1 milliard de machines voire plus) être à 90 jours comme acceptable par pas mal de monde (dont des gros).
De deux, en fait c'est qu'un détail, perso quand on vient me voir et me parler d'une faille, la dernière chose que je ferai et de tanner la personne pour releaser quand moi je veux : même si ça ne me plait pas, le minimum pour avoir la confiance est de respecter la personne qui vient te filer le problème, et si cette personne dit au dernier moment qu'il faut décaler le patch, ben on ne lui met pas de pression (du moins tant qu'on n'a pas eu l'info par un autre canal qui montrerait que le problème est exploité).
Faire au plus vite quand on reçoit un problème est un choix, qu'ils le fassent, mais après il ne faut alors pas s'étonner que les autres, qui respectent les décisions, aient l'info plus tôt.
Tout est dans la confiance que tu vas respecter les autres.
[^] # Re: En parlant de lire ...
Posté par anaseto (site web personnel) . Évalué à 3.
En 2h, tu ne peux pas. Mettons que tu aies vraiment besoin de trois mois : dans tous les cas, c'est le choix de l'équité ou de favoriser la majorité par rapport aux minorités, comme je dis plus haut, donc on va forcément pas tous être d'accord, puisqu'il est question d'éthique et pas que de technique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.