Je suppose que tu fais une distinction qui, comme le chante les Inconnus, n'est pas dans les dicos.
Il y a bien (ou il devrait y avoir) une éthique du logiciel libre, la morale, par contre…
Ça dépend du sens du mot morale, mais soit, remplaçons morale par éthique.
Et dans ce cas, en dehors de la justification à priori que j'ai proposé, quel sont les raisons d'avoir une éthique du logiciel libre ? (et qu'est ce que cette éthique dit en pratique, car c'est marqué nulle part)
Toi et l'auteur de l'article parlez de gratuit, mais absolument
rien dans le libre n'en parle, le choix du gratuit ou pas
gratuit n'a absolument rien à voir avec le libre (perso je fais
parfois du libre payant, aucun problème légal).
Sauf qu'en pratique, c'est pas ce qu'on voit. Pour moi, il est claire que si mon employeur doit payer une équipe commercial pour expliquer que le libre, c'est pas toujours gratuit, c'est bien parce que justement, l'association libre == gratuit est répandu et semble naturel à tout le monde.
Venir dire "c'est pas ce qui est dans les textes", c'est nié la perception courante et aller à contre courant de ce qui semble logique à beaucoup de gens. Et encore une fois, le simple fait de devoir le dire montre que ce n'est pas ce que pense une grande majorité des gens.
Tu fais l'erreur de mettre tout les libristes comme ayant un même objectif
Tu pinailles sur une figure de style.
C'est comme si je disait que tu es amorale parce que tu dis que tu n'as aucun moralité, mais en pratique, je sais que c'est une figure de style de ta part, car je doute que tu te réclames n'avoir aucun sens du bien ou du mal dans toute circonstance, et je comprends bien qu'il faut prendre tes propos dans le cadre de la discussion uniquement.
Un point qui me chagrine dans ce genre d'article, c'est le manque de recul critique.
L'article commence par RMS et comment le logiciel libre est une cause morale (et comment ça a été oublié). Mais quand on regarde l'histoire, la seule chose que le mouvement du libre avait pour vocation à révolutionner, c'est la science informatique. RMS était chercheur par profession, et c'est le non échange entre scientifiques qui lui a posé des soucis (cf la fameuse histoire de l'imprimante), d'ou le fait de monter GNU, etc. Le fait d'avoir réussi à transformer ça en révolution n'est qu'un exemple de plus du pipeline "recherche => industrie" qu'on retrouve assez souvent.
Et l'idée que la cause du libre est profondément morale semble avec l'age une justification à priori. Et comme toute justification à priori, il faut se poser la question de quel comportement on cherche à justifier.
Pour ma part, j'ai le sentiment que nous, les libristes, rajoutons un vernis de moralité afin de justifier à nos propres yeux de faire du travail gratuitement, surtout au regard des débats sur la maintenance du logiciel libre (que ça soit les questions de financement, les questions de burn out, etc).
Il me semble que c'est bien parce que le libre n'est pas naturellement aussi perenne que les autres moyens qu'on doit rajouter un impératif d'ordre moral, car sinon, il n'y aurait pas besoin. On peut dire tout le mal du code proprio qu'on veut (et ces critiques sont justifiés), mais le moyen de vivre sa vie avec, dans le système capitaliste actuel, est assez direct à mon plus grand regret.
Avec le recul, on peut voir que la GPL, pierre angulaire du mouvement du libre, ne se focalise que sur les libertés du point de vue de la personne qui est capable de lire et d'écrire le code (vu que 75% des 4 libertés tournent autour de ça).
Et qu'effectivement, le gros de ce que le logiciel libre a produit, c'est surtout des solutions pour l'industrie logicielle, car c'est la que se trouve les compétences qui en tire parti, et le chemin pour le rendre perenne.
Du coup, c'est à mon sens pas super étonnant que le logiciel libre ne libère pas le monde, vu que rien dans ses fondations n'est pensé pour ça, et que les efforts pour changer ça n'ont jamais abouti.
Tout au plus, le logiciel libre serait une brique dans une libération (au sens abstrait), mais c'est aussi un angle qui me parait assez peu discuté. Par exemple, l'article en lien parle de "permacomputing", mais uniquement à la fin et sans faire de lien direct avec le constat mis en avant dans l'article. De même l'article parle des libertariens sans faire le lien avec des discussions sur le sujet (pour un exemple récent, l'affaire KF et Cloudflare, et l'idéologie qui justifie les choix du patron de CF).
J'aurais tendance à me méfier un peu des nitrokeys (et des solokeys), même si je pense que dans la plupart des cas, ce n'est pas un facteur si important.
Une des controverses autour de Yubico est le fait de ne plus publier le code du firmware il y a quelque années. C'est au moment ou la boite a pris une puce d'infineon au lieu de 2 puces de NXP. Et je suppose que la puce d'Infineon vient avec un NDA, d'ou le changement.
Manque de pot, c'est aussi venu avec une faille, mais c'est la vie, y a des bugs dans les logiciels.
Yubico avait publié un article pour expliquer qu'un contrôleur ARM classique n'était pas adapté, et j'ai tendance à être d'accord avec ce point.
Hors, la nitrokey, c'est un simple STM32F103 si j'en croit les schémas sur Github.
Donc du coup, le choix est entre du code qu'on peut auditer soi même sur du matériel avec des soucis potentiels, et du matériel moins problématique avec du code qu'on a pas pu auditer. Il y a un compromis à faire.
Dans la mesure ou j'irais pas auditer le code de Nitrokey moi même (parce que j'ai ni le temps, ni les compétences en crypto), la différence est de savoir si je fait confiance aux gens qui ont fait un audit potentiel.
J'ai tendance à paradoxalement faire confiance à une boite qui a déjà eu un souci de sécu publié, car elle va prendre plus au sérieux les choses qu'une autre ou je ne peut pas savoir si il n'y a rien car tout est parfait, ou parce que personne n'a rien tenté.
Donc à confiance égale, j'aurais tendance à prendre le matériel prévu pour la sécurité.
Ensuite, je pense aussi que les peurs sur une attaque en pratique visant à sortir les clés sont non fondés pour la plupart des usages. Dans la classification de James Mikens, je pense que je suis clairement dans Not-Mossad comme beaucoup de gens dans ce journal.
Et bon, 10 à 20€ de moins par ci par la, ça peut aider. Et nitrokeys fait du libre, collabore avec solokeys, publie des modifs sur odoo, etc, donc c'est une bonne chose de les soutenir.
J'ai jamais eu de sites m'empêchant de déclarer deux clés,
"Amazon EC2 has entered the chat"
Mais c'est bien le seul service ou j'ai ce probléme (et c'est mineur par rapport à ceux ou j'ai que le support d'une appli et pas des clés ). Ensuite, j'ai aussi un nombre réduit de comptes importants et je m'assure aussi d'avoir les codes de secours à portée de main.
Je pense qu'un truc qui aide, c'est de faire régulièrement le tour des comptes qu'on a dans son gestionnaire de mot de passe et soit de fermer les comptes, soit de vérifier qu'on a le 2FA correctement.
J'ai cru comprendre en lisant en diagonal que c'est pas 3 ans après le commit, mais 3 années après une release qui est dans le fichier de licence (ou 4 ans après une version spécifique).
Ensuite, la licence est vraiment mal fagoté je trouve.
La licence BSL balance "production use" et "non production use" sans vraiment définir le terme.
Car bon, pour un système de CI/CD, l'instance de jenkins et ses tests qui aboutissent au déploiement, c'est un usage en production. Si ton pipeline de déploiement est cassé et que quelqu'un est chargé de réparer ça, pour moi, c'est de la prod (ça produit quelque chose, c'est dans le nom).
Et donc, qui va vouloir faire une bibli qui utilise akka ou se connecte sur akka dans ces conditions alors qu'il y a une incertitude juridique parce que la licence est mal écrite ?
Et surtout, surtout : bordel, pourquoi est-ce-que ça doit prendre tant de place ?
Parce que c'est fait par le presta qui a proposé la presta la moins cher en prenant soit des gens qui sont en cours d'apprentissage (enfin, comme nous tous), ou a qui on a donné juste le temps qu'il faut avant les remettre sur un autre projet.
En même temps, je pense que le pneu ne va pas trop s'user dans l'espace (ou du moins, pas comme sur terre), donc c'est sans doute faisable (sauf si le plan est de construire une autoroute).
Ensuite, on pourrait aussi simplement demander aux devs de baisser leur salaire si on veut réduire l'inflation à ce niveau, mais on me dit que ça serait sans doute pas une mesure populaire.
ok, du coup tu dirais quoi? (puisque bon, BIOS corrompu ==
plein de complications pénibles à gérer ensuite)
Un BIOS corrompu (l'exemple du virus CIH de 1998 me vient en tête), ça serait comme du matos qui tombe en panne, sauf qu'on peut le réparer en reflashant.
Mais on peut imaginer pareil en terme de dégat sur le firmware du disque dur. En fait, c'est pire parce qu'un disque dur corrompu, ça va me coûter plus qu'un BIOS corrompu, vu que je peux changer la carte mère et voila. Sortir les données d'un disque foutu, ça coûte un chouia plus cher.
C'est pas le BIOS. L'iLO tourne sur un processeur à part sur une carte à part avec un OS à part (voir quasiment un Linux embarqué).
Je veux bien qu'on compte ça dans le BIOS sous le prétexte que ça vient avec le matériel dans ton serveur, mais ça serait un abus de langage.
Ensuite, si tu parles de la fonctionnalité équivalente pour les proc intel (eg, AMT), ça vient avec le processeur, pas avec le BIOS. Encore une fois, je veux bien qu'on compte tout qui est avant grub comme "le BIOS" mais ça serait toujours un abus de langage.
Est ce que le BIOS est plus sensible que le processeur ?
Je pense que non (et c'est pour ça aussi que je dit que le BIOS n'est pas le plus sensible en terme de sécurité), mais si on dit "le BIOS est le plus sensible en terme de sécurité", alors le processeur l'est moins. Et c'est pas ce que je voit vu le foin autour des procs intels.
Ensuite, si l'affirmation est "le plus sensible en terme de sécurité, c'est le matériel", l'omniprésence de matériel et/ou de firmware non libre me laisse croire que c'est pas si sensible que ça par rapport au logiciel.
Le matos est la, il est en vente, mais pourtant, j'ai pas le sentiment que ça se bouscule pour acheter (vu qu'il n'y a que Leah sur le coup depuis des années).
Le paranoïaque est il le seul à penser l'être suffisamment?
Je sais pas, je suis pas psychologue, faut aller voir le DSM.
"pas le plus sensible", ça veut pas dire "on s'en balek".
Ça veut juste dire que dans un classement, c'est pas en haut.
La preuve, pendant des années, on a pas eu de mécanismes simples de mises à jour du BIOS ou de l'UEFI (eg, fwupdate sous Linux), et que je sache, on a pas eu d'apocalypse, et que je voudrais bien dire "le nombre de souci de sécurité lié à un souci dans le BIOS se compte sur les doigts d'une main", mais j'ai rien qui me vient à l'esprit.
À coté de ça, on a eu plus de gens qui ont eu des soucis à cause des certificats et du manque de TLS, on eu plus de souci suite à des soucis de crypto (la faille openssh de debian en 2008), etc.
Ensuite, si tu veux éviter le homebrew sur ton matériel, oui. si tu es Google, Amazon ou Nintendo ou n'importe qui qui veut controler le matériel face à ses users, oui, il te faut un BIOS blindé.
Dans une console de jeux, le BIOS va importer à mort. Mais que je sache, on parle pas de ça ici. Et non seulement on parle pas de ça, mais en plus, si on en parle, on va en parler pour la perte de liberté que ça entraîne (eg, secureboot par défaut sur les trucs ARM, etc).
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
En fait, je pense pas qu'il y a un arrangement explicite.
Comme dit ailleurs, c'est de l'apprentissage avec du machine learning. Et si en effet, en moyenne, le fournisseur voit que les mails venant de ton range chez Belgacom, c'est surtout des virus et du spam, et qu'il y a 1 personne avec son serveur qui envoie un mail de temps en temps, les maths sont contre elle.
J'ai le même souci avec mon VPN pour l'IP v6. Je me fait régulièrement bloqué (ou je me prends des captchas) parce que je passe par digital ocean pour ça. Si j'avais mis le VPN sur la connexion de chez moi, je suis sur que j'aurais 0 soucis.
Par contre je ne pense pas que ce soit le spam qui favorise
l’émergence d'acteurs dominants ; tant qu'on est sur du libre,
les informations transitent, et les petits sont aussi armés que
les gros pour lutter contre le spam
Alors je ne pense pas que c'est le spam qui fait qu'on va chez un gros acteur.
Mais avoir 1 acteur avec 100 000 boites mails , ou 1000 acteurs avec 100 boites mails, ça change la donne.
Déjà, les 1000 acteurs, ça implique (pour simplifier) d'avoir 1 admin par acteur. L'acteur avec 100 000 boites mails, à ressources égales, il va se retrouver avec 1000 admins. Si on suppose que ça ne croit pas de manière linéaire et qu'on peut fire 100 000 boites mails avec 100 admins, alors l'acteur dominant va avoir plus de ressources pour lutter contre le spam (les 900 personnes), et il peut faire des choses que les plus petits ne peuvent pas.
Par exemple, il a une vue sur plus d'opérations, il va recevoir plus de spam et/ou plus vite, ce qui permet de réagir plus vite et donc d’arrêter plus vite, ce qui diminue le nombre de spam par utilisateurs.
En dehors de ses capacités, un acteur dominant a un avantage pour la lutte contre le spam.
Et tu parles d'avoir les informations qui transitent, mais il n'y a rien qui transite à part des DNSBL qui n'ont rien de libre ou d'ouvert.
Les systèmes modernes des GAFAMs se basent sur l'apprentissage statistique de la réputation des serveurs, mais ça ne marche que si tu as beaucoup de mail. Moi, avec mon serveur perso, je vais pas faire grand chose à ce niveau si j'ai 1 mail par jour.
Ce qui pourrait être fait pour les mails aussi, de façon assez trivial en fait.
C'est une des idées proposé par hey.com, et une qui peut se faire chez soi avec un peu de code.
Par exemple, tu envoies tout les mails ailleurs que dans ta inbox, sauf si le mail est dans une liste spécifique. Tu peux ensuite déplacer un email dans un dossier spécial pour déclencher le changement du filtre et le déplacement des emails qui correspondent vers la inbox.
Si c'était la solution, alors quelqu'un d'autre que Hey le proposerait. Mais visiblement, ça ne suffit pas.
Un point qui me semble revenir rarement est la question des autres fédérations. Par exemple, XMPP, Matrix, et tout ce qui tourne à ActivityPub.
Le protocole SMTP de base a plein de souci. Mais une fois qu'on rajoute DKIM, SPF, etc, le probléme du spam persiste.
Pour le moment, les autres protocoles fédérés sont épargnés en partie parce que relativement personne (à l'échelle de la planète) ne les utilisent pour le moment.
Est ce qu'il ne faut pas se poser la question de se dire ce qui devrait être fait avant qu'on refasse la même chose que l'email ?
Ou est ce qu'il faut juste accepter que c'est inéluctable et que ça vient avec le fait d'avoir du succès, donc du monde, donc des problèmes d'échelle qui entraîne l'ossification du protocole et l’émergence d'acteurs dominants.
C'est possible, mais ça ne posait pas de souci avec un autre opérateur (celui d'avant, et celui d’après aussi). Et mes collègues se plaignaient aussi du réseau chez eux (et moi aussi, c'est comme ça que j'ai su pour les femtocells).
C'est con, mais ça aide d'avoir du réseau pour recevoir les alertes nagios.
Certes mais ce n'était qu'un exemple. Le reste du logiciel est pareil. Prenons par exemple et justement l'action de modifier la barre d'outils.
C'est dans préférence, barre d'outils et de menu. C'est facile à trouver, mais quand on clique sur ça, on arrive sur une fenetre quasiment vide avec une liste déroulante.
Primo, le premier item "cliquer pour choisir la barre d'outils…" est un des choix possibles, alors qu'à mon sens, ça devrait être un label avec un choix par défaut (un clic de moins pour éditer).
Ensuite, choisir les éléments via leur nom, c'est pas exactement l'UX la plus intuitive, surtout quand tu as 2 réglages suivant la présence ou pas d'une liseuse branché, et ça me parait une magouille dans le code pour faire apparaître le bouton d'opération sur la liseuse la ou je pense qu'une bonne pratique, c'est d'avoir un bouton grisé quand rien n'est branché. Pour moi, ça serait comme avoir libreoffice avec 2 choix "document à sauver / document sans modification", pour cacher l’icône de sauvegarde
Ça mentionne une "seconde barre d'outil optionnel", d’où est ce qu'elle vient, quelle sont ses réseaux ? Il y aussi le "menu contextuelle pour la liste de livres divisées", je suppose que c'est le menu qui s'affiche pour clic droit, mais à quel moment (sachant qu'il y a toujours une liste de livre, donc qu'est ce qui est divisé) ?
C'est pas que le logiciel n'est pas utilisable, et j'ai vu largement pire.
Mais tout a un coté baroque.
Mon dernier exemple, quand tu va dans les préférences, tu peux fermer une fenêtre via la croix en haut. Sauf que la croix agit comme "retour arrière", vu que tu reviens à la fenêtre d'avant.
Il y a spécifiquement une surcharge d'un comportement par défaut d'un élément d'interface compris depuis les premiers macs.
Ça me fume un peu. Ensuite, c'est sans doute les séquelles de mes années à faire de l'ergonomie.
[^] # Re: durée de vie des sdcard
Posté par Misc (site web personnel) . En réponse au lien Bug de l'an 2038 : par exemple Raspberry Pi OS 32-bits est concerné (IoT). Évalué à 4.
Ensuite, vu les pénuries de Rpi 4, je suis pas sur qu'on va en avoir d'ici 2038.
[^] # Re: Version logicielle ?
Posté par Misc (site web personnel) . En réponse au journal Clés de sécurité, pas assez utilisées. Évalué à 5.
C'est ton jour de chance, j'ai vu ça sur reddit:
https://old.reddit.com/r/netsec/comments/xh3bae/virtual_fido_is_a_virtual_usb_device_that/
qui pointe vers ça:
https://github.com/bulwarkid/virtual-fido
[^] # Re: Un pavé dans la mare
Posté par Misc (site web personnel) . En réponse au lien les drones utilisent linux : le logiciel libre ce n’est pas suffisant. Évalué à 7.
Je veux bien mais bon, quand on regarde la définition:
éthique, Relatif à la morale, ce qui est moral.
Je suppose que tu fais une distinction qui, comme le chante les Inconnus, n'est pas dans les dicos.
Ça dépend du sens du mot morale, mais soit, remplaçons morale par éthique.
Et dans ce cas, en dehors de la justification à priori que j'ai proposé, quel sont les raisons d'avoir une éthique du logiciel libre ? (et qu'est ce que cette éthique dit en pratique, car c'est marqué nulle part)
[^] # Re: Un pavé dans la mare
Posté par Misc (site web personnel) . En réponse au lien les drones utilisent linux : le logiciel libre ce n’est pas suffisant. Évalué à 10.
Sauf qu'en pratique, c'est pas ce qu'on voit. Pour moi, il est claire que si mon employeur doit payer une équipe commercial pour expliquer que le libre, c'est pas toujours gratuit, c'est bien parce que justement, l'association libre == gratuit est répandu et semble naturel à tout le monde.
Venir dire "c'est pas ce qui est dans les textes", c'est nié la perception courante et aller à contre courant de ce qui semble logique à beaucoup de gens. Et encore une fois, le simple fait de devoir le dire montre que ce n'est pas ce que pense une grande majorité des gens.
Tu pinailles sur une figure de style.
C'est comme si je disait que tu es amorale parce que tu dis que tu n'as aucun moralité, mais en pratique, je sais que c'est une figure de style de ta part, car je doute que tu te réclames n'avoir aucun sens du bien ou du mal dans toute circonstance, et je comprends bien qu'il faut prendre tes propos dans le cadre de la discussion uniquement.
# Un pavé dans la mare
Posté par Misc (site web personnel) . En réponse au lien les drones utilisent linux : le logiciel libre ce n’est pas suffisant. Évalué à 10.
Un point qui me chagrine dans ce genre d'article, c'est le manque de recul critique.
L'article commence par RMS et comment le logiciel libre est une cause morale (et comment ça a été oublié). Mais quand on regarde l'histoire, la seule chose que le mouvement du libre avait pour vocation à révolutionner, c'est la science informatique. RMS était chercheur par profession, et c'est le non échange entre scientifiques qui lui a posé des soucis (cf la fameuse histoire de l'imprimante), d'ou le fait de monter GNU, etc. Le fait d'avoir réussi à transformer ça en révolution n'est qu'un exemple de plus du pipeline "recherche => industrie" qu'on retrouve assez souvent.
Et l'idée que la cause du libre est profondément morale semble avec l'age une justification à priori. Et comme toute justification à priori, il faut se poser la question de quel comportement on cherche à justifier.
Pour ma part, j'ai le sentiment que nous, les libristes, rajoutons un vernis de moralité afin de justifier à nos propres yeux de faire du travail gratuitement, surtout au regard des débats sur la maintenance du logiciel libre (que ça soit les questions de financement, les questions de burn out, etc).
Il me semble que c'est bien parce que le libre n'est pas naturellement aussi perenne que les autres moyens qu'on doit rajouter un impératif d'ordre moral, car sinon, il n'y aurait pas besoin. On peut dire tout le mal du code proprio qu'on veut (et ces critiques sont justifiés), mais le moyen de vivre sa vie avec, dans le système capitaliste actuel, est assez direct à mon plus grand regret.
Avec le recul, on peut voir que la GPL, pierre angulaire du mouvement du libre, ne se focalise que sur les libertés du point de vue de la personne qui est capable de lire et d'écrire le code (vu que 75% des 4 libertés tournent autour de ça).
Et qu'effectivement, le gros de ce que le logiciel libre a produit, c'est surtout des solutions pour l'industrie logicielle, car c'est la que se trouve les compétences qui en tire parti, et le chemin pour le rendre perenne.
Du coup, c'est à mon sens pas super étonnant que le logiciel libre ne libère pas le monde, vu que rien dans ses fondations n'est pensé pour ça, et que les efforts pour changer ça n'ont jamais abouti.
Tout au plus, le logiciel libre serait une brique dans une libération (au sens abstrait), mais c'est aussi un angle qui me parait assez peu discuté. Par exemple, l'article en lien parle de "permacomputing", mais uniquement à la fin et sans faire de lien direct avec le constat mis en avant dans l'article. De même l'article parle des libertariens sans faire le lien avec des discussions sur le sujet (pour un exemple récent, l'affaire KF et Cloudflare, et l'idéologie qui justifie les choix du patron de CF).
[^] # Re: Nitrokey
Posté par Misc (site web personnel) . En réponse au journal Clés de sécurité, pas assez utilisées. Évalué à 8.
J'aurais tendance à me méfier un peu des nitrokeys (et des solokeys), même si je pense que dans la plupart des cas, ce n'est pas un facteur si important.
Une des controverses autour de Yubico est le fait de ne plus publier le code du firmware il y a quelque années. C'est au moment ou la boite a pris une puce d'infineon au lieu de 2 puces de NXP. Et je suppose que la puce d'Infineon vient avec un NDA, d'ou le changement.
Manque de pot, c'est aussi venu avec une faille, mais c'est la vie, y a des bugs dans les logiciels.
Yubico avait publié un article pour expliquer qu'un contrôleur ARM classique n'était pas adapté, et j'ai tendance à être d'accord avec ce point.
Hors, la nitrokey, c'est un simple STM32F103 si j'en croit les schémas sur Github.
Donc du coup, le choix est entre du code qu'on peut auditer soi même sur du matériel avec des soucis potentiels, et du matériel moins problématique avec du code qu'on a pas pu auditer. Il y a un compromis à faire.
Dans la mesure ou j'irais pas auditer le code de Nitrokey moi même (parce que j'ai ni le temps, ni les compétences en crypto), la différence est de savoir si je fait confiance aux gens qui ont fait un audit potentiel.
J'ai tendance à paradoxalement faire confiance à une boite qui a déjà eu un souci de sécu publié, car elle va prendre plus au sérieux les choses qu'une autre ou je ne peut pas savoir si il n'y a rien car tout est parfait, ou parce que personne n'a rien tenté.
Donc à confiance égale, j'aurais tendance à prendre le matériel prévu pour la sécurité.
Ensuite, je pense aussi que les peurs sur une attaque en pratique visant à sortir les clés sont non fondés pour la plupart des usages. Dans la classification de James Mikens, je pense que je suis clairement dans Not-Mossad comme beaucoup de gens dans ce journal.
Et bon, 10 à 20€ de moins par ci par la, ça peut aider. Et nitrokeys fait du libre, collabore avec solokeys, publie des modifs sur odoo, etc, donc c'est une bonne chose de les soutenir.
[^] # Re: Pérénité ?
Posté par Misc (site web personnel) . En réponse au journal Clés de sécurité, pas assez utilisées. Évalué à 5.
C'est surtout qu'il n'y a pas de bon moment pour perdre une clé comme ça.
[^] # Re: J'en ai une, je m'en sers... mais pas assez
Posté par Misc (site web personnel) . En réponse au journal Clés de sécurité, pas assez utilisées. Évalué à 6.
"Amazon EC2 has entered the chat"
Mais c'est bien le seul service ou j'ai ce probléme (et c'est mineur par rapport à ceux ou j'ai que le support d'une appli et pas des clés ). Ensuite, j'ai aussi un nombre réduit de comptes importants et je m'assure aussi d'avoir les codes de secours à portée de main.
Je pense qu'un truc qui aide, c'est de faire régulièrement le tour des comptes qu'on a dans son gestionnaire de mot de passe et soit de fermer les comptes, soit de vérifier qu'on a le 2FA correctement.
[^] # Re: Le prix de la licence
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 9.
Je pense qu'on devrait rester dans le domaine du réel, une grosse boite avec une administration performante, ça n'existe pas.
sans doute que si, mais en général, les boites se fatiguent pas.
Déjà, pourquoi tu voudrais avoir un truc sans support ?
La, c'est 2000€ par an et par coeur pour le support basique, tu payerais sans doute plus en frais d'avocat à vouloir faire des économies.
[^] # Re: noyage de poisson
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 5.
J'ai cru comprendre en lisant en diagonal que c'est pas 3 ans après le commit, mais 3 années après une release qui est dans le fichier de licence (ou 4 ans après une version spécifique).
Ensuite, la licence est vraiment mal fagoté je trouve.
# "Production use"
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 7.
La licence BSL balance "production use" et "non production use" sans vraiment définir le terme.
Car bon, pour un système de CI/CD, l'instance de jenkins et ses tests qui aboutissent au déploiement, c'est un usage en production. Si ton pipeline de déploiement est cassé et que quelqu'un est chargé de réparer ça, pour moi, c'est de la prod (ça produit quelque chose, c'est dans le nom).
Et donc, qui va vouloir faire une bibli qui utilise akka ou se connecte sur akka dans ces conditions alors qu'il y a une incertitude juridique parce que la licence est mal écrite ?
[^] # Re: noyage de poisson
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 7.
Attendre 3 ans avant d'avoir le correctif d'un CVE, c'est sur que la version libre va être utile.
# Facile
Posté par Misc (site web personnel) . En réponse au journal Sobriété, j'écris ton nom. Évalué à 10.
Parce que c'est fait par le presta qui a proposé la presta la moins cher en prenant soit des gens qui sont en cours d'apprentissage (enfin, comme nous tous), ou a qui on a donné juste le temps qu'il faut avant les remettre sur un autre projet.
[^] # Re: Et en même temps…
Posté par Misc (site web personnel) . En réponse au lien EU regulators want 5 years of smartphone parts, much better batteries - OSnews. Évalué à 5.
En même temps, je pense que le pneu ne va pas trop s'user dans l'espace (ou du moins, pas comme sur terre), donc c'est sans doute faisable (sauf si le plan est de construire une autoroute).
[^] # Re: Trackers ?
Posté par Misc (site web personnel) . En réponse au lien Comment rendre les applications moins énergivores ?. Évalué à 2.
En fait, de gagner de l'argent, oui.
Ensuite, on pourrait aussi simplement demander aux devs de baisser leur salaire si on veut réduire l'inflation à ce niveau, mais on me dit que ça serait sans doute pas une mesure populaire.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 2.
Un BIOS corrompu (l'exemple du virus CIH de 1998 me vient en tête), ça serait comme du matos qui tombe en panne, sauf qu'on peut le réparer en reflashant.
Mais on peut imaginer pareil en terme de dégat sur le firmware du disque dur. En fait, c'est pire parce qu'un disque dur corrompu, ça va me coûter plus qu'un BIOS corrompu, vu que je peux changer la carte mère et voila. Sortir les données d'un disque foutu, ça coûte un chouia plus cher.
Et le firmware d'un disque, ça peut s'attaquer
C'est pas le BIOS. L'iLO tourne sur un processeur à part sur une carte à part avec un OS à part (voir quasiment un Linux embarqué).
Je veux bien qu'on compte ça dans le BIOS sous le prétexte que ça vient avec le matériel dans ton serveur, mais ça serait un abus de langage.
Ensuite, si tu parles de la fonctionnalité équivalente pour les proc intel (eg, AMT), ça vient avec le processeur, pas avec le BIOS. Encore une fois, je veux bien qu'on compte tout qui est avant grub comme "le BIOS" mais ça serait toujours un abus de langage.
Est ce que le BIOS est plus sensible que le processeur ?
Je pense que non (et c'est pour ça aussi que je dit que le BIOS n'est pas le plus sensible en terme de sécurité), mais si on dit "le BIOS est le plus sensible en terme de sécurité", alors le processeur l'est moins. Et c'est pas ce que je voit vu le foin autour des procs intels.
Ensuite, si l'affirmation est "le plus sensible en terme de sécurité, c'est le matériel", l'omniprésence de matériel et/ou de firmware non libre me laisse croire que c'est pas si sensible que ça par rapport au logiciel.
Le matos est la, il est en vente, mais pourtant, j'ai pas le sentiment que ça se bouscule pour acheter (vu qu'il n'y a que Leah sur le coup depuis des années).
Je sais pas, je suis pas psychologue, faut aller voir le DSM.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 3.
"pas le plus sensible", ça veut pas dire "on s'en balek".
Ça veut juste dire que dans un classement, c'est pas en haut.
La preuve, pendant des années, on a pas eu de mécanismes simples de mises à jour du BIOS ou de l'UEFI (eg, fwupdate sous Linux), et que je sache, on a pas eu d'apocalypse, et que je voudrais bien dire "le nombre de souci de sécurité lié à un souci dans le BIOS se compte sur les doigts d'une main", mais j'ai rien qui me vient à l'esprit.
À coté de ça, on a eu plus de gens qui ont eu des soucis à cause des certificats et du manque de TLS, on eu plus de souci suite à des soucis de crypto (la faille openssh de debian en 2008), etc.
Ensuite, si tu veux éviter le homebrew sur ton matériel, oui. si tu es Google, Amazon ou Nintendo ou n'importe qui qui veut controler le matériel face à ses users, oui, il te faut un BIOS blindé.
Dans une console de jeux, le BIOS va importer à mort. Mais que je sache, on parle pas de ça ici. Et non seulement on parle pas de ça, mais en plus, si on en parle, on va en parler pour la perte de liberté que ça entraîne (eg, secureboot par défaut sur les trucs ARM, etc).
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 2.
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
[^] # Re: Des oublis
Posté par Misc (site web personnel) . En réponse au lien Self-Hosted email is the hardest it's ever been, but also the easiest.. Évalué à 3.
En fait, je pense pas qu'il y a un arrangement explicite.
Comme dit ailleurs, c'est de l'apprentissage avec du machine learning. Et si en effet, en moyenne, le fournisseur voit que les mails venant de ton range chez Belgacom, c'est surtout des virus et du spam, et qu'il y a 1 personne avec son serveur qui envoie un mail de temps en temps, les maths sont contre elle.
J'ai le même souci avec mon VPN pour l'IP v6. Je me fait régulièrement bloqué (ou je me prends des captchas) parce que je passe par digital ocean pour ça. Si j'avais mis le VPN sur la connexion de chez moi, je suis sur que j'aurais 0 soucis.
[^] # Re: Quid des autres federations ?
Posté par Misc (site web personnel) . En réponse au lien After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. Évalué à 5.
Alors je ne pense pas que c'est le spam qui fait qu'on va chez un gros acteur.
Mais avoir 1 acteur avec 100 000 boites mails , ou 1000 acteurs avec 100 boites mails, ça change la donne.
Déjà, les 1000 acteurs, ça implique (pour simplifier) d'avoir 1 admin par acteur. L'acteur avec 100 000 boites mails, à ressources égales, il va se retrouver avec 1000 admins. Si on suppose que ça ne croit pas de manière linéaire et qu'on peut fire 100 000 boites mails avec 100 admins, alors l'acteur dominant va avoir plus de ressources pour lutter contre le spam (les 900 personnes), et il peut faire des choses que les plus petits ne peuvent pas.
Par exemple, il a une vue sur plus d'opérations, il va recevoir plus de spam et/ou plus vite, ce qui permet de réagir plus vite et donc d’arrêter plus vite, ce qui diminue le nombre de spam par utilisateurs.
En dehors de ses capacités, un acteur dominant a un avantage pour la lutte contre le spam.
Et tu parles d'avoir les informations qui transitent, mais il n'y a rien qui transite à part des DNSBL qui n'ont rien de libre ou d'ouvert.
Les systèmes modernes des GAFAMs se basent sur l'apprentissage statistique de la réputation des serveurs, mais ça ne marche que si tu as beaucoup de mail. Moi, avec mon serveur perso, je vais pas faire grand chose à ce niveau si j'ai 1 mail par jour.
[^] # Re: Quid des autres federations ?
Posté par Misc (site web personnel) . En réponse au lien After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. Évalué à 4. Dernière modification le 05 septembre 2022 à 12:25.
Ce qui pourrait être fait pour les mails aussi, de façon assez trivial en fait.
C'est une des idées proposé par hey.com, et une qui peut se faire chez soi avec un peu de code.
Par exemple, tu envoies tout les mails ailleurs que dans ta inbox, sauf si le mail est dans une liste spécifique. Tu peux ensuite déplacer un email dans un dossier spécial pour déclencher le changement du filtre et le déplacement des emails qui correspondent vers la inbox.
Si c'était la solution, alors quelqu'un d'autre que Hey le proposerait. Mais visiblement, ça ne suffit pas.
# Quid des autres federations ?
Posté par Misc (site web personnel) . En réponse au lien After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. Évalué à 9.
Un point qui me semble revenir rarement est la question des autres fédérations. Par exemple, XMPP, Matrix, et tout ce qui tourne à ActivityPub.
Le protocole SMTP de base a plein de souci. Mais une fois qu'on rajoute DKIM, SPF, etc, le probléme du spam persiste.
Pour le moment, les autres protocoles fédérés sont épargnés en partie parce que relativement personne (à l'échelle de la planète) ne les utilisent pour le moment.
Est ce qu'il ne faut pas se poser la question de se dire ce qui devrait être fait avant qu'on refasse la même chose que l'email ?
Ou est ce qu'il faut juste accepter que c'est inéluctable et que ça vient avec le fait d'avoir du succès, donc du monde, donc des problèmes d'échelle qui entraîne l'ossification du protocole et l’émergence d'acteurs dominants.
[^] # Re: Service de réception de SMS en ligne
Posté par Misc (site web personnel) . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 8.
Ce que tu cherches, c'est pas simplement ça: https://docs.gammu.org/smsd/smsd.html
Avec une carte sim et un modem 4G sur un serveur en USB ?
[^] # Re: Et les zones blanches
Posté par Misc (site web personnel) . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 4.
C'est possible, mais ça ne posait pas de souci avec un autre opérateur (celui d'avant, et celui d’après aussi). Et mes collègues se plaignaient aussi du réseau chez eux (et moi aussi, c'est comme ça que j'ai su pour les femtocells).
C'est con, mais ça aide d'avoir du réseau pour recevoir les alertes nagios.
[^] # Re: Expérience liseuses++
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 5.
Certes mais ce n'était qu'un exemple. Le reste du logiciel est pareil. Prenons par exemple et justement l'action de modifier la barre d'outils.
C'est dans préférence, barre d'outils et de menu. C'est facile à trouver, mais quand on clique sur ça, on arrive sur une fenetre quasiment vide avec une liste déroulante.
Primo, le premier item "cliquer pour choisir la barre d'outils…" est un des choix possibles, alors qu'à mon sens, ça devrait être un label avec un choix par défaut (un clic de moins pour éditer).
Ensuite, choisir les éléments via leur nom, c'est pas exactement l'UX la plus intuitive, surtout quand tu as 2 réglages suivant la présence ou pas d'une liseuse branché, et ça me parait une magouille dans le code pour faire apparaître le bouton d'opération sur la liseuse la ou je pense qu'une bonne pratique, c'est d'avoir un bouton grisé quand rien n'est branché. Pour moi, ça serait comme avoir libreoffice avec 2 choix "document à sauver / document sans modification", pour cacher l’icône de sauvegarde
Ça mentionne une "seconde barre d'outil optionnel", d’où est ce qu'elle vient, quelle sont ses réseaux ? Il y aussi le "menu contextuelle pour la liste de livres divisées", je suppose que c'est le menu qui s'affiche pour clic droit, mais à quel moment (sachant qu'il y a toujours une liste de livre, donc qu'est ce qui est divisé) ?
C'est pas que le logiciel n'est pas utilisable, et j'ai vu largement pire.
Mais tout a un coté baroque.
Mon dernier exemple, quand tu va dans les préférences, tu peux fermer une fenêtre via la croix en haut. Sauf que la croix agit comme "retour arrière", vu que tu reviens à la fenêtre d'avant.
Il y a spécifiquement une surcharge d'un comportement par défaut d'un élément d'interface compris depuis les premiers macs.
Ça me fume un peu. Ensuite, c'est sans doute les séquelles de mes années à faire de l'ergonomie.