Je peux tout à fait construire un scalpel, une lampe de bloc opératoire, un lit électrique et même l'ordinateur qui piloterait tout ça. J'en ai le droit et même dans mon salon
Mais tu dois alors annoncer partout que ce truc n’est qu’un jouet, pas qualifié pour de vraies opérations, sans aucune certification médicale et que ce n’est pas utilisable en production, avec tous les warning obligatoires sur le sujet (comme par exemple la mention « ce produit n’est pas un dispositif médical »).
D’autant plus quand tu présentes ça comme la future révolution de ton domaine, que tu as fondé une boîte pour concevoir, développer et opérer ça et que tu en maintiens 2 instances en production pour de vrai.
Mastodon est l’équivalent de Sorin qui lancerait un nouveau pacemaker avec 0 certification, où il manque des gros bouts ne serait-ce que pour pouvoir envisager de lancer la certification, en ferait la promotion sur l’ensemble de ses sites internet et en aurait déjà implantés 2-3 en vrai sur des vrais patients et en maintiendrait même la liste officielle d’implantation réussie en dehors de tout process légal. Et sans jamais dire officiellement ni même officieusement ni même rien du tout « Mais surtout faites pas ça les gens ! » à ces hôpitaux qui se mettent à communiquer d’avoir aussi implanter des patients avec cette merde.
Ah oui et sur la portée, la limite de 45 millions n’est que pour la définition de gatekeeper. Qui ont des exigences renforcées.
Pour les autres, et en tout cas depuis le 17 février dernier, il y a quand même des obligations aussi, en particulier de célérité, de processus (appel neutre, etc) et de transparence de la modération à mettre en œuvre pour tout le monde.
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Et tu remarqueras aussi que c’est justement marqué « occupe » et non « emploi », et que c’est « 50 personnes ET moins de 10 millions » et non pas « 50 personnes OU moins de 10 millions ».
Il y a bien plus de 50 personnes occupées sur Mastodon, en comptant les développeurs (1889 dans le github), les modérateurs, les administrateurs d’instance, et j’en passe.
La 1ère clause du nombre de personne tombant, le DSA s’applique. Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
Il y a énormément de métier que tu ne peux pas faire à la maison sur ton temps libre malgré que ça soit techniquement possible, sauf à passer des certifications préalables et des tets de compétences avant de pouvoir être autonomes.
Pourquoi encore une fois le libre ou le logiciel en général devrait magiquement ne pas faire éventuellement comme les autres ?
Oui développer est un métier qui ne nécessite pas que des compétences techniques mais aussi des compétences légales ou autre.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
Et j'ai aucun problème à ce que curl dise « je m'en fous du RGPD «. Tu m'excuseras simplement de ne pas pleurer s'il ne remporte pas d.appel d'offre, et de ne plus l'utiliser moi-même.
Et à la limite peu importe de la responsabilité juridique ou pas de curl : livrer un soft pas conforme RGPD pour toute entité utilisatrice soumise au RGPD, ça serait… con.
Comme Mastodon qui dev un soft en pratique inutilisable en Europe… 🤔
Et donc si curl et cie sont prévus pour être dans un environnement sans DCP, c'est hors RGPD, mais si ça traite (et la simple transmission est un traitement), alors curl doit répondre aux exigences du RGPD, sécurité, supply chain, DPA, gestion de l'obsolescence par une entité compétente, audit…
Et donc si curl livre des trucs pas patchés ou incompatible, il s'exclut possiblement de lui même de tout appel d'offre type HdH oui.
Si tu déploies un tel logiciel tu dois effectivement dire que ce n'est qu'un poc, qu'il n'est pas utilisable en l'état et n'est pas habilité à traiter de la donnée perso.
Effectivement. Tu ne peux à aucun moment dire qu'il est utilisable et toute personne est supposée le savoir (le RGPD s'applique aussi aux particuliers, surtout pour une boîte mail généralement mélangeant pro et perso.
Tout logiciel livré doit de toute façon faire l'objet d'un DPA avec l'entité utilisatrice, ne serait-ce que pour garantir les maj, les alertes de sécu, les 36h légaux de notification en cas de faille, et toutes les autres exigences de l'article 28 qui doivent être contractualisées.
Si ça n'a aucun but et qu'au final en plus ici-même on me répond « de toute façon t'as pas besoin du source », faut qu'on m'explique encore une fois l'intérêt…
Je pourrais aussi signaler qu'un code source dispo sur github n'est du coup pas acccessible. Cette plate-forme est illégale en Europe et donc je ne peux ni voir le source ni contribuer.
Utiliser github viole manifestement au moins une des 4 libertés.
Sauf que quand on vient m’expliquer qu’on peut faire sans Github mais que 90% (chiffre au pif mais certainement proche de la réalité) des projets libres sont sous Github et exclusivement sous Github, je rigole.
La procédure donnée par delta-chat ne vérifie rien en pratique. Donc les devs eux-même ne savent même pas comment permettre la vérification. Sauf en se reposant sur f-droid (ils ont signé un DPA avec F-Droid comme sous-traitant/co-responsable de traitement d’ailleurs ?)
Ce n'est pas mis en avant sur la page de Delta-Chat, mais une personne qui compilerait le logiciel serait au delà de l'utilisateur basique et donc on peut compter sur sa capacité à faire une recherche sur software héritage, et le quelifier d'accès simple.
On ne parle pas de compiler le logiciel mais de faire l’audit bi-annuel obligatoire pour tout usage d’un logiciel tiers pour vérifier sa compliance norme ANSSI et supply chain.
L'utilisateur lambda ayant besoin d'un binaire déjà préparé, il n'a pas besoin des sources, il n'a pas besoin de github.
Une asso ou entreprise ou particulier non soumis à 2(2)c (avocat, médecin, usage pro quelconque mélangé à son usage perso dans sa boîte mail…) ne peut pas juste prendre un binaire random sur le net. C’est juste ça que tu ne comprends pas du tout.
Je pense que les gens qui installent directement depuis le .deb fourni ne sont pas si nombreux, ce n'est pas le moyen d'accès privilégié pour ce genre de logiciel : c'est le gestionnaire de paquet de ta distrib.
Ce n’est mentionné nul part dans la doc de delta-chat. Encore une fois c’est une faute de conformité RGPD. delta-chat ne devrait LÉGALEMENT PAS fournit de moyen d’installation non sécurisé et vérifiée.
Et à la limite on peut prendre le problème dans l’autre sens : je suis une entreprise/association qui souhaite utiliser delta-chat. Peu importe la relation contractuelle entre moi et delta-chat.
Je dois assurer la sécurité informatique de ma chaîne logicielle et n’utiliser que des outils répondant aux exigences « état de l’art » de l’ANSSI et contrôler ma supply chain, comme rappelé par la CNIL dans ses sanctions.
Je tombe sur un soft qui ne fournit pas de signature d’intégrité, embarque un navigateur obsolète contenant 30 CVE, me contraint dans tous les cas à ouvrir un compte sur Github (Microsoft) pour pouvoir ne serait-ce que remonter les issues. Je ne peux même pas aller constater les violations vu que pour ça faut que j’aille sur github. Ou faut que je me prenne le chou à trouver le moyen d’avoir un accès aux sources. Et qu’il me faut des notions en crypto pour m’apercevoir que la procédure de vérification d’intégrité proposée pour les APK est du flanc qui ne fait strictement rien.
Juste je passe mon chemin. Je ne vais pas passer 3h à chercher un truc quand en faisant 3 clics sur Google j’ai un contrat de DPA les rendant co-responsables de traitement légalement avec moi et que si jamais j’ai des emmerdes j’ai quelqu’un qui va être responsable avec moi, plutôt qu’un truc qui va me dire « démerde-toi tout seul t’avais qu’à forker c’est pas ma merde ».
Et c’est ça que le libre n’arrive pas du tout à adresser. Pire, cf la discussion ici, il NE VEUT PAS le faire.
Un défaut de sécurité, c'est le quotidien de tout producteur de logiciel, le RGPD ne dit pas que tu ne dois jamais avoir de faille, sinon ce serait impossible de distribuer le moindre bout de soft.
Je n’ai jamais dis ça. J’ai dis que tu devais mettre en œuvre les préconisations de l’état de l’art du secteur, en l’occurence celle de l’ANSSI, et que delta-chat ne respectait au moins pas les prérequis sur TLS (pas de PFS, DHE actif, moins de 3070 bits alors que PFS pas garanti).
Ce n'est pas parce que Delta Chat héberge ses sources chez Github que Github devient co/sous-traitant du logiciel au sens de cette règlementation.
Delta-chat agit en responsable de traitement au moins vis-à-vis de ses propres développeurs/contributeurs/whatever, et donc Github est sous-traitant de l’entité développant le logiciel delta-chat. Dans tous les cas.
Et l’utilisateur, en particulier association ou entreprise, ayant le RGPD à respecter donc, agit en tant que responsable de traitement, et delta-chat est son propre sous-traitant (au mieux, responsable de traitement conjoint, au pire).
Delta-chat ne respectant pas la réglementation en vigueur, et à la limite qu’il soit responsable ou pas ne change pas le problème, ne remplit pas les objectifs obligatoires pour utiliser ce logiciel (défaut de sécurisation, défaut de supply-chain, violation de Schrems II pour audit du code ou contribution) et delta-chat ne peut donc PAS être utilisé en Europe par qui que ce soit qui est soumis au RGPD.
Un responsable de traitement souhaitant mettre en œuvre l’article 28 du RGPD sur l’encadrement de la sous-traitance ne pourrait pas établir delta-chat comme sous-traitant conforme.
Delta-chat développe donc au mieux (s’il n’est pas responsable de traitement ni sous-traitant) un logiciel inutilisable légalement en Europe, au pire sera requalifié sous-traitant (ou pire du pire responsable de traitement) violant le RGPD et endosserait aussi la responsabilité d’une non conformité.
Aucune entreprise en Europe n’est en capacité légale de pouvoir utiliser delta-chat sauf à violer encore plus le RGPD. Les manquements que j’ai identifié sont suffisant à ne pas pouvoir mettre en place ne serait-ce qu’un acte de sous-traitance avec delta-chat par une entité soumise au RGPD.
Ben comme dit, du coup tu te retrouves avec 2 trucs qui violent la loi.
Si le libre ne l’avait pas violer, j’aurais pu éventuellement dire que je m’en foutais des fonctionnalités différentes entre A (conforme) et B (pas conforme), j’ai que A comme choix viable et donc on s’arrête-là, c’est A qui gagne. Pas parce que c’est libre, mais parce que c’est conforme. Et je m’en cogne que ça soit libre du coup, ça ne m’apporte rien de plus : si c’est A qui est conforme et proprio et que B est non conforme mais libre, je ne PEUX PAS choisir B quelque soit ses avantages autres.
Et quand j’ai A (libre et pas conforme) et B (proprio et pas conforme), avant d’aller me battre pour les éventuelles fonctionnalités, je vais devoir d’abord sélectionner celui qui viole le moins la loi… Et c’est pas forcément A…
Si je dois violer 1 seule fois Schrems II en allant que chez Microsoft, ça sera toujours mieux que de le violer 4× via Google, Microsoft, AWS et Cloudflare.
Si je viole Schrems II en allant chez Microsoft, j’évite aussi de violer encore plus la loi avec une absence de SIEM/IAM/firewall/cloisonnement/interface privée d’admin en plus. 1 violation côté MS, 5 côté pas MS.
Etc.
Et que quitte à devoir dépendre de Microsoft pour Github, de Google pour Electron, de AWS pour npm.js et de Cloudflare pour crate.io, j’irais dépendre uniquement de Microsoft tout court, avec un vrai contrat formalisé et pas des « non mais t’as qu’à faire toi-même et de toute façon NO WARRANTY qu’on a dit ».
Et actuellement, on n’a PAS de solutions libres qui passent le 1er pré-filtre de la conformité. Donc on ne peut même pas commencer à parler de ce qui vient derrière, on en est juste au stade juridique et on fait le choix du moins pire au niveau légal. Pas technique. Pas éthique. Pas morale. Légal.
Et c’est là que vous déformez mes propos. Je n’ai jamais dis qu’on ne pouvait pas faire sans les GAFAM. On peut le faire. Je développe mes softs sur MA forge git, je release sur MES serveurs, je fournis des signatures sur TOUS mes livrables, même un pov’ article de blog (https://blog.imirhil.fr/2014/04/28/gpgit-chiffrez-courriel-entrant.html#installation, oui c’était en 2014 et y’avait pas encore ni Microsoft ni Schrems II pour Github), je fais gaffe à tenir à jour mes dépendances. Je fais des projets en minimisant mes dépendances.
Je dis juste qu’aujourd’hui la plupart des projets, y compris libres, livre de la merde en barre, du docker only electronisé google à mort pour faire l’équivalent d’un dd (je blague même pas, balena est l’équivalent de DD en interface graphique et pèse 133Mo parce qu’il embarque un navigateur complet, discourse n’est plus livré/supporté hors docker, etc), s’en cogne complètement de la conformité (même quand on veut y participer), tout le monde a foncé sur go qui n’est même plus fonctionnel le jour où github tombe et alors même qu’au début du monde le truc faisait des git-clone-main pour sa gestion de dépendances, etc…
C’est du coup pas qu’on ne peut pas faire sans les GAFAM, c’est que les projets libres font tout pour pousser les utilisateurs à y courir !
Le libre est supposé être le modèle d’exemple mais il n’est même pas capable de faire un truc aussi simple que « héberger sa propre forge logicielle sans dépendre de Microsoft et impose à tout contributeur un compte github chez Microsoft »…
monter/trouver un miroir de github pour virer Microsoft pour auditer le code (violation Schrems II)
passer un doctorat en crypto pour comprendre que la vérification de signature préconisé ne fait rien du tout (défaut de sécurité et de contrôle de la supply chain)
devoir corriger des CVE en migrant sur une version décente de Electron (défaut de sécurité et défaut de suivi obsolescence logicielle)
devoir en fait tout recoder pour virer Electron carrément et donc Google
J’ai pas encore testé, mais je suppose que va aussi :
me falloir monter un miroir de npm.js pour virer Cloudflare (violation Schrems II)
me falloir monter un miroir de crate.io pour virer AWS (violation Schrems II)
$ apksigner verify com.b44t.messenger_6774.apk &>/dev/null && echo OK || echo KO
OK
$ echo "\n" >> com.b44t.messenger_6774.apk
$ apksigner verify com.b44t.messenger_6774.apk &>/dev/null && echo OK || echo KO
KO
Mais du coup je suppose que c’est encore à moi d’aller faire l’effort de leur expliquer la crypto ? 🙄
Donc en gros on a des gus suffisamment crétin pour rédiger une procédure de vérification d’un APK sans même s’être posé la question de si c’était bien une vérification de signature et pas juste lister un des certificats dispo dans l’APK.
Là comme ça il est assez facile de refaire un APK verrolé qui vérifie exactement la procédure que delta-chat indique, il suffit d’inclure le certificat de fdroid sur un APK signé par un autre certificat.
La procédure de vérification donnée ne vérifiant que la présence du certificat et non la validité de la signature, ça passerait crème pour tous les utilisateurs qui suivraient la procédure officielle de delta-chat…
Et ces gens envisagent de développer un soft basé sur la crypto… 🙄
Et encore, la commande filée pour vérifier l’archive est invalide
Pour imprimer les empreintes SHA256 du certificat de signature de l’APK vous pouvez utiliser, par ex. keytool -list -printcert -jarfile <APK-file>
aeris> keytool -list -printcert -jarfile com.b44t.messenger_6774.apk
erreur keytool : java.lang.Exception: Une seule commande est autorisée : -list et -printcert ont été spécifiées.
Ben j’ai juste pas de paquet signé hein…
Celui présenté sur le site de delta-chat ne possède aucune signature GPG ou même de checksum. Que ça soit pour le .deb, le app image, les sources ou n’importe quoi sur le site. Le seul truc éventuellement signé est l’APK android.
Tout le reste est livré sans aucune signature.
Et pourquoi est-ce que ça serait à moi d’installer Tor, de trouver Software Archive, ou de faire un mirroir de Github, quand ça pourrait être juste delta-chat qui n’utiliserait tout simplement pas Github tout court ?
Surtout quand on prétend ici-même qu’on sait faire sans les GAFAM hein !
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2 (+1/-4).
Mais tu dois alors annoncer partout que ce truc n’est qu’un jouet, pas qualifié pour de vraies opérations, sans aucune certification médicale et que ce n’est pas utilisable en production, avec tous les warning obligatoires sur le sujet (comme par exemple la mention « ce produit n’est pas un dispositif médical »).
D’autant plus quand tu présentes ça comme la future révolution de ton domaine, que tu as fondé une boîte pour concevoir, développer et opérer ça et que tu en maintiens 2 instances en production pour de vrai.
Mastodon est l’équivalent de Sorin qui lancerait un nouveau pacemaker avec 0 certification, où il manque des gros bouts ne serait-ce que pour pouvoir envisager de lancer la certification, en ferait la promotion sur l’ensemble de ses sites internet et en aurait déjà implantés 2-3 en vrai sur des vrais patients et en maintiendrait même la liste officielle d’implantation réussie en dehors de tout process légal. Et sans jamais dire officiellement ni même officieusement ni même rien du tout « Mais surtout faites pas ça les gens ! » à ces hôpitaux qui se mettent à communiquer d’avoir aussi implanter des patients avec cette merde.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2 (+1/-4).
Ah oui et sur la portée, la limite de 45 millions n’est que pour la définition de gatekeeper. Qui ont des exigences renforcées.
Pour les autres, et en tout cas depuis le 17 février dernier, il y a quand même des obligations aussi, en particulier de célérité, de processus (appel neutre, etc) et de transparence de la modération à mettre en œuvre pour tout le monde.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+1/-3).
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Et tu remarqueras aussi que c’est justement marqué « occupe » et non « emploi », et que c’est « 50 personnes ET moins de 10 millions » et non pas « 50 personnes OU moins de 10 millions ».
Il y a bien plus de 50 personnes occupées sur Mastodon, en comptant les développeurs (1889 dans le github), les modérateurs, les administrateurs d’instance, et j’en passe.
La 1ère clause du nombre de personne tombant, le DSA s’applique. Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3 (+0/-4).
Il y a énormément de métier que tu ne peux pas faire à la maison sur ton temps libre malgré que ça soit techniquement possible, sauf à passer des certifications préalables et des tets de compétences avant de pouvoir être autonomes.
Pourquoi encore une fois le libre ou le logiciel en général devrait magiquement ne pas faire éventuellement comme les autres ?
Oui développer est un métier qui ne nécessite pas que des compétences techniques mais aussi des compétences légales ou autre.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 0 (+0/-1).
Il me semble que ça a été corrigé depuis, mais Tchap avait été livré sans aucune réflexion en amont… 1h15 après sa publication, il était déjà pété : https://www.lepoint.fr/high-tech-internet/tchap-il-m-a-suffi-de-1-h-15-pour-trouver-la-faille-de-securite-06-05-2019-2311048_47.php
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+0/-2).
Et j'ai aucun problème à ce que curl dise « je m'en fous du RGPD «. Tu m'excuseras simplement de ne pas pleurer s'il ne remporte pas d.appel d'offre, et de ne plus l'utiliser moi-même.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3 (+0/-4). Dernière modification le 21 février 2024 à 19:40.
Et à la limite peu importe de la responsabilité juridique ou pas de curl : livrer un soft pas conforme RGPD pour toute entité utilisatrice soumise au RGPD, ça serait… con.
Comme Mastodon qui dev un soft en pratique inutilisable en Europe… 🤔
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+0/-2).
Et donc si curl et cie sont prévus pour être dans un environnement sans DCP, c'est hors RGPD, mais si ça traite (et la simple transmission est un traitement), alors curl doit répondre aux exigences du RGPD, sécurité, supply chain, DPA, gestion de l'obsolescence par une entité compétente, audit…
Et donc si curl livre des trucs pas patchés ou incompatible, il s'exclut possiblement de lui même de tout appel d'offre type HdH oui.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2 (+0/-3). Dernière modification le 21 février 2024 à 19:35.
C'ert surtout que c'est marqué « ainsi que » dans le texte cité…
C'est tout traitement auto de DCP ou tout traitement non auto d'un fichier de DCP. Fichier étant au sens général (un post-it est un fichier).
Curl et cie c'est le 1.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+1/-3).
Si tu déploies un tel logiciel tu dois effectivement dire que ce n'est qu'un poc, qu'il n'est pas utilisable en l'état et n'est pas habilité à traiter de la donnée perso.
Effectivement. Tu ne peux à aucun moment dire qu'il est utilisable et toute personne est supposée le savoir (le RGPD s'applique aussi aux particuliers, surtout pour une boîte mail généralement mélangeant pro et perso.
Tout logiciel livré doit de toute façon faire l'objet d'un DPA avec l'entité utilisatrice, ne serait-ce que pour garantir les maj, les alertes de sécu, les 36h légaux de notification en cas de faille, et toutes les autres exigences de l'article 28 qui doivent être contractualisées.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+0/-2).
Si ça n'a aucun but et qu'au final en plus ici-même on me répond « de toute façon t'as pas besoin du source », faut qu'on m'explique encore une fois l'intérêt…
Je pourrais aussi signaler qu'un code source dispo sur github n'est du coup pas acccessible. Cette plate-forme est illégale en Europe et donc je ne peux ni voir le source ni contribuer.
Utiliser github viole manifestement au moins une des 4 libertés.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+0/-2).
Sauf que quand on vient m’expliquer qu’on peut faire sans Github mais que 90% (chiffre au pif mais certainement proche de la réalité) des projets libres sont sous Github et exclusivement sous Github, je rigole.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 0 (+0/-1).
La procédure donnée par delta-chat ne vérifie rien en pratique. Donc les devs eux-même ne savent même pas comment permettre la vérification. Sauf en se reposant sur f-droid (ils ont signé un DPA avec F-Droid comme sous-traitant/co-responsable de traitement d’ailleurs ?)
On ne parle pas de compiler le logiciel mais de faire l’audit bi-annuel obligatoire pour tout usage d’un logiciel tiers pour vérifier sa compliance norme ANSSI et supply chain.
Une asso ou entreprise ou particulier non soumis à 2(2)c (avocat, médecin, usage pro quelconque mélangé à son usage perso dans sa boîte mail…) ne peut pas juste prendre un binaire random sur le net. C’est juste ça que tu ne comprends pas du tout.
Ce n’est mentionné nul part dans la doc de delta-chat. Encore une fois c’est une faute de conformité RGPD. delta-chat ne devrait LÉGALEMENT PAS fournit de moyen d’installation non sécurisé et vérifiée.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2 (+1/-4).
Et à la limite on peut prendre le problème dans l’autre sens : je suis une entreprise/association qui souhaite utiliser delta-chat. Peu importe la relation contractuelle entre moi et delta-chat.
Je dois assurer la sécurité informatique de ma chaîne logicielle et n’utiliser que des outils répondant aux exigences « état de l’art » de l’ANSSI et contrôler ma supply chain, comme rappelé par la CNIL dans ses sanctions.
Je tombe sur un soft qui ne fournit pas de signature d’intégrité, embarque un navigateur obsolète contenant 30 CVE, me contraint dans tous les cas à ouvrir un compte sur Github (Microsoft) pour pouvoir ne serait-ce que remonter les issues. Je ne peux même pas aller constater les violations vu que pour ça faut que j’aille sur github. Ou faut que je me prenne le chou à trouver le moyen d’avoir un accès aux sources. Et qu’il me faut des notions en crypto pour m’apercevoir que la procédure de vérification d’intégrité proposée pour les APK est du flanc qui ne fait strictement rien.
Juste je passe mon chemin. Je ne vais pas passer 3h à chercher un truc quand en faisant 3 clics sur Google j’ai un contrat de DPA les rendant co-responsables de traitement légalement avec moi et que si jamais j’ai des emmerdes j’ai quelqu’un qui va être responsable avec moi, plutôt qu’un truc qui va me dire « démerde-toi tout seul t’avais qu’à forker c’est pas ma merde ».
Et c’est ça que le libre n’arrive pas du tout à adresser. Pire, cf la discussion ici, il NE VEUT PAS le faire.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3 (+0/-4).
Je n’ai jamais dis ça. J’ai dis que tu devais mettre en œuvre les préconisations de l’état de l’art du secteur, en l’occurence celle de l’ANSSI, et que delta-chat ne respectait au moins pas les prérequis sur TLS (pas de PFS, DHE actif, moins de 3070 bits alors que PFS pas garanti).
Delta-chat agit en responsable de traitement au moins vis-à-vis de ses propres développeurs/contributeurs/whatever, et donc Github est sous-traitant de l’entité développant le logiciel delta-chat. Dans tous les cas.
Et l’utilisateur, en particulier association ou entreprise, ayant le RGPD à respecter donc, agit en tant que responsable de traitement, et delta-chat est son propre sous-traitant (au mieux, responsable de traitement conjoint, au pire).
Delta-chat ne respectant pas la réglementation en vigueur, et à la limite qu’il soit responsable ou pas ne change pas le problème, ne remplit pas les objectifs obligatoires pour utiliser ce logiciel (défaut de sécurisation, défaut de supply-chain, violation de Schrems II pour audit du code ou contribution) et delta-chat ne peut donc PAS être utilisé en Europe par qui que ce soit qui est soumis au RGPD.
Un responsable de traitement souhaitant mettre en œuvre l’article 28 du RGPD sur l’encadrement de la sous-traitance ne pourrait pas établir delta-chat comme sous-traitant conforme.
Delta-chat développe donc au mieux (s’il n’est pas responsable de traitement ni sous-traitant) un logiciel inutilisable légalement en Europe, au pire sera requalifié sous-traitant (ou pire du pire responsable de traitement) violant le RGPD et endosserait aussi la responsabilité d’une non conformité.
Aucune entreprise en Europe n’est en capacité légale de pouvoir utiliser delta-chat sauf à violer encore plus le RGPD. Les manquements que j’ai identifié sont suffisant à ne pas pouvoir mettre en place ne serait-ce qu’un acte de sous-traitance avec delta-chat par une entité soumise au RGPD.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 1 (+2/-2).
Ben comme dit, du coup tu te retrouves avec 2 trucs qui violent la loi.
Si le libre ne l’avait pas violer, j’aurais pu éventuellement dire que je m’en foutais des fonctionnalités différentes entre A (conforme) et B (pas conforme), j’ai que A comme choix viable et donc on s’arrête-là, c’est A qui gagne. Pas parce que c’est libre, mais parce que c’est conforme. Et je m’en cogne que ça soit libre du coup, ça ne m’apporte rien de plus : si c’est A qui est conforme et proprio et que B est non conforme mais libre, je ne PEUX PAS choisir B quelque soit ses avantages autres.
Et quand j’ai A (libre et pas conforme) et B (proprio et pas conforme), avant d’aller me battre pour les éventuelles fonctionnalités, je vais devoir d’abord sélectionner celui qui viole le moins la loi… Et c’est pas forcément A…
Si je dois violer 1 seule fois Schrems II en allant que chez Microsoft, ça sera toujours mieux que de le violer 4× via Google, Microsoft, AWS et Cloudflare.
Si je viole Schrems II en allant chez Microsoft, j’évite aussi de violer encore plus la loi avec une absence de SIEM/IAM/firewall/cloisonnement/interface privée d’admin en plus. 1 violation côté MS, 5 côté pas MS.
Etc.
Et que quitte à devoir dépendre de Microsoft pour Github, de Google pour Electron, de AWS pour npm.js et de Cloudflare pour crate.io, j’irais dépendre uniquement de Microsoft tout court, avec un vrai contrat formalisé et pas des « non mais t’as qu’à faire toi-même et de toute façon NO WARRANTY qu’on a dit ».
Et actuellement, on n’a PAS de solutions libres qui passent le 1er pré-filtre de la conformité. Donc on ne peut même pas commencer à parler de ce qui vient derrière, on en est juste au stade juridique et on fait le choix du moins pire au niveau légal. Pas technique. Pas éthique. Pas morale. Légal.
Et c’est là que vous déformez mes propos. Je n’ai jamais dis qu’on ne pouvait pas faire sans les GAFAM. On peut le faire. Je développe mes softs sur MA forge git, je release sur MES serveurs, je fournis des signatures sur TOUS mes livrables, même un pov’ article de blog (https://blog.imirhil.fr/2014/04/28/gpgit-chiffrez-courriel-entrant.html#installation, oui c’était en 2014 et y’avait pas encore ni Microsoft ni Schrems II pour Github), je fais gaffe à tenir à jour mes dépendances. Je fais des projets en minimisant mes dépendances.
Je dis juste qu’aujourd’hui la plupart des projets, y compris libres, livre de la merde en barre, du docker only electronisé google à mort pour faire l’équivalent d’un dd (je blague même pas, balena est l’équivalent de DD en interface graphique et pèse 133Mo parce qu’il embarque un navigateur complet, discourse n’est plus livré/supporté hors docker, etc), s’en cogne complètement de la conformité (même quand on veut y participer), tout le monde a foncé sur go qui n’est même plus fonctionnel le jour où github tombe et alors même qu’au début du monde le truc faisait des git-clone-main pour sa gestion de dépendances, etc…
C’est du coup pas qu’on ne peut pas faire sans les GAFAM, c’est que les projets libres font tout pour pousser les utilisateurs à y courir !
Le libre est supposé être le modèle d’exemple mais il n’est même pas capable de faire un truc aussi simple que « héberger sa propre forge logicielle sans dépendre de Microsoft et impose à tout contributeur un compte github chez Microsoft »…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+2/-4).
À ceux qui répondrait que je peux récupérer le code sur le site de delta-chat : l’archive n’est pas signée.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3 (+1/-5).
Donc pour résumer avant d’utiliser delta-chat :
J’ai pas encore testé, mais je suppose que va aussi :
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+0/-2).
Alors que bon, avec apksigner
Mais du coup je suppose que c’est encore à moi d’aller faire l’effort de leur expliquer la crypto ? 🙄
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+0/-2).
D’ailleurs y’a même encore plus simple pour le prouver…
YOLO
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 0 (+1/-2).
Donc en gros on a des gus suffisamment crétin pour rédiger une procédure de vérification d’un APK sans même s’être posé la question de si c’était bien une vérification de signature et pas juste lister un des certificats dispo dans l’APK.
Là comme ça il est assez facile de refaire un APK verrolé qui vérifie exactement la procédure que delta-chat indique, il suffit d’inclure le certificat de fdroid sur un APK signé par un autre certificat.
La procédure de vérification donnée ne vérifiant que la présence du certificat et non la validité de la signature, ça passerait crème pour tous les utilisateurs qui suivraient la procédure officielle de delta-chat…
Et ces gens envisagent de développer un soft basé sur la crypto… 🙄
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+1/-3). Dernière modification le 21 février 2024 à 14:10.
Et la procédure de vérification est inefficace. Ça ne fait qu’afficher le certificat de signature sans procéder réellement à la vérification.
C’est apksigner qu’il faut utiliser et pas keytool. Pour des gus supposés faire de la crypto, ça fait peur…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2 (+0/-3).
Et encore, la commande filée pour vérifier l’archive est invalide
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2 (+0/-3).
Ben j’ai juste pas de paquet signé hein…
Celui présenté sur le site de delta-chat ne possède aucune signature GPG ou même de checksum. Que ça soit pour le .deb, le app image, les sources ou n’importe quoi sur le site. Le seul truc éventuellement signé est l’APK android.
Tout le reste est livré sans aucune signature.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1 (+1/-3).
Et pourquoi est-ce que ça serait à moi d’installer Tor, de trouver Software Archive, ou de faire un mirroir de Github, quand ça pourrait être juste delta-chat qui n’utiliserait tout simplement pas Github tout court ?
Surtout quand on prétend ici-même qu’on sait faire sans les GAFAM hein !