Le seul truc auquel je pense c'est la double authentification. Je trouve que c'est très adapté à plein de situations qui concernent à peu près tout le monde.
Pour remplacer les anciens token smartcard/SIM/USB avec PIN code ? Ça oblige en plus à avoir un téléphone et faire de l'entrée manuelle, mais les deux facteurs sont la dans les deux cas.
D'autres exemples de technos modernes de sécurité ?
Pour le cas de systemd-homed, avoir un home encryptée avec une clé séparée de celle de la machine… je m'en fous. Voire je m'en fous de chiffrer tout court.
Je pense aussi à l'authentification forcée d'application sur des systèmes liés à des magasins, ou mécanismes similaires (j'ai fait une conf sur Firefox OS à l'époque où il vivait encore où Mozilla se targuait de faire du libre et de protéger les utilisateurs en n'autorisant que ses apps validées, sans contournement possible bien sûr). C'est anti-liberté.
Ou encore la manie de passer par des gestionnaires de mot de passe, voire en ligne (qui finissent troués), alors qu'à une époque on se profilait à l'utilisation bien meilleure de clé. La gestion était pour des cas d'utilisations différents d'aujourd'hui où Google avec son WebAuth imagine une grande menace de la part des fournisseurs (mais pas lui-même, bien sûr) alors que c'était l'inverse à l'époque de PKCS. Où ils foutent de la biométrie obligatoire alors que c'est éthiquement répréhensible (pour moi).
Il y a aussi les solutions de sandbox (de syscall, ou autre), qui servent à des utilisateurs qui font tourner n'importe quoi sur leur machines en mode YOLO. Je n'utilise que des logiciels libres, de confiance.
Tout ce qui est secure boot, qui essaye de résoudre un problème insoluble : un soft ne pourra jamais être sûr de ce sur quoi il tourne, il pourra toujours être manipulé.
Beaucoup de solutions de firewall (bon, j'y vais peut-être un peu dur, là), qui pour mon cas d'utilisateur de logiciels maîtrisés et modifiables n'a aucun intérêt. Un firewall c'est pour des softs que tu ne maîtrise pas, où des machines que tu ne maîtrise pas.
La plupart des solutions de CDN ou de « protection » de sites contre les DDoS, qui sont des rackets de protection : je fais du petit et décentralisé, j'ai jamais d'emmerdes (oui, j'ai bien dit que c'était pour mes cas, et ça n'ira bien sûr pas à d'autres).
Mettre sur TLS partout : plutôt de se dire qu'on va protéger ses données parce qu'on passe tout le temps aux US et qu'on ne veut pas être espionné par la NSA, on devrait plutôt chercher à faire du local, court, voire sans accès à Internet pour plein de choses qui n'en ont pas besoin. Ça n'est pas forcément mal dans certains cas, mais la manière dont est réfléchi le modèle du « tout est observé par les US » oblige à un modèle de menace délirant, qui occulte plein d'autres problématiques.
que quand ça revient à la normale tu puisses avoir tes loisirs habituels avec ton niveau de vie habituel plutôt que de devoir tout reconstruire.
Mais quand est-ce que ça reviendra à la normale ? C'est ça (je pense) qui fait peur à ceux qui crient à l'esclavage. Avec le ralentissement de la propagation par le confinement, afin de s'adapter au « rythme » de la disponibilité des hôpitaux, il faudra facile une année voire plus avant d'arriver à avoir une immunité de groupe (je sais pu comment ça s'appelle) ou un vaccin (qu'on paiera la peau des fesses) ou autre chose. C'est quoi le plan du gouvernement à long terme avant de proposer ces mesures ?
J'ai l'impression que le mois reconductible a été un compromis trouvé pour ne pas dire « pendant très longtemps », mais aussi longtemps c'est intenable, je ne comprends pas quel est leur plan. D'où les inquiétudes.
Ho, t'aurais pas du me lancer là-dessus : donc maintenant on a systemd dans l'initrd (!), une réinvention des user/group Unix avec un langage de définition tout nouveau et du contenu en JSON, l'intégration future de ce dernier bidule à sssd et LDAP, les homes dont on parlait, et du multi-instance pour le gestionnaire afin de palier à ses perf merdiques (que j'ai déjà constaté pour de vrai). Bon, je n'ai extrait que les trucs qui me déplaisent, il n'y a pas que ça, mais c'est un beau florilège je trouve.
En fait, il y a tout un paquet de modalités spécifiques à systemd qui dupliquent ce qui existait déjà avant. Faudrait que je fasse un jour un journal sur la philosophie « avec le moins de modalité possible » adoptée par Unix et Internet (l'IETF) : j'ai l'impression que ça n'est vraiment pas compris par beaucoup de monde. (il y a des critiques légitimes à ce modèle, mais je le trouve quand même vastement supérieur à ce machin de systemd)
La spécificité d'HTTP, c'est de s'être largement fossilisé sur les couches basses, et de n'avoir pas su évoluer alors que le courrier électronique s'est adapté aux services multiples avec les enregistrements MX, et plein d'autres protocoles avec des enregistrements SRV.
D'ailleurs je jetais un œil régulièrement au bug proposant l'amélioration de Firefox en lui ajoutant le support des SRV, et il a été fermé l'année dernière (WONTFIX), après vingt ans d'existence ! https://bugzilla.mozilla.org/show_bug.cgi?id=14328
La justification, après avoir eu moult débats et propositions de patchs jamais intégrés ? « Il n'y a pas de use-case utilisateur en vue, en particulier au vu de la migration vers les web-extension » : bref, le passage à la guillotine des web-extension pour justifier n'importe quoi. Le web vraiment décentralisé n'aura pas lieu.
Faut arrêter avec la sécurité à tout crin : la plupart des technos à la con (selon moi) modernes qui ont « innové » niveau sécurité sont pour des modèles de menaces qui ne me concernent absolument pas. Tu te pignoles peut-être sur l'evil maid, mais je pense que c'est parce que les mecs qui ont développé tous ces trucs ont des melons énormes et kiffent s'imaginer en rebel recherché par la CIA. Ça n'est pas mon cas, désolé.
Les téléphones portables ont toutes les fonctionnalités nécessaires pour qu'ils ne dérangent pas. De la même façon qu'on ne peut pas te contraindre à exécuter les JS de Taboola dans ton navigateur, le téléphone portable est ton outil.
L'important n'est pas ce qu'on peut faire (tout ordinateur est une machine généraliste qui peut tout faire), mais ce que font les gens en général : les réglages par défaut. Et j'observe que la majorité des gens transportent le dérangement en permanences, et s'attendent à ce que tout le monde fasse pareil, comme dit Tanguy (pareil pour Taboola). Bref, argument fallacieux.
Perso j'utilise toujours une souris à boule de 1996, et je lui fais un petit nettoyage tous les mois ou deux mois environ, ça suffit : c'est pas la mort. Elle a eu droit à de nouveaux contacteurs (boutons), par contre.
Oui, moi aussi. Pôle-Emploi incite fortement à aller sur LinkedIn, mais sur ce réseau je suis traité de robot et ne peut y accéder… bientôt l'exclusion sera sévère.
il ne devrait pas y avoir d'analyse comportementale sur la page d'informations.
Je sais pas si t'es au courant, mais les dernières start-up à la mode pour le paiement en ligne sont justement celles qui ne nécessitent rien d'autre qu'une analyse de comportement pour valider le paiement ! Je n'ai pas de lien sous la main, mais de mémoire Google y travaille également. Plus besoin de login ou de mdp, juste du JS partout pour t'analyser et t'identifier sans que tu ne t'en rendes compte ! Elle est pas belle la vie ?
Effectivement, c'est très important comme différence. Il y a quelques jours, j'ai vu Jancovici qui disait que quels que soient les moyens qu'on mette (ou pas) pour contrer le changement climatique, les températures des 20 prochaines années sont déjà déterminées à l'avance à cause de l'inertie de tous les systèmes de la Terre. Donc il faut en plus avoir des gens prêts à sacrifier beaucoup, sur une durée longue, sans même pouvoir observer de résultat positif à échéance « normale » (quasiment une génération sans voir de résultat, c'est énorme). Et encore, ça sera tout juste le début d'un vague changement de tendance.
La batterie n'est pas « amovible » au sens classique, mais se remplace si tu sais enlever quelques vis. Pour les deux disques, il y a potentiellement deux M.2, mais le second est un court donc ça va être galère. Et par contre, Windows obligatoire…
Un doute m'est venu juste après avoir posté ce commentaire : existerait-il un module gitlab à weboob, afin de boucler la boucle ? Apparemment non. Ça aurait été méta-drôle, même si j'aurais plutôt ri méta-jaune.
J'arrive après la bataille, mais je voulais lancer un petit troll relatif au cœur du projet : on ma demandé de relancer un patch que j'avais proposé sur la ML (assez morte, par ailleurs) par le gitlab de weboob, sur https://git.weboob.org/
Et là je me suis dit « Comment ? Les devs de weboob osent demander de passer par le web afin de contribuer à ”web out of browser” ? ». Du coup ça m'a fait une excuse pourrie pour ne pas rebaser le patch et reporter le boulot à plus tard /o\
Intéressant comme méthode, mais ta création de partition en masse m'a tout de suite fait penser à plutôt utiliser le device mapper, cf man dmsetup(8).
Tu laisses ton disque non-partitionné, et tu crées un fichier qui contient la « table » des morceaux de disque que tu veux agréger dans un nouveau device, selon la syntaxe indiquée dans le manuel :
0 900000 linear /dev/sda 4100000
0 900000 linear /dev/sda 5100000
…
Ensuite tu crées le device :
dmsetup create disque_aggrege --table ma_table.txt Sache que le Device Mapper est le mécanisme « bas-niveau » utilisé par lvm et dmraid (entre autres), c'est donc du « classique » mais que tu fais ici à la mano ! Par contre j'ai un petit doute sur l'imbrication de device (vu que tu va créer des mapping avec LVM sur ce device qui est déjà un aggrégat de mapping linéaire), mais je pense que ça passe normalement.
Si tu veux voir comment ça fait avec tes devices LVM actuels, histoire de comprendre :
dmsetup ls
dmsetup table mon_device
Par contre, ton VirtualGL c'est autre chose : c'est utiliser l'accélération du client X11 pour envoyer des frames déjà rendues sur le client au serveur X11. Après, l'argument qu'ils avancent de la non-efficacité de faire de l'OpenGL à distance est peut-être vrai, mais du coup s'applique (de ce que je comprends) également à waypipe avec accélération 3D.
Je ne suis pas sûr qu'on se soit bien compris, mais :
Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.
Si tu parles bien d'utiliser sa propre infrastructure qu'on maîtrise pour le triplage de la facture, oui effectivement ça n'est pas un choix facile. On ne peut malheureusement pas tout avoir.
Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.
Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).
Après, une attaque « via des logiciels établis » est toujours possible, mais on commence encore une fois selon moi à entrer dans des probabilités tellement basses que la question du compromis tiens toujours : je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.
Si tu as un master 2 ou un DESS, ta formation est aussi sérieuse et complète que celle d'un ingénieur
Peut-être pour certaines écoles d'ingé, plutôt privées comme tu l'indiques, mais j'ai « comparé » avec des gens que je connais bien issus d'école publiques renommées, et pour moi il y a quand même quelque-chose « en plus » avec celles-ci (INSA en l'occurence). Ou alors c'était ma fac qui n'était pas géniale…
Bon après il y a également l'effet réseau professionnel qui te permet « automatiquement » d'avoir des postes mieux après de bonnes écoles d'ingé, mais ça ça n'est pas très reluisant.
Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.
À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.
Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.
L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.
Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.
Il y a un exploit Meltdown/Spectre qui permet de récupérer l’intégralité de la RAM, en quelques minutes, sans aucun log.
Ça a été montré pour un cas spécifique, mais perso je n'ai pas pu le reproduire, et d'autres personnes me l'ont également confirmé. C'était au début, ça s'est peut-être amélioré depuis, mais on reste sur des méthodes probabilistes qui dépendent d'un alignement de bonnes étoiles (même si oui, ça peut arriver).
Bah vas-y, donne nous tes astuces et bonnes pratiques, on attend que ça.
Ça se fait pas en un commentaire, et je ne suis pas un méga-spécialiste qui pourrait se permettre de lister ça sereinement. Ce que je veux dire, c'est que la publicité faite sur ces failles occulte un tas d'autres choses qui sont plus importantes, c'est tout.
Pas ceux des utilisateurs déjà, puisque l'utilisation des droits est déjà une barrière pour les problèmes humains, qui par définition ne sont pas contrôlable par un admin comme les programmes qui tournent sur sa machine.
Pour les démons, effectivement on met une protection en plus à priori « pas nécessaire » que je trouve déloyal de comparer à cette faille-ci : je pense qu'il y a beaucoup plus de probabilité qu'arrive une RCE qui ne sera pas exploitable pour éscalader les droits que quelqu'un vienne te faire un cacheout sur des secrets spécifiques pour arriver à ses fins. Faire tourner des démons avec des droits distincts, c'est relativement simple, n'a pas d'impact de perf, et te protège de beaucoup de choses. Ici, c'est chiant à mettre en place, pour un gain vraiment très faible. C'est la différence que je fait.
Globalement, avec ce genre de faille, ça veut dire qu'à la moindre RCE, tu bypass les protections du système […] et qui installe un malware dans le bios/uefi
La probabilité que ça arrive est à mon avis assez faible. Mais bon, c'est juste mon avis.
En fait, on ne fait aucune pub pour toutes les bonnes pratiques autres qui sont beaucoup plus logiques et simples à appliquer, et on passe son temps à parler des ces trucs hyper techniques qui ont des probabilité de fonctionner tellement faible que ça en est ridicule. Ça fait parler de Intel, et du bad buzz c'est quand même du buzz, et on donne une attention complètement disproportionnée à ce genre de problème. Ça entraînera forcément une négligence sur d'autres aspects qui auraient pu être beaucoup plus constructifs.
Tu as l'air de dire que tout le monde doit maîtriser à mort son infra.
J'aimerais, mais je sais bien que ça n'est pas possible. Et à ce moment-là, comme le dit kowalsky, tu as bien d'autres problèmes plus prioritaires à te soucier que ces failles.
se connecter sur une de tes machines via un compte non privilégié, il peut utiliser cette faille --> ta super maîtrise est par terre.
Je suis d'accord qu'il faut avoir plusieurs niveaux de protection, mais franchement il y aura à mon avis plus simple que cette faille pour arriver à tes fins dans ce cas-là. On fait tout un foin sur cette histoire, alors que plein de gens font tourner des tas de containers pas à jours avec aucun suivi de CVE. Tu veux essayer de « mitiger » après avec ta super protection anti-Cacheout ? Ton ordre des priorités est vraiment étrange, selon moi.
[^] # Re: Et Poettering ?
Posté par benoar . En réponse au journal Confinement : risque de release de nombreux projets inutiles. Évalué à 1.
Pour remplacer les anciens token smartcard/SIM/USB avec PIN code ? Ça oblige en plus à avoir un téléphone et faire de l'entrée manuelle, mais les deux facteurs sont la dans les deux cas.
Pour le cas de systemd-homed, avoir un home encryptée avec une clé séparée de celle de la machine… je m'en fous. Voire je m'en fous de chiffrer tout court.
Je pense aussi à l'authentification forcée d'application sur des systèmes liés à des magasins, ou mécanismes similaires (j'ai fait une conf sur Firefox OS à l'époque où il vivait encore où Mozilla se targuait de faire du libre et de protéger les utilisateurs en n'autorisant que ses apps validées, sans contournement possible bien sûr). C'est anti-liberté.
Ou encore la manie de passer par des gestionnaires de mot de passe, voire en ligne (qui finissent troués), alors qu'à une époque on se profilait à l'utilisation bien meilleure de clé. La gestion était pour des cas d'utilisations différents d'aujourd'hui où Google avec son WebAuth imagine une grande menace de la part des fournisseurs (mais pas lui-même, bien sûr) alors que c'était l'inverse à l'époque de PKCS. Où ils foutent de la biométrie obligatoire alors que c'est éthiquement répréhensible (pour moi).
Il y a aussi les solutions de sandbox (de syscall, ou autre), qui servent à des utilisateurs qui font tourner n'importe quoi sur leur machines en mode YOLO. Je n'utilise que des logiciels libres, de confiance.
Tout ce qui est secure boot, qui essaye de résoudre un problème insoluble : un soft ne pourra jamais être sûr de ce sur quoi il tourne, il pourra toujours être manipulé.
Beaucoup de solutions de firewall (bon, j'y vais peut-être un peu dur, là), qui pour mon cas d'utilisateur de logiciels maîtrisés et modifiables n'a aucun intérêt. Un firewall c'est pour des softs que tu ne maîtrise pas, où des machines que tu ne maîtrise pas.
La plupart des solutions de CDN ou de « protection » de sites contre les DDoS, qui sont des rackets de protection : je fais du petit et décentralisé, j'ai jamais d'emmerdes (oui, j'ai bien dit que c'était pour mes cas, et ça n'ira bien sûr pas à d'autres).
Mettre sur TLS partout : plutôt de se dire qu'on va protéger ses données parce qu'on passe tout le temps aux US et qu'on ne veut pas être espionné par la NSA, on devrait plutôt chercher à faire du local, court, voire sans accès à Internet pour plein de choses qui n'en ont pas besoin. Ça n'est pas forcément mal dans certains cas, mais la manière dont est réfléchi le modèle du « tout est observé par les US » oblige à un modèle de menace délirant, qui occulte plein d'autres problématiques.
C'est tout ce à quoi je pense pour l'instant.
[^] # Re: surcharge hospitalière
Posté par benoar . En réponse au journal Le retour de l'esclavage. Évalué à 4.
Mais quand est-ce que ça reviendra à la normale ? C'est ça (je pense) qui fait peur à ceux qui crient à l'esclavage. Avec le ralentissement de la propagation par le confinement, afin de s'adapter au « rythme » de la disponibilité des hôpitaux, il faudra facile une année voire plus avant d'arriver à avoir une immunité de groupe (je sais pu comment ça s'appelle) ou un vaccin (qu'on paiera la peau des fesses) ou autre chose. C'est quoi le plan du gouvernement à long terme avant de proposer ces mesures ?
J'ai l'impression que le mois reconductible a été un compromis trouvé pour ne pas dire « pendant très longtemps », mais aussi longtemps c'est intenable, je ne comprends pas quel est leur plan. D'où les inquiétudes.
[^] # Re: Et Poettering ?
Posté par benoar . En réponse au journal Confinement : risque de release de nombreux projets inutiles. Évalué à 1.
Ho, t'aurais pas du me lancer là-dessus : donc maintenant on a systemd dans l'initrd (!), une réinvention des user/group Unix avec un langage de définition tout nouveau et du contenu en JSON, l'intégration future de ce dernier bidule à sssd et LDAP, les homes dont on parlait, et du multi-instance pour le gestionnaire afin de palier à ses perf merdiques (que j'ai déjà constaté pour de vrai). Bon, je n'ai extrait que les trucs qui me déplaisent, il n'y a pas que ça, mais c'est un beau florilège je trouve.
En fait, il y a tout un paquet de modalités spécifiques à systemd qui dupliquent ce qui existait déjà avant. Faudrait que je fasse un jour un journal sur la philosophie « avec le moins de modalité possible » adoptée par Unix et Internet (l'IETF) : j'ai l'impression que ça n'est vraiment pas compris par beaucoup de monde. (il y a des critiques légitimes à ce modèle, mais je le trouve quand même vastement supérieur à ce machin de systemd)
[^] # Re: FFx 75
Posté par benoar . En réponse à la dépêche Pas de confinement pour Firefox 74. Évalué à 4.
D'ailleurs je jetais un œil régulièrement au bug proposant l'amélioration de Firefox en lui ajoutant le support des SRV, et il a été fermé l'année dernière (WONTFIX), après vingt ans d'existence ! https://bugzilla.mozilla.org/show_bug.cgi?id=14328
La justification, après avoir eu moult débats et propositions de patchs jamais intégrés ? « Il n'y a pas de use-case utilisateur en vue, en particulier au vu de la migration vers les web-extension » : bref, le passage à la guillotine des web-extension pour justifier n'importe quoi. Le web vraiment décentralisé n'aura pas lieu.
[^] # Re: Et Poettering ?
Posté par benoar . En réponse au journal Confinement : risque de release de nombreux projets inutiles. Évalué à -4. Dernière modification le 22 mars 2020 à 21:51.
Faut arrêter avec la sécurité à tout crin : la plupart des technos à la con (selon moi) modernes qui ont « innové » niveau sécurité sont pour des modèles de menaces qui ne me concernent absolument pas. Tu te pignoles peut-être sur l'evil maid, mais je pense que c'est parce que les mecs qui ont développé tous ces trucs ont des melons énormes et kiffent s'imaginer en rebel recherché par la CIA. Ça n'est pas mon cas, désolé.
[^] # Re: Et Poettering ?
Posté par benoar . En réponse au journal Confinement : risque de release de nombreux projets inutiles. Évalué à 8.
Putain c'est même pas une blague : https://wiki.archlinux.org/index.php/Systemd-homed
[^] # Re: Pires inventions à mon avis
Posté par benoar . En réponse au journal Mon Top 5 des inventions geeks des 20 dernières années. Évalué à 5.
L'important n'est pas ce qu'on peut faire (tout ordinateur est une machine généraliste qui peut tout faire), mais ce que font les gens en général : les réglages par défaut. Et j'observe que la majorité des gens transportent le dérangement en permanences, et s'attendent à ce que tout le monde fasse pareil, comme dit Tanguy (pareil pour Taboola). Bref, argument fallacieux.
[^] # Re: La souris optique
Posté par benoar . En réponse au journal Mon Top 5 des inventions geeks des 20 dernières années. Évalué à 4.
Perso j'utilise toujours une souris à boule de 1996, et je lui fais un petit nettoyage tous les mois ou deux mois environ, ça suffit : c'est pas la mort. Elle a eu droit à de nouveaux contacteurs (boutons), par contre.
[^] # Re: Quelques explications sont importantes
Posté par benoar . En réponse au journal Les sites de paiement qui demandent la lune. Évalué à 6.
Oui, moi aussi. Pôle-Emploi incite fortement à aller sur LinkedIn, mais sur ce réseau je suis traité de robot et ne peut y accéder… bientôt l'exclusion sera sévère.
[^] # Re: Quelques explications sont importantes
Posté par benoar . En réponse au journal Les sites de paiement qui demandent la lune. Évalué à 9.
Je sais pas si t'es au courant, mais les dernières start-up à la mode pour le paiement en ligne sont justement celles qui ne nécessitent rien d'autre qu'une analyse de comportement pour valider le paiement ! Je n'ai pas de lien sous la main, mais de mémoire Google y travaille également. Plus besoin de login ou de mdp, juste du JS partout pour t'analyser et t'identifier sans que tu ne t'en rendes compte ! Elle est pas belle la vie ?
[^] # Re: ridicule ....
Posté par benoar . En réponse au journal Face à l'urgence climatique, plus de mille scientifiques appellent à la désobéissance civile . Évalué à 3.
Effectivement, c'est très important comme différence. Il y a quelques jours, j'ai vu Jancovici qui disait que quels que soient les moyens qu'on mette (ou pas) pour contrer le changement climatique, les températures des 20 prochaines années sont déjà déterminées à l'avance à cause de l'inertie de tous les systèmes de la Terre. Donc il faut en plus avoir des gens prêts à sacrifier beaucoup, sur une durée longue, sans même pouvoir observer de résultat positif à échéance « normale » (quasiment une génération sans voir de résultat, c'est énorme). Et encore, ça sera tout juste le début d'un vague changement de tendance.
# Thinkpad T495
Posté par benoar . En réponse au message Un ordinateur portable . Évalué à 3.
Un Thinkpad parce qu'il n'y a que ça de vrai, série « T » pour du pro en taille raisonnable (14") (sinon « X » pour du réduit, mais va disparaître), et maintenant ils font de l'AMD donc T495 :
https://www.lenovo.com/fr/fr/laptops/thinkpad/t-series/T495/p/22TP2TTT495
La batterie n'est pas « amovible » au sens classique, mais se remplace si tu sais enlever quelques vis. Pour les deux disques, il y a potentiellement deux M.2, mais le second est un court donc ça va être galère. Et par contre, Windows obligatoire…
[^] # Re: Non
Posté par benoar . En réponse au message réparer le grub en ligne de commande. Évalué à 2. Dernière modification le 24 février 2020 à 23:22.
Vous avez tous les deux raison : je pense que NeoX parle de GPT, et toi d'UEFI :-)
[^] # Re: Troll : obligé d'utiliser un browser pour contribuer à weboob ?
Posté par benoar . En réponse à la dépêche Weboob a dix ans !. Évalué à 4.
Un doute m'est venu juste après avoir posté ce commentaire : existerait-il un module gitlab à weboob, afin de boucler la boucle ? Apparemment non. Ça aurait été méta-drôle, même si j'aurais plutôt ri méta-jaune.
# Troll : obligé d'utiliser un browser pour contribuer à weboob ?
Posté par benoar . En réponse à la dépêche Weboob a dix ans !. Évalué à 6.
J'arrive après la bataille, mais je voulais lancer un petit troll relatif au cœur du projet : on ma demandé de relancer un patch que j'avais proposé sur la ML (assez morte, par ailleurs) par le gitlab de weboob, sur https://git.weboob.org/
Et là je me suis dit « Comment ? Les devs de weboob osent demander de passer par le web afin de contribuer à ”web out of browser” ? ». Du coup ça m'a fait une excuse pourrie pour ne pas rebaser le patch et reporter le boulot à plus tard /o\
# Avec le Device Mapper ?
Posté par benoar . En réponse à la dépêche Sauver un disque dur mécanique. Évalué à 9. Dernière modification le 21 février 2020 à 01:13.
Intéressant comme méthode, mais ta création de partition en masse m'a tout de suite fait penser à plutôt utiliser le device mapper, cf man dmsetup(8).
Tu laisses ton disque non-partitionné, et tu crées un fichier qui contient la « table » des morceaux de disque que tu veux agréger dans un nouveau device, selon la syntaxe indiquée dans le manuel :
Ensuite tu crées le device :
dmsetup create disque_aggrege --table ma_table.txt
Si tu veux voir comment ça fait avec tes devices LVM actuels, histoire de comprendre :
dmsetup ls
dmsetup table mon_device
[^] # Re: Rappel du principe
Posté par benoar . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 4.
Ah, je ne savais pas pour les extensions.
Par contre, ton VirtualGL c'est autre chose : c'est utiliser l'accélération du client X11 pour envoyer des frames déjà rendues sur le client au serveur X11. Après, l'argument qu'ils avancent de la non-efficacité de faire de l'OpenGL à distance est peut-être vrai, mais du coup s'applique (de ce que je comprends) également à waypipe avec accélération 3D.
[^] # Re: Rappel du principe
Posté par benoar . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 4.
X11 peut forwarder l'OpenGL sur le réseau depuis 20 ans à peu près…
[^] # Re: liberté
Posté par benoar . En réponse au journal De retour du FOSDEM 2020. Évalué à 5.
Et en plus avec des bières, dans des bouteilles en verre ! C'est « hallucinant » d'une certaine manière, mais tellement humain en vrai.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 3.
Je ne suis pas sûr qu'on se soit bien compris, mais :
Si tu parles bien d'utiliser sa propre infrastructure qu'on maîtrise pour le triplage de la facture, oui effectivement ça n'est pas un choix facile. On ne peut malheureusement pas tout avoir.
Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).
Après, une attaque « via des logiciels établis » est toujours possible, mais on commence encore une fois selon moi à entrer dans des probabilités tellement basses que la question du compromis tiens toujours : je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.
[^] # Re: Au sujet du terme ingénieur...
Posté par benoar . En réponse au journal Partage d’expérience : comment je suis devenu ingénieur diplômé par l’État à 44 ans. Évalué à 1.
Peut-être pour certaines écoles d'ingé, plutôt privées comme tu l'indiques, mais j'ai « comparé » avec des gens que je connais bien issus d'école publiques renommées, et pour moi il y a quand même quelque-chose « en plus » avec celles-ci (INSA en l'occurence). Ou alors c'était ma fac qui n'était pas géniale…
Bon après il y a également l'effet réseau professionnel qui te permet « automatiquement » d'avoir des postes mieux après de bonnes écoles d'ingé, mais ça ça n'est pas très reluisant.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 7.
À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.
Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.
L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.
Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 1.
Ça a été montré pour un cas spécifique, mais perso je n'ai pas pu le reproduire, et d'autres personnes me l'ont également confirmé. C'était au début, ça s'est peut-être amélioré depuis, mais on reste sur des méthodes probabilistes qui dépendent d'un alignement de bonnes étoiles (même si oui, ça peut arriver).
Ça se fait pas en un commentaire, et je ne suis pas un méga-spécialiste qui pourrait se permettre de lister ça sereinement. Ce que je veux dire, c'est que la publicité faite sur ces failles occulte un tas d'autres choses qui sont plus importantes, c'est tout.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 6.
Pas ceux des utilisateurs déjà, puisque l'utilisation des droits est déjà une barrière pour les problèmes humains, qui par définition ne sont pas contrôlable par un admin comme les programmes qui tournent sur sa machine.
Pour les démons, effectivement on met une protection en plus à priori « pas nécessaire » que je trouve déloyal de comparer à cette faille-ci : je pense qu'il y a beaucoup plus de probabilité qu'arrive une RCE qui ne sera pas exploitable pour éscalader les droits que quelqu'un vienne te faire un cacheout sur des secrets spécifiques pour arriver à ses fins. Faire tourner des démons avec des droits distincts, c'est relativement simple, n'a pas d'impact de perf, et te protège de beaucoup de choses. Ici, c'est chiant à mettre en place, pour un gain vraiment très faible. C'est la différence que je fait.
La probabilité que ça arrive est à mon avis assez faible. Mais bon, c'est juste mon avis.
En fait, on ne fait aucune pub pour toutes les bonnes pratiques autres qui sont beaucoup plus logiques et simples à appliquer, et on passe son temps à parler des ces trucs hyper techniques qui ont des probabilité de fonctionner tellement faible que ça en est ridicule. Ça fait parler de Intel, et du bad buzz c'est quand même du buzz, et on donne une attention complètement disproportionnée à ce genre de problème. Ça entraînera forcément une négligence sur d'autres aspects qui auraient pu être beaucoup plus constructifs.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 3.
J'aimerais, mais je sais bien que ça n'est pas possible. Et à ce moment-là, comme le dit kowalsky, tu as bien d'autres problèmes plus prioritaires à te soucier que ces failles.
Je suis d'accord qu'il faut avoir plusieurs niveaux de protection, mais franchement il y aura à mon avis plus simple que cette faille pour arriver à tes fins dans ce cas-là. On fait tout un foin sur cette histoire, alors que plein de gens font tourner des tas de containers pas à jours avec aucun suivi de CVE. Tu veux essayer de « mitiger » après avec ta super protection anti-Cacheout ? Ton ordre des priorités est vraiment étrange, selon moi.