Alors si, moi je travaille gratuitement pour Google.
En echange de leur fournir des donnees pour optimiser leur machine learning, ils offrent un service de captcha, c'est a dire que tu n'as pas a payer pour ca (dans tes impots).
L'EFS bénéficie d'un service de filtrage, pas moi. Par contre, pas de chance, au final Google si finance par la publicité, qui est une taxe globale qu'on finit tous par payer. Donc Google est « payé » des deux côtés : par mon travail qui enrichit son outil, et par la taxe publicitaire que je paye (avec d'autres).
Je comprends que tu n'aimes pas mais de la a appeler ca du travail force…
« Travail forcé » au sens où le besoin de base ne requiert pas de travail de ma part (enfin, là c'est spécifique, je vais faire une action de don, qui peut déjà être une sorte de « travail »…), mais on me demande d'en faire pour une raison technique et politique qui est qu'un service non-authentifié proposé sur le réseau ouvert mondial est soumis à des abus divers. Il y a différente manières de s'en prémunir (authentifier les gens, changer Internet pour garder que les gens biens, trier les spams à la main, etc), et là ils ont choisit la méthode où c'est moi qui vais devoir passer du temps à bosser. L'EFS l'a choisit, pas moi, donc pour moi c'est du travail forcé. (oui, après je peux juste refuser de donner mon sang et ne pas travailler pour Google, aussi)
Bon déjà c'est ton service local de collecte du sang qui a décidé de rendre obligatoire le renseignement d'un captcha fourni par Google
C'est l'EFS au niveau national. Et comme j'ai dit, ça s'étend à plus en plus de services, dans tous les domaines, nationalement.
Ou alors tout marche bien et juste tu voulais pas remplir un captcha même pour donner ton sang et (sincèrement) c'est bien ton droit mais appelons un (capt)chat un (capt)chat.
Donc Google ne peut pas te mettre en prison directement, mais te faire travailler gratuitement sur des applications qui permettront à des robots de contrôler ta vie (les voitures autonomes ; et demain, ça sera quoi ?), ça n'est pas grave. Les travaux forcés version moderne, quoi.
Ha oui, avec tes délires tu n'expliques pas comment VLC n'est pas interdit en UE si ils violent des brevets…
Tu connais très bien la réponse : parce qu'ils ne font pas de blé avec. Les brevets c'est pour faire du racket quand tu vois un concurrent trop menaçant : bref, garder le libre dans son cercle d'amateurs sympas, mais si quelqu'un veut professionnaliser le truc, il ne pourra pas à moins de rentrer dans le jeu. Ça tombe bien, tu es un professionnel du secteur, tu vas pouvoir nous dire comment ça marche de près !
Effectivement, mais il peut faire des choses tout à fait dégueulasses car moins directement visibles mais tout aussi contraignantes pour les gens : par exemple, véridique, Google m'a empêché il y a quelques jours de donner mon sang ; reCAPTCHA obligatoire, plus de RDV par téléphone, point. Certes, c'est avec la collaboration de services publics, mais c'est de plus en plus courant, ceux qui se font prendre pour des robots par Google n'auront bientôt plus de travail (quasi-réel, Pôle-Emploi t'envoie vers beaucoup de services qui le requièrent et te radie si tu ne le fais pas), plus de réseau social, plus de transport (SNCF en ce moment), etc. Ça n'est pas directement la prison, mais c'est quand même assez invivable.
C'est triste de pinailler à ce point quand Benjamin est un grand défenseur de la liberté logicielle contre les brevets, que je pensais que tu connaîtrais vu que c'est un « vieux » comme nous. Il cite MP4 comme mot « courant » pour désigner cette technologie, et sa remarque est tout à fait valable pour les codecs plus récents que tu cites.
Oui en gros casser complètement le fonctionnement classique d'une ML : le From est celui de la liste, avec comme nom d'affiche « Jean Dupont (pour la ML machin)", ce que je trouve trompeur et pas pratique. Bref, relayer sans changer le contenu, c'est pas mal comme juste milieu je trouve.
Merci encore. Bref, tu es optimistes parce qu'il semble y avoir un certain nombre de personnes de qualité qui y croient également, et ça se comprend. C'est vachement intéressant ta liste d'évolutions récentes ! Et bravo de citer les auteurs.
Merci, c'est très intéressant. Je vais t'embêter encore un peu si ça ne te dérange pas (je comprendrais que tu n'aies pas le temps de répondre) : penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ? Enfin, ça ressemble plus à un hack qu'autre chose, mais d'un côté de ce que j'ai lu de la RFC 1847 on ne peut pas toucher à la structure multipart/signed donc on est obligé de « l'encapsuler » dans un multipart/mixed si on veut rajouter quelque-chose après.
Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance. Es-tu d'accord ?
Merci pour ta réponse. Sur les qualités de l'e-mail hors confidentialité (persistante ou non), intégrité, signature/attestation, non-répudiation je les connais bien, mais ma question était plus orientée sur qu'est-ce qui te fait croire en la sécurisation possible de l'e-mail, au sens des qualités que je viens de citer ? Ta réponse est peut-être uniquement « gnupg le fait bien », mais c'était pour savoir si tu savais argumenter plus précisément dans ce sens, quand d'autres répliquent que « ça ne marchera jamais ».
Tu soulignes bien en tous cas que les qualités que tu voies à l'e-mail sont effectivement décrites comme étant des défauts par d'autres, mais j'ai effectivement la même approche « libre » des technologies : apprendre à l'utilisateur à lire et à écrire, qu'on désignait entre autre comme faisant partie de « l'instruction » des élèves, est essentiel pour en faire des citoyens libres (enfin, leur équivalent numérique).
Par contre, sur l'e-mail killer dont j'en ai effectivement vu passer un paquet, j'ai un peu moins d'espoir que toi : Facebook a bouffé une bonne partie des communications inter-personnelles, et pour une très grande partie de la population (c'est ce qui manquait aux précédents, l'étendue générationnelle). Il reste la communication « entreprise », mais c'est en train d'être attaqué par d'autres. Je tiens toujours à mon e-mail, j'aime le low-tech, mais j'ai un peu peur de l'avenir.
(Mais c’était une mauvaise idée en fin de compte.)
T'es fort pour nous laisser en suspend sur des problèmes intéressants… pourquoi, si c'est pas indiscret ? (ça n'est pas mentionné sur la page de fmail, ça pourrait être intéressant de l'expliquer pour l'histoire)
Un des gros problèmes de cette solution est qu’elle interdit pratiquement toute utilisation de PGP/MIME, sauf pour les fous furieux qui aiment construire et parser des structures MIME « à la main ».
Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça ; cf. le man qui indique à la fin explicitement une utilisation de GPG avec un document MIME.
D’une part parce que sécuriser l’e-mail est un problème difficile (tellement difficile que beaucoup de cryptologues ont purement abandonné cette idée et disent aujourd’hui « utilisez Signal »), mais aussi et surtout parce qu’un des intérêts d’OpenPGP en général et de GnuPG en particulier est de donner le contrôle aux utilisateurs (empowering the users, comme on dit en anglais), ce que les approches à la Signal ne font pas.
Par curiosité, pourrais-tu présenter les arguments qui t'incitent à continuer dans la voie d'essayer de sécuriser l'e-mail ? Je suis personnellement pour, même si je ne pratique pas, parce qu'un système de messagerie historique, ouvert, simple et a-centré comme l'email est pour moi indispensable à une vraie informatique libre, même s'il est très imparfait, mais je cherche d'autres arguments si possible :-)
Augeas https://augeas.net/ n'a pas type mais a des sortes de schémas qui sont des « lentilles », basées sur des regexp, qui ont en plus une base théorique solide si c'est ton genre de truc. Ça permet de faire de la modification de fichier de configuration avec toute une base de schémas déjà existant pour plein de logiciels qu'on trouve dans /etc. C'est complètement bidirectionnel ce qui est assez génial, et offre une API accessible dans plein de langages pour de la modification programmatique de fichier de configuration.
Bon, c'est assez différent en fait, car ça n'est pas un truc « générique » comme a l'air d'être le tiens, mais pour gérer de la conf ça semble quand même vachement plus sympa (mon avis).
La migration des clés est un processus prévu dans la norme ! Après, c'était l'époque du TPM 1.2, mais c'était bien un des exemple d'utilisation nécessaire pour certains besoins.
Bravo en passant pour ton journal/dépêche, ça fait du bien de toujours retrouver du contenu très technique encore aujourd'hui.
Ça ressemble vachement à Oracle avec sa base de données ce que vous racontez : utilisé partout par des gens qui le maîtrisent mal et n'ont pas besoin d'un logiciel aussi pléthorique, mais niveau commercial ça turbine à fond.
C'est une manière de voir, mais beaucoup arguent que continuer à construire des centrales très puissantes nous engagent sur un moyen terme ou il sera possible de continuer à consommer comme on le fait aujourd'hui, sans devoir changer en profondeur.
Je suis convaincu de la nécessité de décroître, mais sur les arguments que avoir beaucoup d'énergie nucléaire nous « ferait croire » qu'on peut continuer comme avant ce sont des ressorts psychologiques qui ne sont pas du tout avérés et restent de la spéculation sociologique. J'ai lu François Roddier, si c'est le genre de personne dont tu parles, et même s'il est plutôt convainquant, reste qu'imaginer faire la transition dans une société sans énergie nucléaire suffisante est quelque-chose qui me fait peur.
J'estime que transmettre le savoir et informer sur le changement climatique est une part essentielle de mon boulot de météorologue.
Tout à fait. Mais il y a tellement d'autres choses à faire avant imaginer que fabriquer d'autres centrales nucléaires soit un problème sérieux, surtout si tu crois pouvoir arriver à faire vivre une société comme la nôtre avec si peu d'énergie dans un laps de temps si court ! Comment veux-tu faire réaliser aux gens les concessions nécessaires pour un scénario Négawatt (par exemple) qui est pourtant présenté par les autorités comme plutôt sérieux, alors qu'il faudra qu'ils abandonnent en grande partie en à peine 30 ans transport individuel, chauffage et viande ? Bien sûr qu'il faut s'y préparer, mais commençons par prioriser ses combats !
OK donc pour reformuler en français, le « propriétaire » de la machine (je mets entre guillemets parce que pour les logiciels qui tournent dessus c'est un mensonge, il n'en est pas propriétaire du tout ; juste du matériel) peut demander gentiment à HPE de faire valider (signer) sa clé intermédiaire qui lui permettra de faire tourner le(s) firmeware(s) de son choix, pour certaines machines désignées seulement. C'est mieux que rien, mais perso c'est une telle entrave à la liberté de faire tourner ses logiciels que j'ai beaucoup de peine à appeler ça une « liberté de choix », mais bon. Encore moins de décrire la volonté de « protection » comme légitime, mais c'est mon avis perso.
Le fait que tu décrives le mécanisme en détail sans évoquer de grand système de gestion connu me fait penser que c'est une solution ad-hoc, imaginée par vous dans un coin, et ça ne me rassure pas du tout sur la maturité du truc : ça ressemble à un proto qui a de grands risques de ne jamais voir le jour. Vous basez-vous sur un dérivé de ce qui a été fait pour le Secure Boot sur UEFI (pas que ça soit un système qui ait ma sympathie, mais il a le mérite d'exister), ou alors c'est du BootGuard avec implémentation custom ? Sans parler des questions de gestion, qui sont malheureusement souvent oubliées des concepteurs de ce genre de solution parce que c'est la partie selon moi la plus importante, puisqu'elle concerne les garanties que les utilisateurs peuvent attendre d'un tel système, mais qu'en général c'est la dernière préoccupation des constructeurs. Bref, ça ressemble plus à de la poudre aux yeux qu'à un réel système qui mettrait vaguement en avant l'intérêt de l'utilisateur.
Ca peut sembler etre une usine a gaz, mais a court terme, cela permet deja d'avancer et ne compromet pas le mode de fonctionnement deja etablit.
Le principe technique ne me paraît pas tant usine à gaz : les chaînes de confiance à niveaux multiples sont un classique — même si ici tu ajoutes une propriété comme l'ID de la machine —, et je comprends la volonté de rétro-compatibilité avec l'existant. Mais cette volonté de faire du spécifique est pour moi vouée à l'échec. Enfin, toutes les solutions de protection de ce genre sont pour moi pourries, donc d'un côté je suis content qu'elle échoue.
On etudie d'autres options avec moins de dependances vis a vis d'HPE
Est-ce une réelle volonté ou un affichage pour faire sembler de ce préoccuper de ce point ?
et/ou sans tier de confiance en utilisant une approche blockchain
OK je suis désolé mais quand tu en arrives à sortir ça, pour moi tu es 100% dans le bullshit sans avoir compris réellement le problème. Tu es comme un certain nombre de personne à t'amuser avec de la crypto parce que c'est marrant, mais tu n'as pas compris l'essentiel des problématiques de liberté d'utilisation des machines. C'est un dilemme classique : on met des personne qui croient honnêtement œuvrer à faire des choses bien, mais qui abordent un problème sans les connaissances adéquates. Je sais que tu vas me trouver méprisant, mais je pense que tu devrais réellement te poser la question de ce que tu fais avec les techniques que tu es en train de mettre en place.
Merci en tous cas pour ces explications des mécanismes sur lesquels tu travailles.
Après, pour une note de contexte finale sur mon point de vue : perso, je trouve que la libération des firmwares a peu d'intérêt en dehors de la vérification de l'absence de fonction déloyale à l'utilisateur, et je ne cherche pas absolument à les « libérer » : en effet, ce sont des logiciels plutôt fixés et utilisés uniquement au démarrage de la machine, dont l'OS prend vite le relais. Bref, ça n'a pas un intérêt gigantesque en terme de liberté logicielle pour l'utilisateur. Et l'absence de fonction déloyale serait plutôt à chercher dans la publication de code source ou la certification par des organisme spécifique que dans la possibilité de faire tourner un firmware choisit par l'utilisateur, qui sera de toutes façons toujours une solution minoritaire et ne règle pas le problème de manière globale.
Pour le contexte, bépoète depuis plus de 10 ans, avec Typematrix.
Pourquoi on continue à s'évertuer à décaler les rangées de touches à chaque ligne du clavier ?
Parce qu'il n'existe pas de manière standard de rendre un 105 touches orthogonal ? Je veux dire, personne ne s'est encore mis d'accord sur quelle était la bonne manière de faire : Typematrix en a fait une qui vaut ce qu'elle vaut, mais il y a toujours un compromis à faire sur des touches qui vont être décalées en bas, en haut, voire à l'autre bout du clavier si on veut pouvoir rendre des colonnes inclinées partiellement droites dans une forme rectangulaire, parce que ça ferait vraiment bizarre d'avoir des trous si on redressait strictement un 105 touches classique sans réfléchir.
L'intérêt de garder toutes les touches peut sembler débile aux communautés de keyboard hackers, mais pour la plupart des gens c'est essentiel de ne pas se retrouver avec une touche manquante sur le mapping par défaut : c'est le problème des standards, il faut qu'il y ait toutes les touches présentes comme sur un 105 incliné, sinon ça ne fonctionnera pas. Regarde tous les orthogonaux alternatifs : ce sont des trucs pour spécialistes, avec chacun sa customisation, ça ne pourra jamais fonctionner comme standard global.
C'est pour moi un des grands avantages et une des grande victoire du bépo : avoir réussi a imposer un standard, qui ne plaît pas à tout le monde mais est quand même vachement bien pour la plupart des gens. Perso, j'ai arrêté la customisation à outrance pour mes softs et cherche toujours un entre deux : des customisation essentielles, tout en essayant de me dire que je pourrais me débrouiller sans, sur une config par défaut disponible chez tout le monde, même si ça n'est pas idéal.
Pourquoi le clavier à une main n'a pas été plus loin que ça ?
J'avais un mapping xkb à une main sur typematrix à une époque, il faudrait que je retrouve ça (juste pour les lettres) ; ça n'était qu'un test mais c'était « marrant ».
La difficulté technique repose principalement sur la mise en oeuvre des mécanismes de protection (légitime) des microcodes depuis quelques années (Silicon Root of Trust, et Intel Bootguard en sont quelques exemples). Comment concilier liberté de choix et mécanisme de protection ?
Heu, perso ça m'intéresse, parce que ça fait longtemps que j'étudie le sujet et que je ne vois absolument pas comment c'est possible… Déjà rien qu'au vocabulaire que tu utilises (« protection »), ça n'augure rien de bon. Mais je suppose que tes compromis sont différents de ceux que je pense acceptables. Aurais-tu plus de détails stp ?
OK, donc ça semble plutôt une source pas encore établie et en cours de recherche. C'est très intéressant ce que tu dis ici, mais il ne faudrait pas non plus vendre ça comme un consensus établi ; je pense que la volonté de mahikeulbody était d'être clair sur ce point.
Parce que quand même, dire qu'on ne peut plus faire de nucléaire à cause du réchauffement climatique, qui arrive parce qu'on n'a pas fait assez de nucléaire, c'est un peu fort de café à la base. Et ton 40 à 48° à l'ombre, si en plus tu veux baisser la clim pour que la conso énergétique baisse, ça ne va pas vraiment passer… Perso je suis absolument contre la clim, hein, pour que la boucle de rétro-action soit bien fermée sur la gueule des êtres humains, mais si on en rajoute encore plus en disant qu'il faut zéro nucléaire, tu auras autre chose à craindre que juste le réchauffement climatique.
LinuxFr a probablement parmi le meilleur comité de relecture du paysage informationnel français, tous sujets confondu.
Elle est bonne celle-là ! Je ne l'aurais pas imaginé de cette manière, mais c'est pas complètement faux :-) Oui, ça défouraille grave des fois, et c'est pour ça qu'on s'aime bien, mais je n'aurais jamais osé parlé de « comité de relecture » même si ça s'y prête bien !
Ceux qui écrivent sur Linuxfr sont pour la plupart des spécialistes de haut niveau qui savent parler avec passion de leurs domaines de prédilection.
Je sais bien, j'ai la prétention d'en faire partie /o\ Mais c'est vrai qu'il y a ce mélange de site « maison », de ton relâché, qui fait que même s'il y a effectivement de très bons contributeurs (c'est pour ça que je viens ici aussi !) ça ne fait pas très « officiel » ou « sérieux ». Mais c'est très drôle d'avoir ce mélange !
[^] # Re: Liberticide à long terme (i.e. pas tout de suite) ?
Posté par benoar . En réponse au journal StopCovid : inefficace, dangereux, totalitaire. Évalué à 4.
Alors si, moi je travaille gratuitement pour Google.
L'EFS bénéficie d'un service de filtrage, pas moi. Par contre, pas de chance, au final Google si finance par la publicité, qui est une taxe globale qu'on finit tous par payer. Donc Google est « payé » des deux côtés : par mon travail qui enrichit son outil, et par la taxe publicitaire que je paye (avec d'autres).
« Travail forcé » au sens où le besoin de base ne requiert pas de travail de ma part (enfin, là c'est spécifique, je vais faire une action de don, qui peut déjà être une sorte de « travail »…), mais on me demande d'en faire pour une raison technique et politique qui est qu'un service non-authentifié proposé sur le réseau ouvert mondial est soumis à des abus divers. Il y a différente manières de s'en prémunir (authentifier les gens, changer Internet pour garder que les gens biens, trier les spams à la main, etc), et là ils ont choisit la méthode où c'est moi qui vais devoir passer du temps à bosser. L'EFS l'a choisit, pas moi, donc pour moi c'est du travail forcé. (oui, après je peux juste refuser de donner mon sang et ne pas travailler pour Google, aussi)
[^] # Re: Liberticide à long terme (i.e. pas tout de suite) ?
Posté par benoar . En réponse au journal StopCovid : inefficace, dangereux, totalitaire. Évalué à 4.
C'est l'EFS au niveau national. Et comme j'ai dit, ça s'étend à plus en plus de services, dans tous les domaines, nationalement.
Donc Google ne peut pas te mettre en prison directement, mais te faire travailler gratuitement sur des applications qui permettront à des robots de contrôler ta vie (les voitures autonomes ; et demain, ça sera quoi ?), ça n'est pas grave. Les travaux forcés version moderne, quoi.
[^] # Re: Brevets MP4
Posté par benoar . En réponse à la dépêche Le Parlement européen adopte la préférence pour le logiciel libre pour les institutions de l’UE. Évalué à 2.
Tu connais très bien la réponse : parce qu'ils ne font pas de blé avec. Les brevets c'est pour faire du racket quand tu vois un concurrent trop menaçant : bref, garder le libre dans son cercle d'amateurs sympas, mais si quelqu'un veut professionnaliser le truc, il ne pourra pas à moins de rentrer dans le jeu. Ça tombe bien, tu es un professionnel du secteur, tu vas pouvoir nous dire comment ça marche de près !
[^] # Re: Liberticide à long terme (i.e. pas tout de suite) ?
Posté par benoar . En réponse au journal StopCovid : inefficace, dangereux, totalitaire. Évalué à 7.
Effectivement, mais il peut faire des choses tout à fait dégueulasses car moins directement visibles mais tout aussi contraignantes pour les gens : par exemple, véridique, Google m'a empêché il y a quelques jours de donner mon sang ; reCAPTCHA obligatoire, plus de RDV par téléphone, point. Certes, c'est avec la collaboration de services publics, mais c'est de plus en plus courant, ceux qui se font prendre pour des robots par Google n'auront bientôt plus de travail (quasi-réel, Pôle-Emploi t'envoie vers beaucoup de services qui le requièrent et te radie si tu ne le fais pas), plus de réseau social, plus de transport (SNCF en ce moment), etc. Ça n'est pas directement la prison, mais c'est quand même assez invivable.
[^] # Re: Brevets MP4
Posté par benoar . En réponse à la dépêche Le Parlement européen adopte la préférence pour le logiciel libre pour les institutions de l’UE. Évalué à 0.
C'est triste de pinailler à ce point quand Benjamin est un grand défenseur de la liberté logicielle contre les brevets, que je pensais que tu connaîtrais vu que c'est un « vieux » comme nous. Il cite MP4 comme mot « courant » pour désigner cette technologie, et sa remarque est tout à fait valable pour les codecs plus récents que tu cites.
[^] # Re: petite série de tee-shirts
Posté par benoar . En réponse au journal LinuxFr.org : seconde quinzaine de mai 2020. Évalué à 6.
Un petit aperçu pour qu'on voie à quoi ça ressemble ?
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 2.
Oui en gros casser complètement le fonctionnement classique d'une ML : le From est celui de la liste, avec comme nom d'affiche « Jean Dupont (pour la ML machin)", ce que je trouve trompeur et pas pratique. Bref, relayer sans changer le contenu, c'est pas mal comme juste milieu je trouve.
[^] # Re: c'e'st déjà un peu le cas
Posté par benoar . En réponse au journal pourquoi pas: vaccin libre/opensource. Évalué à 4.
N'importe quoi : https://www.bastamag.net/production-masques-FFP2-strategie-industrielle-usine-Plaintel-plan-social
[^] # Re: Ouh là lààààà
Posté par benoar . En réponse à la dépêche Bien démarrer avec GnuPG. Évalué à 3.
Merci encore. Bref, tu es optimistes parce qu'il semble y avoir un certain nombre de personnes de qualité qui y croient également, et ça se comprend. C'est vachement intéressant ta liste d'évolutions récentes ! Et bravo de citer les auteurs.
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 3.
Merci, c'est très intéressant. Je vais t'embêter encore un peu si ça ne te dérange pas (je comprendrais que tu n'aies pas le temps de répondre) : penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ? Enfin, ça ressemble plus à un hack qu'autre chose, mais d'un côté de ce que j'ai lu de la RFC 1847 on ne peut pas toucher à la structure multipart/signed donc on est obligé de « l'encapsuler » dans un multipart/mixed si on veut rajouter quelque-chose après.
Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance. Es-tu d'accord ?
[^] # Re: Ouh là lààààà
Posté par benoar . En réponse à la dépêche Bien démarrer avec GnuPG. Évalué à 2.
Merci pour ta réponse. Sur les qualités de l'e-mail hors confidentialité (persistante ou non), intégrité, signature/attestation, non-répudiation je les connais bien, mais ma question était plus orientée sur qu'est-ce qui te fait croire en la sécurisation possible de l'e-mail, au sens des qualités que je viens de citer ? Ta réponse est peut-être uniquement « gnupg le fait bien », mais c'était pour savoir si tu savais argumenter plus précisément dans ce sens, quand d'autres répliquent que « ça ne marchera jamais ».
Tu soulignes bien en tous cas que les qualités que tu voies à l'e-mail sont effectivement décrites comme étant des défauts par d'autres, mais j'ai effectivement la même approche « libre » des technologies : apprendre à l'utilisateur à lire et à écrire, qu'on désignait entre autre comme faisant partie de « l'instruction » des élèves, est essentiel pour en faire des citoyens libres (enfin, leur équivalent numérique).
Par contre, sur l'e-mail killer dont j'en ai effectivement vu passer un paquet, j'ai un peu moins d'espoir que toi : Facebook a bouffé une bonne partie des communications inter-personnelles, et pour une très grande partie de la population (c'est ce qui manquait aux précédents, l'étendue générationnelle). Il reste la communication « entreprise », mais c'est en train d'être attaqué par d'autres. Je tiens toujours à mon e-mail, j'aime le low-tech, mais j'ai un peu peur de l'avenir.
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 3.
T'es fort pour nous laisser en suspend sur des problèmes intéressants… pourquoi, si c'est pas indiscret ? (ça n'est pas mentionné sur la page de fmail, ça pourrait être intéressant de l'expliquer pour l'histoire)
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 4.
Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça ; cf. le man qui indique à la fin explicitement une utilisation de GPG avec un document MIME.
[^] # Re: Ouh là lààààà
Posté par benoar . En réponse à la dépêche Bien démarrer avec GnuPG. Évalué à 5.
Par curiosité, pourrais-tu présenter les arguments qui t'incitent à continuer dans la voie d'essayer de sécuriser l'e-mail ? Je suis personnellement pour, même si je ne pratique pas, parce qu'un système de messagerie historique, ouvert, simple et a-centré comme l'email est pour moi indispensable à une vraie informatique libre, même s'il est très imparfait, mais je cherche d'autres arguments si possible :-)
# Ça me fait un peu penser à Augeas
Posté par benoar . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 3. Dernière modification le 27 mai 2020 à 00:09.
Augeas https://augeas.net/ n'a pas type mais a des sortes de schémas qui sont des « lentilles », basées sur des regexp, qui ont en plus une base théorique solide si c'est ton genre de truc. Ça permet de faire de la modification de fichier de configuration avec toute une base de schémas déjà existant pour plein de logiciels qu'on trouve dans /etc. C'est complètement bidirectionnel ce qui est assez génial, et offre une API accessible dans plein de langages pour de la modification programmatique de fichier de configuration.
Bon, c'est assez différent en fait, car ça n'est pas un truc « générique » comme a l'air d'être le tiens, mais pour gérer de la conf ça semble quand même vachement plus sympa (mon avis).
[^] # Re: sauvegarde de clé ?
Posté par benoar . En réponse à la dépêche Utilisation d’un TPM pour l’authentification SSH. Évalué à 4.
Je vais te ressortir un vieux commentaire de khane< d'une discussion qu'on avait eu il y a… 14 ans là-dessus :
https://linuxfr.org/news/tcpatpm-la-deferlante-silencieuse#comment-740971
La migration des clés est un processus prévu dans la norme ! Après, c'était l'époque du TPM 1.2, mais c'était bien un des exemple d'utilisation nécessaire pour certains besoins.
Bravo en passant pour ton journal/dépêche, ça fait du bien de toujours retrouver du contenu très technique encore aujourd'hui.
[^] # Re: PetiteMerveille
Posté par benoar . En réponse à la dépêche Proxmox VE 6.2 est disponible. Évalué à 5.
Ça ressemble vachement à Oracle avec sa base de données ce que vous racontez : utilisé partout par des gens qui le maîtrisent mal et n'ont pas besoin d'un logiciel aussi pléthorique, mais niveau commercial ça turbine à fond.
[^] # Re: diff, git, delta
Posté par benoar . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 2.
Un éditeur bien fait le fait normalement très bien aussi, cf. vimdiff par exemple.
[^] # Re: Warning!
Posté par benoar . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 1.
Je suis convaincu de la nécessité de décroître, mais sur les arguments que avoir beaucoup d'énergie nucléaire nous « ferait croire » qu'on peut continuer comme avant ce sont des ressorts psychologiques qui ne sont pas du tout avérés et restent de la spéculation sociologique. J'ai lu François Roddier, si c'est le genre de personne dont tu parles, et même s'il est plutôt convainquant, reste qu'imaginer faire la transition dans une société sans énergie nucléaire suffisante est quelque-chose qui me fait peur.
Tout à fait. Mais il y a tellement d'autres choses à faire avant imaginer que fabriquer d'autres centrales nucléaires soit un problème sérieux, surtout si tu crois pouvoir arriver à faire vivre une société comme la nôtre avec si peu d'énergie dans un laps de temps si court ! Comment veux-tu faire réaliser aux gens les concessions nécessaires pour un scénario Négawatt (par exemple) qui est pourtant présenté par les autorités comme plutôt sérieux, alors qu'il faudra qu'ils abandonnent en grande partie en à peine 30 ans transport individuel, chauffage et viande ? Bien sûr qu'il faut s'y préparer, mais commençons par prioriser ses combats !
[^] # Re: Mécanismes de protection ?
Posté par benoar . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 2.
OK donc pour reformuler en français, le « propriétaire » de la machine (je mets entre guillemets parce que pour les logiciels qui tournent dessus c'est un mensonge, il n'en est pas propriétaire du tout ; juste du matériel) peut demander gentiment à HPE de faire valider (signer) sa clé intermédiaire qui lui permettra de faire tourner le(s) firmeware(s) de son choix, pour certaines machines désignées seulement. C'est mieux que rien, mais perso c'est une telle entrave à la liberté de faire tourner ses logiciels que j'ai beaucoup de peine à appeler ça une « liberté de choix », mais bon. Encore moins de décrire la volonté de « protection » comme légitime, mais c'est mon avis perso.
Le fait que tu décrives le mécanisme en détail sans évoquer de grand système de gestion connu me fait penser que c'est une solution ad-hoc, imaginée par vous dans un coin, et ça ne me rassure pas du tout sur la maturité du truc : ça ressemble à un proto qui a de grands risques de ne jamais voir le jour. Vous basez-vous sur un dérivé de ce qui a été fait pour le Secure Boot sur UEFI (pas que ça soit un système qui ait ma sympathie, mais il a le mérite d'exister), ou alors c'est du BootGuard avec implémentation custom ? Sans parler des questions de gestion, qui sont malheureusement souvent oubliées des concepteurs de ce genre de solution parce que c'est la partie selon moi la plus importante, puisqu'elle concerne les garanties que les utilisateurs peuvent attendre d'un tel système, mais qu'en général c'est la dernière préoccupation des constructeurs. Bref, ça ressemble plus à de la poudre aux yeux qu'à un réel système qui mettrait vaguement en avant l'intérêt de l'utilisateur.
Le principe technique ne me paraît pas tant usine à gaz : les chaînes de confiance à niveaux multiples sont un classique — même si ici tu ajoutes une propriété comme l'ID de la machine —, et je comprends la volonté de rétro-compatibilité avec l'existant. Mais cette volonté de faire du spécifique est pour moi vouée à l'échec. Enfin, toutes les solutions de protection de ce genre sont pour moi pourries, donc d'un côté je suis content qu'elle échoue.
Est-ce une réelle volonté ou un affichage pour faire sembler de ce préoccuper de ce point ?
OK je suis désolé mais quand tu en arrives à sortir ça, pour moi tu es 100% dans le bullshit sans avoir compris réellement le problème. Tu es comme un certain nombre de personne à t'amuser avec de la crypto parce que c'est marrant, mais tu n'as pas compris l'essentiel des problématiques de liberté d'utilisation des machines. C'est un dilemme classique : on met des personne qui croient honnêtement œuvrer à faire des choses bien, mais qui abordent un problème sans les connaissances adéquates. Je sais que tu vas me trouver méprisant, mais je pense que tu devrais réellement te poser la question de ce que tu fais avec les techniques que tu es en train de mettre en place.
Merci en tous cas pour ces explications des mécanismes sur lesquels tu travailles.
Après, pour une note de contexte finale sur mon point de vue : perso, je trouve que la libération des firmwares a peu d'intérêt en dehors de la vérification de l'absence de fonction déloyale à l'utilisateur, et je ne cherche pas absolument à les « libérer » : en effet, ce sont des logiciels plutôt fixés et utilisés uniquement au démarrage de la machine, dont l'OS prend vite le relais. Bref, ça n'a pas un intérêt gigantesque en terme de liberté logicielle pour l'utilisateur. Et l'absence de fonction déloyale serait plutôt à chercher dans la publication de code source ou la certification par des organisme spécifique que dans la possibilité de faire tourner un firmware choisit par l'utilisateur, qui sera de toutes façons toujours une solution minoritaire et ne règle pas le problème de manière globale.
# Parce qu'il n'y a pas d'orthogonalisation standard du 105 touches ?
Posté par benoar . En réponse au journal Clavier orthogonal, clavier à une main, etc pourquoi rien ne change ?. Évalué à 2.
Pour le contexte, bépoète depuis plus de 10 ans, avec Typematrix.
Parce qu'il n'existe pas de manière standard de rendre un 105 touches orthogonal ? Je veux dire, personne ne s'est encore mis d'accord sur quelle était la bonne manière de faire : Typematrix en a fait une qui vaut ce qu'elle vaut, mais il y a toujours un compromis à faire sur des touches qui vont être décalées en bas, en haut, voire à l'autre bout du clavier si on veut pouvoir rendre des colonnes inclinées partiellement droites dans une forme rectangulaire, parce que ça ferait vraiment bizarre d'avoir des trous si on redressait strictement un 105 touches classique sans réfléchir.
L'intérêt de garder toutes les touches peut sembler débile aux communautés de keyboard hackers, mais pour la plupart des gens c'est essentiel de ne pas se retrouver avec une touche manquante sur le mapping par défaut : c'est le problème des standards, il faut qu'il y ait toutes les touches présentes comme sur un 105 incliné, sinon ça ne fonctionnera pas. Regarde tous les orthogonaux alternatifs : ce sont des trucs pour spécialistes, avec chacun sa customisation, ça ne pourra jamais fonctionner comme standard global.
C'est pour moi un des grands avantages et une des grande victoire du bépo : avoir réussi a imposer un standard, qui ne plaît pas à tout le monde mais est quand même vachement bien pour la plupart des gens. Perso, j'ai arrêté la customisation à outrance pour mes softs et cherche toujours un entre deux : des customisation essentielles, tout en essayant de me dire que je pourrais me débrouiller sans, sur une config par défaut disponible chez tout le monde, même si ça n'est pas idéal.
J'avais un mapping xkb à une main sur typematrix à une époque, il faudrait que je retrouve ça (juste pour les lettres) ; ça n'était qu'un test mais c'était « marrant ».
# Mécanismes de protection ?
Posté par benoar . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 3.
Heu, perso ça m'intéresse, parce que ça fait longtemps que j'étudie le sujet et que je ne vois absolument pas comment c'est possible… Déjà rien qu'au vocabulaire que tu utilises (« protection »), ça n'augure rien de bon. Mais je suppose que tes compromis sont différents de ceux que je pense acceptables. Aurais-tu plus de détails stp ?
[^] # Re: Warning!
Posté par benoar . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 4.
OK, donc ça semble plutôt une source pas encore établie et en cours de recherche. C'est très intéressant ce que tu dis ici, mais il ne faudrait pas non plus vendre ça comme un consensus établi ; je pense que la volonté de mahikeulbody était d'être clair sur ce point.
Parce que quand même, dire qu'on ne peut plus faire de nucléaire à cause du réchauffement climatique, qui arrive parce qu'on n'a pas fait assez de nucléaire, c'est un peu fort de café à la base. Et ton 40 à 48° à l'ombre, si en plus tu veux baisser la clim pour que la conso énergétique baisse, ça ne va pas vraiment passer… Perso je suis absolument contre la clim, hein, pour que la boucle de rétro-action soit bien fermée sur la gueule des êtres humains, mais si on en rajoute encore plus en disant qu'il faut zéro nucléaire, tu auras autre chose à craindre que juste le réchauffement climatique.
[^] # Re: Manque de citations françaises de linuxfr ?
Posté par benoar . En réponse à la dépêche Ces articles, papiers et autres publications qui mentionnent LinuxFr.org. Évalué à 2.
Elle est bonne celle-là ! Je ne l'aurais pas imaginé de cette manière, mais c'est pas complètement faux :-) Oui, ça défouraille grave des fois, et c'est pour ça qu'on s'aime bien, mais je n'aurais jamais osé parlé de « comité de relecture » même si ça s'y prête bien !
[^] # Re: Manque de citations françaises de linuxfr ?
Posté par benoar . En réponse à la dépêche Ces articles, papiers et autres publications qui mentionnent LinuxFr.org. Évalué à 1.
Je sais bien, j'ai la prétention d'en faire partie /o\ Mais c'est vrai qu'il y a ce mélange de site « maison », de ton relâché, qui fait que même s'il y a effectivement de très bons contributeurs (c'est pour ça que je viens ici aussi !) ça ne fait pas très « officiel » ou « sérieux ». Mais c'est très drôle d'avoir ce mélange !