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.
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…
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.
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 ?
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…
Excuse-moi d’être proche du burnout quand je passe 1 journée à expliquer des trucs à des gens qui disent que je dis de la merde mais prouve par A+B que j’ai raison, et que quand on me donne un exemple, je défonce littéralement le truc à la fois au niveau organisationnel (forum, source, build et j’en passe), juridique (des PP qui n’ont aucun sens) et technique (libs obsolètes de 3 ans d’âge, protocole crypto déprécié depuis 8 et chaîne de dépendance complètement WTF (ça fout quoi dans les livrables le libffmpeg.so que je ne sais même pas de quelle version il vient ?)) y compris sur de la crypto dont c’est supposé être le point fort de la solution… 😑
Ah oui, toi qui parle crypto, t’es au courant que delta-chat négocies du non PFS avec les serveurs IMAPS et donc que si ton client se fait défoncer par une faille de sécu sur la ligne, c’est AUSSI delta-chat qui est responsable pour ne pas avoir blacklisté ces cipher suite ? Et que ça négocie aussi du DHE pété depuis 2018 avec logjam & cie ? Et que donc idem ?
Et ton comportement est l’archétype même de ce que je dénonce dans mon post. Des réflexions purement « techniques » et que comme « je fais du libre j’ai totem d’immunité », je ne me remet absolument pas en question. Jusqu’au jour où « oups je vais me faire défoncer par mon APD » (ça va, en France y’a de la marge… 😑)
[^] # 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).
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.
[^] # 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).
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).
[^] # 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).
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).
[^] # 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).
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.
[^] # 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).
Ben non. La source officielle est sur Github.
[^] # 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 à 10:48.
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…
[^] # 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).
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
[^] # 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).
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… 😑
[^] # 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 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).
[^] # 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). Dernière modification le 21 février 2024 à 09:41.
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.
[^] # 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).
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…)
[^] # 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).
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 ?
[^] # 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).
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.
[^] # 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 un responsable de traitement ou un sous-traitant au sens du RGPD. Merci.
[^] # 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). Dernière modification le 21 février 2024 à 09:27.
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.
[^] # 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).
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
[^] # 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).
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 ?
[^] # 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).
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.
[^] # 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 (+3/-2).
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 ?????
[^] # 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).
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…
[^] # 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). Dernière modification le 21 février 2024 à 00:41.
Aller on continue… Bon ben c’est basé sur Electron hein. Donc Chrome…
Bon ben hein…
378082 access("/usr/share/kservices5/searchproviders/google_news.desktop", F_OK) = 0
378082 access("/usr/share/kservices5/searchproviders/google_groups.desktop", R_OK) = 0
378082 access("/home/aeris/.local/share/kservices5/searchproviders/google_groups.desktop", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
378082 access("/home/aeris/.local/share/kservices5/searchproviders/google_groups.desktop", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
378082 access("/usr/share/kservices5/searchproviders/google_groups.desktop", F_OK) = 0
378082 access("/usr/share/mime/application/vnd.google-earth.kmz.xml", R_OK) = 0
378082 access("/usr/share/mime/application/vnd.google-earth.kml+xml.xml", R_OK) = 0
378082 access("/usr/share/mime/text/x-google-video-pointer.xml", R_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", R_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", F_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", F_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", W_OK) = -1 EACCES (Permission non accordée)
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", R_OK) = 0
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", F_OK) = 0
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", F_OK) = 0
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", W_OK) = -1 EACCES (Permission non accordée)
Oui, c’est delta-chat ça… J’en ai 1038 lignes des comme ça si tu veux…
[^] # 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 à 00:27.
Excuse-moi d’être proche du burnout quand je passe 1 journée à expliquer des trucs à des gens qui disent que je dis de la merde mais prouve par A+B que j’ai raison, et que quand on me donne un exemple, je défonce littéralement le truc à la fois au niveau organisationnel (forum, source, build et j’en passe), juridique (des PP qui n’ont aucun sens) et technique (libs obsolètes de 3 ans d’âge, protocole crypto déprécié depuis 8 et chaîne de dépendance complètement WTF (ça fout quoi dans les livrables le libffmpeg.so que je ne sais même pas de quelle version il vient ?)) y compris sur de la crypto dont c’est supposé être le point fort de la solution… 😑
[^] # 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 (+2/-3). Dernière modification le 21 février 2024 à 00:08.
Je te met une étoile devant tout ce qui est déprécié et actuellement négocié par delta chat
LA MOITIÉ des cipher suite négociées sont dépréciées par l’ANSSI depuis 8 ans au moins !!!!
[^] # 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, toi qui parle crypto, t’es au courant que delta-chat négocies du non PFS avec les serveurs IMAPS et donc que si ton client se fait défoncer par une faille de sécu sur la ligne, c’est AUSSI delta-chat qui est responsable pour ne pas avoir blacklisté ces cipher suite ? Et que ça négocie aussi du DHE pété depuis 2018 avec logjam & cie ? Et que donc idem ?
[^] # 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 ton comportement est l’archétype même de ce que je dénonce dans mon post. Des réflexions purement « techniques » et que comme « je fais du libre j’ai totem d’immunité », je ne me remet absolument pas en question. Jusqu’au jour où « oups je vais me faire défoncer par mon APD » (ça va, en France y’a de la marge… 😑)