Aeris a écrit 444 commentaires

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 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…

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 !

Ce n’est encore une fois pas de la responsabilité des utilisateurs que de faire le taff de mise en conformité qui aurait du être fait par le (au mieux) sous-traitant au sens du RGPD.
Sachant que pour mettre en place un mirroir, il faudrait toujours que celui qui le mette en place soit responsable de traitement avec github en sous-traitant, et que ben t’as toujours pas réglé le problème.

Curl et telnet ont à respecter le RGPD. Ou dit autrement, s’ils n’implémentent pas le minimum viable pour être utilisé légalement en Europe, ils n’ont juste aucun sens.

curl ou telnet ne se mettraient pas à jour en terme de sécurité/fix de CVE ou autres, ils ne seraient juste tout simplement plus utilisables en Europe légalement parlant. Et si un utilisateur s’en sert et se fait trouer, ils seraient AUSSI responsables (quoi qu’indique leur licence).

Le RGPD ne fait pas la différence effectivement. C’est bien delta-chat qui agit en tant que sous-traitant en fournissant un logiciel à des entités qui peuvent être elle-même responsable de traitement (asso, entreprise, particulier hors 2(2)c).

Ce qui ne change strictement rien au RGPD. Typiquement il est même interdit par le RGPD de demander aux utilisateurs de mettre en œuvre des mécanismes de protection au lieu de faire les efforts côté responsable de traitement.
C’est explicite pour les cookies par exemple, « t’as qu’à configurer correctement ton navigateur pour les bloquer » est illégal.

Ben non. La source officielle est sur Github.

Accepter une clé RSA weak t’expose à du downgrade attack parce qu’un attaquant peut forcer le repli vers une suite faillible. C’est donc une faille de sécurité et actuellement c’est de toute façon une violation des lignes directrices de l’ANSSI (pas de PFS = support de données après 2030 = 3072 bits minimum) donc une violation du RGPD.
Tu peux argumenter tant que tu veux, c’est un fait juridique.

Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD, et que c’est même exactement ce traitement qui est visé avec Schrems II, la sanction de Google Analytics (malgré l’anonymisation prouvée derrière par la CNIL), Google Fonts, Cloudflare ou tout CDN ou contenu tiers servi par un site internet (violation de l’obligation de minimisation de données article 5 et 6)…
La connexion chiffrée va ensuite échanger un mot de passe et un nom d’utilisateur qui sera aussi une DCP, même si le tunnel lui-même est chiffré. Données accessibles en clair au service en face donc n’étant PAS anonymisées.
Delta-chat est le moyen utilisé pour cette transmission, la finalité étant elle-même décidé par l’utilisateur. Sauf qu’un responsable de traitement est celui qui définit la finalité OU le moyen et donc delta-chat reste responsable de traitement, éventuellement est même sous-traitant au sens du RGPD si delta-chat est utilisé dans le cadre d’une asso ou d’une entreprise (qui est elle-aussi responsable de traitement pour avoir définit la finalité).

Mais tu ne fais que confirmer que tu n’as strictement aucune idée de ce qu’est le RGPD…

https://gdprhub.eu/index.php?title=LG_M%C3%BCnchen_-_3_O_17493/20
https://gdprhub.eu/index.php?title=IMY_(Sweden)_-_DI-2020-11373
https://gdprhub.eu/index.php?title=CNPD_(Portugal)_-_Delibera%C3%A7%C3%A3o_2021/533

Si puisque tu transmets ton adresse IP à Microsoft.
’fin bon, tu prouves que tu as une culture proche du néant en terme de conformité RGPD…

Github est sous-traitant de delta-chat, delta-chat aurait du signer un DPA avec Microsoft.
Le téléchargement du source sur github (avec delta-chat en responsable de traitement donc et Github en co-responsable de traitement) est un traitement de données soumis à l’article 50 des transferts internationaux de DCP, et une violation de l’arrêt Schrems II de la CJUE.

C’est pas comme si c’était JUSTE UN PEU l’intégralité du rationnel de la CJUE sur Schrems II hein… 😑

Et dans le cas de delta-chat, je ne peux même pas télécharger le soft, j'ai pas les signatures ! Donc je ne vais pas plus loin en fait. Ça n'ira jamais sur mon PC. Encore moins si je suis une boîte/asso (violation RGPD instantanée, défait de suply chain).

Et c'est exactement ce que je dis dans mon blog.
Quitte à comparrer 2 trucs illégaux, je compare ce qui est plus ou moins conforme et je prend le moins pire. Et c'est pas forcément le libre.
Merci de la démo.

