Ça devrait les empêcher d'être utilisés dans pas mal de
systèmes liberticides, mais ce n'est pas suffisant : par
exemple des appareils privateurs (TV, routeur, voiture…)
fabriqués et distribués par des groupes capitalistes incluent
souvent des logiciels sous GPL.
Et du coup, ça serait mieux si c'était sous une licence proprio ?
Parce que j'ai quand même l'impression que ça va financer les boites qui font du proprio, qui vont en faire plus. Il y a sans doute des calculs qui m'échappent.
Quelqu'un a une piste, y a-t-il des travaux sur le sujet (sur
les plans juridiques, stratégiques, techniques) ?
Il y a la liste que j'ai pointé pour les licences. Il y a aussi la salle dédié au FOSDEM. Sinon, suffit d'embaucher des juristes spécialisés, mais c'est cher.
Je vais avancer une hypothèse naïve, libre à vous de la réfuter
avec force, j'en sortirai grandi : j'ai l'impression que ce
n'est un souci que pour les plus grands acteurs, donc que ce
n'est pas un souci.
Alors en fait, c'est pas très compliqué, parce qu'il n'y a pas "les grand acteurs d'un coté" et "le reste de l'autre".
Quand il y a des procès médiatiques autour du libre, ça calme pas mal l'ardeur de certains clients à prendre du libre (cf des discussions que j'ai eu avec les commerciaux au bureau), car il faut pas croire que les commerciaux d'en face se gène pour le dire.
Et pourtant, mon employeur vends justement la tranquillité d'esprit à ce niveau la (que ça soit sur les brevets ou autre souci juridique), donc on pourrais croire que ça serait à notre bénéfice que d'avoir justement plus d'incertitude, mais pas vraiment.
Je pense que personne n'a envie qu'on lui dise "non, on peut pas prendre ton Debian la, remets un NT4 pour le DHCP, on veut pas de procès". Et pourtant, c'était un peu le risque à l'époque.
Il est courament admis que Linux a décollé car les BSDs, à tort ou à raison, était vu comme juridiquement risqué à cause du procès AT&T.
Et c'était avant d'avoir des grands acteurs du libre comme on a maintenant. Donc je suppose que si la situation se reproduit, les effets vont être les mêmes.
Vont-ils pour autant bouder Github et Opencollective, ou
Twitter ou Facebook ?
Nice try, mais ni Twitter, ni Facebook n'ont des ToS contre les projets post-opensource, et leur ToS sont appliqués au petit bonheur la chance par rapport à leur risque à eux.
Github s'en fout, tant que tu leur donne le droit de distribuer, etc. Si ça contredit la licence de ton propre code, bah, tu peux te faire un procès à toi même.
Opencollective aussi n'est pas contre les projets autre que libre, mais c'est via des autres structures (car il y a d'autres hôtes fiscaux). Curieusement, les autres hôtes sont moins cher que l'OSC qui prends 10%. Donc peut être que le business model, c'est de prendre plus pour les logiciels, ce qui explique pourquoi ils regardent pas trop.
Ou peut être que c'est juste un risque, et que les projets en questions vont se trouver sans financement face à un acteur malicieux. Ensuite, c'est leur pognon, je vais pas gérer leur risque.
Comment une telle clause pourrait avoir une chance d'être
opposable dans la vraie vie ?
Un tel clause n'a pas besoin d'être opposable pour de vrai, mais elle va surtout servir de douche froide.
Et dans le cas de Bookwyrm, il est amusant de voir qu'il n'y a pas exactement foule pour aider sur le projet, il y a exactement 1 personne qui bosse dessus depuis 2 ans.
Si je compare par exemple avec Funkwhale, pour rester sur le Fediverse, le projet arrive à avoir une communauté plus grande. Certes, le projet est plus vieux, mais au bout de 3 ans, le projet était déjà bien parti pour que sa codeuse principale puisse en faire son taf à temps plein.
Je vois pas trop ça arriver vu les finances de Bookwyrm. Ensuite, chacun sa stratégie.
Ensuite, oui, c'est vrai que je pourrais parfaitement installer Bookwyrm au taf sans qu'on risque un procès.
Par contre, ce qu'on peut risquer en tant que grande boite(tm), c'est un article dans "The Register" qui va faire jaser sur toute la planète, et rester pour toujours sur Wikipedia. Je pense qu'on a atteint un stade ou les gens qui se souviennent de gcc 2.96 sont parti à la retraite, ça serait dommage de relancer ça pour 20 ans.
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.
[^] # Re: Clauses anticapitalistes, antimilitaires, etc.
Posté par Misc (site web personnel) . En réponse au journal Tout le monde (ou plutôt, trop de gens) semble se foutre des licences en 2022. Évalué à 3.
Et du coup, ça serait mieux si c'était sous une licence proprio ?
Parce que j'ai quand même l'impression que ça va financer les boites qui font du proprio, qui vont en faire plus. Il y a sans doute des calculs qui m'échappent.
Il y a la liste que j'ai pointé pour les licences. Il y a aussi la salle dédié au FOSDEM. Sinon, suffit d'embaucher des juristes spécialisés, mais c'est cher.
[^] # Re: Un souci pour qui ?
Posté par Misc (site web personnel) . En réponse au journal Tout le monde (ou plutôt, trop de gens) semble se foutre des licences en 2022. Évalué à 5.
Alors en fait, c'est pas très compliqué, parce qu'il n'y a pas "les grand acteurs d'un coté" et "le reste de l'autre".
Quand il y a des procès médiatiques autour du libre, ça calme pas mal l'ardeur de certains clients à prendre du libre (cf des discussions que j'ai eu avec les commerciaux au bureau), car il faut pas croire que les commerciaux d'en face se gène pour le dire.
Et pourtant, mon employeur vends justement la tranquillité d'esprit à ce niveau la (que ça soit sur les brevets ou autre souci juridique), donc on pourrais croire que ça serait à notre bénéfice que d'avoir justement plus d'incertitude, mais pas vraiment.
Je pense que personne n'a envie qu'on lui dise "non, on peut pas prendre ton Debian la, remets un NT4 pour le DHCP, on veut pas de procès". Et pourtant, c'était un peu le risque à l'époque.
Il est courament admis que Linux a décollé car les BSDs, à tort ou à raison, était vu comme juridiquement risqué à cause du procès AT&T.
Et c'était avant d'avoir des grands acteurs du libre comme on a maintenant. Donc je suppose que si la situation se reproduit, les effets vont être les mêmes.
Nice try, mais ni Twitter, ni Facebook n'ont des ToS contre les projets post-opensource, et leur ToS sont appliqués au petit bonheur la chance par rapport à leur risque à eux.
Github s'en fout, tant que tu leur donne le droit de distribuer, etc. Si ça contredit la licence de ton propre code, bah, tu peux te faire un procès à toi même.
Opencollective aussi n'est pas contre les projets autre que libre, mais c'est via des autres structures (car il y a d'autres hôtes fiscaux). Curieusement, les autres hôtes sont moins cher que l'OSC qui prends 10%. Donc peut être que le business model, c'est de prendre plus pour les logiciels, ce qui explique pourquoi ils regardent pas trop.
Ou peut être que c'est juste un risque, et que les projets en questions vont se trouver sans financement face à un acteur malicieux. Ensuite, c'est leur pognon, je vais pas gérer leur risque.
Un tel clause n'a pas besoin d'être opposable pour de vrai, mais elle va surtout servir de douche froide.
Et dans le cas de Bookwyrm, il est amusant de voir qu'il n'y a pas exactement foule pour aider sur le projet, il y a exactement 1 personne qui bosse dessus depuis 2 ans.
Si je compare par exemple avec Funkwhale, pour rester sur le Fediverse, le projet arrive à avoir une communauté plus grande. Certes, le projet est plus vieux, mais au bout de 3 ans, le projet était déjà bien parti pour que sa codeuse principale puisse en faire son taf à temps plein.
Je vois pas trop ça arriver vu les finances de Bookwyrm. Ensuite, chacun sa stratégie.
Ensuite, oui, c'est vrai que je pourrais parfaitement installer Bookwyrm au taf sans qu'on risque un procès.
Par contre, ce qu'on peut risquer en tant que grande boite(tm), c'est un article dans "The Register" qui va faire jaser sur toute la planète, et rester pour toujours sur Wikipedia. Je pense qu'on a atteint un stade ou les gens qui se souviennent de gcc 2.96 sont parti à la retraite, ça serait dommage de relancer ça pour 20 ans.
[^] # Re: port 22
Posté par Misc (site web personnel) . En réponse au sondage Quel port ouvert pour le SSH ?. Évalué à 6.
Et changer de port, c'est aussi le risque de se faire bloquer par un parefeu mal luné.
[^] # 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.