Et dans tous les cas, je rigole quand même quand j'entend dire que je dis que sans GAFAM point de salut (ce que je n'ai jamais dit) quand tu me files en exemple un soft libre qui tourne sous Chrome avec le source chez Microsoft hein… (C'est bizarre comme Github et Electron sont partout…)

Donc en fait t'es en train de m'expliquer que le libre c'est bien parce qu'une asso a mirroré un github dans un coin pour avoir accès aux sources sans violer la loi ??
Tu sais que tu ne fais que confirmer ce que je dis dans mon blog hein ?

Je t'invite à lire le RGPD et la définition de traitement de données. Le simple affichage d'une DCP à l'écran est un traitement. Qui a décidé de comment, dont du moyen, afficher les données à l'écran ? Delta-chat.
Définition de responsable de traitement du RGPD ? Entité qui décide les moyens ou finalités d'un traitement.
Delta-chat est responsable de traitement. Delta-chat doit respecter le RGPD.

Et donc un responsable de traitement ou un sous-traitant au sens du RGPD. Merci.

Le RGPD impose la minimisation des données et de la friction utilisateur, par exemple aucun effet négatif entre un utilisateur A et un B gui accepterait le tracking.
Dans tous les cas c'est bien delta-chat (l'équipe) le responsable de traitement et empêche l'accès à son propre soft pour quelqu'un qui voudrait l'utiliser.

Une boîte ou un particulier sensibilisé qui voudrait utiliser le soft ne PEUT PAS. Pas de signature des livrables, défaut de sécurité de la supply chain. Pas d'accès simple aux sources sans passer par une boîte US. La simple visite du site web conduit DÉJÀ à des violations du RGPD.
Un responsable de traitement (asso, boîte, particulier agissant hors 2(2)c) qui installe ce soft, sans vérification possible de l'intégrité donc, déploie un chromo obsolète rempli d'une 30aine de CVE, et commet donc une 20aine de violation lui-même (défaut de sécurité, défaut de sous-traitance, usahe de logiciel obsolète, défaut de contrôle de la supply chain, transfert US, …).

Et on en revient à ce que je dis dans mon article. Le libre devrait m'éviter de faire toutes ces vérifications et contrôles et devrait impliquer un certain gage de qualité. Sauf qu'en pratique ce n'est plus le cas et le taff de vérif à accomplir est au moins aussi important que pour le proprio.
Le proprio a par contre le bon goût, lui, de ne pas tenter par tous les moyens de ne même pas reconnaître qu'il est réellement responsable de traitement (c'est dans le contrat et il te file un DPA).

Techniquement en plus on a vu que ce soft est une merde sécuritaire de toute façon.

Nom mais impose le respect de l'état de l'art en terme de sécurité et donc le suivi des recommandations ANSSI en France, comme encore rappelé par la CNIL dans ses sanctions

J’oubliais quand même aussi : version d’électron embarquée ? 26.6.0
Fin de vie officielle quand ? 20-Fev-2024
Ah… C’est con… Un navigateur qui est en plus complètement déprécié…
C’est prévu quand la prochaine release de delta-chat du coup pour la migration en electron 27 minimum ?

Je peux même pas forker, j’ai pas accès aux sources (github). Même si je forkais, faut que je réécrive tout pour virer Electron/Chrome/Google.

Et donc ton « client mail » est en réalité un navigateur de 161Mo embarquant en dur une libffmpeg pas maintenue par le système en cas de faille de sécurité, pour faire tourner le navigateur de Google et appeler des libs JS de 3 ans d’âge pour négocier des protocoles de sécurité pétés depuis 8 ans, le tout livré depuis un site web avec une privacy policy complètement lunaire, fournissant des tar.gz, deb ou appimage non signés, le tout avec un code source dispo exclusivement sous github en violation de Schrems II, et dont je suppose très fortement que tout ça se torche avec la compilation reproductible et que j’aurais aucun moyen de vérifier ce qu’il y a réellement dans le binaire fourni par le projet ?
Et tu oses venir me demander de me justifier sur la non conformité des projets libres ?????

Mais encore une fois, on a fondé un logiciel libre sur un composant des GAFAM, que personne ne serait certainement capable de me dire quel version de ffmpeg, vulkan et eGL ça embarque, et tout le monde me donne tord depuis hier…
En vrai le soft que tu me demandes d’analyser est juste basé sur le pire navigateur de tout les temps conçus, géré et livré par Google lui-même. Vraiment, on aurait commencé par là, on aurait gagné du temps hein…