Aeris a écrit 272 commentaires

  • [^] # Re: Le RGPD est clair pour ceux qui pensent qu'il est clair ^^

    Posté par  (site Web personnel) . En réponse au journal « votre bulletin de paye électronique ». Évalué à 8. Dernière modification le 06/06/19 à 00:32.

    Ne pas oublier aussi que le consentement n’est QU’UN des moyens légaux opposables à une collecte de données.
    Au pif, on a aussi

    • Exécution d’un contrat / mesures précontractuelles
    • Obligation légale
    • Mission d’intérêt public / autorité publique
    • Sauvegarde des intérêts vitaux
    • Intérêt légitime

    En l’occurrence ici, je vois au moins 2 moyens possibles permettant l’utilisation de ce service sans avoir de consentement à recueillir :

    • Obligation légale
    • + Intérêt légitime

    Décret n° 2016–1762 du 16 décembre 2016 relatif à la dématérialisation des bulletins de paie et à leur accessibilité dans le cadre du compte personnel d’activité
    https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000033625104&categorieLien=id

    L’employeur n’a pas légalement pas besoin de te demander ton avis avant d’utiliser un service de dématérialisation. Il doit uniquement te permettre de t’y opposer, et ceci n’importe quand.
    Une fois un service choisi, il relève du coup de l’intérêt légitime pour l’entreprise d’utiliser ce service.

    J’ajouterais un 2nd « intérêt légitime + obligation légale » puisqu’on est ici dans le cadre professionnel, donc avec une obligation de subordination qui fait qu’un employeur peut t’imposer ce genre d’outils.

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 7. Dernière modification le 12/10/18 à 19:59.

    Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
    Pourtant unattended-upgrades est active par default avec Debian et Gnome: https://wiki.debian.org/UnattendedUpgrades

    Je parlais bien évidemment dans le cas de FlatPak et au point de vue du build de l’image, pas au niveau de l’upgrade côté utilisateur.

    Dans le cas de Debian, les mises-à-jour ne sont justement pas automatiques.
    Un mainteneur intervient manuellement pour mettre à jour son ou ses (quelques) paquets maintenus, s’emmerde à lire les releases notes pour s’assurer que c’est bien ABI compatible avec la dernière version, etc.
    Il pousse ensuite son paquet, et tout le monde en profite dans toutes les applications.

    Il n’est pas noyé sous la tonne de dépendance dont il n’est même pas supposé être le mainteneur, comme c’est le cas de freedesktop qui va devoir se coltiner les releases note aussi diverses et variées que gpg (j’espère qu’ils ont des cryptologues), xorg (et aussi des experts en matos vidéo), nano, ffmpeg, gstreamer, gcc, cmake, zip et j’en passe.
    S’amuser à tester toutes les combinaisons possibles jusqu’à trouver un truc qui tombe en marche capable de builder tout ce petit monde (un libssl 1.2.x pour compiler gnupg 2.2.10, ça passe ou pas ?).
    Pousser leur image… Et devoir notifier tous les mainteneurs des applications du dessus pour les mettre à jour et remonter les problèmes de build éventuels (« coucou, on a mis à jour gcc ! il build toujours ton projet ? »).
    Qui devront rebuilder leur image, pester contre les mainteneurs de freedesktop (stabilité et reproductibilité vous avez dit ?), etc.

    D’ailleurs, rien que de voir actuellement du 1.0.2o en libssl pour freedesktop, ça montre bien le problème…
    La branche 1.0.x est obsolète, même Debian est plus à jour quoi…
    Et il n’y a pas le patch 1.0.2p qui date pourtant de août 2018 et patche une CVE…

    Ou encore gpgme 1.1, quand on en est à la 1.12…

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 3.

    Sinon concernant les tests, la quasi majorités des logiciels libres importants sont aujourd'hui couvert par un nombre de tests suffisamment important pour garantir leur bon fonctionnement dans un environnement donnée

    Les tests vont peut-être exister.
    Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
    Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.

    encore faut-il que les sysadmins se donne la peine de réaliser ces mises à jours compte tenu du risque que cela représente. Quand tu as la possibilité de réaliser ces mises à jours dans une environnement reproductible, tu n'as plus aucune raison pour ne pas les faire étant données que tu as toujours la possibilité de revenir en arrière si dans le pire des cas tu observais un problème après avoir effectué l'upgrade.

    Au contraire.
    Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
    Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.

    D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
    Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.

    Un soft qui tourne parfaitement en glibc peut se tauler magistralement µclibc.
    Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
    Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.

  • [^] # Re: Espace disque partagé...

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 3.

    Tout le monde, toi y compris : Firefox, OpenSSH, libSSL, le kernel Linux etc.
    C'est le propre d'une faille de sécurité : transformer un logiciel bienveillant en un logiciel malveillant.

    Et donc tu arrêtes d’embarquer en dur tes libs ou de te transformer en leur mainteneur.
    Pour justement te mettre à jour le plus vite possible quelque soit l’état d’utilisation des logiciels à la fin.
    Et tu vires immédiatement tout ce qui ne supporte pas la nouvelle versions patchée.

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 1.

    Pour résumer, tu as la reproductibilité pour une image donnée et un contexte d’exécution donné.
    Dès que tu reconstruits l’image en changeant une dépendance, tu ne garanties plus rien (incompatiblité fonctionnelle).
    Dès que tu changes le contexte d’exécution (passage alpine/debian, ou changement de distribution hôte), tu ne garanties plus rien non plus (incompatibilité ABI).

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 1.

    L'isolation des dépendances à au moins l'avantage de permettre la reproductibilité de l’environnement, de pouvoir exécuter des tests dans un environnement contrôlé et rentre tout processus de mise à jour automatisable plus facilement.

    Pour moi c’est justement exactement le contraire.

    L’embarquement des dépendances pose la question de la glibc et du kernel utilisés.
    La compatibilité entre versions y est plutôt bonne mais pas garantie et tu t’exposes à des crashs totalement incompréhensibles d’une machine à l’autre si tu utilises un binaire compilé avec une glibc qui n’est pas celle utilisée par le kernel de ta machine. Cf ici pour le détail du problème de compatibilité.
    La garantie de reproductibilité vient donc de sauter (et encore pire sous Docker avec des trucs type Alpine/µClibc quand le dev a toutes les chances d’utiliser et de tester sous glibc).

    Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
    Peu de monde s’amuse à changer ses fichiers de dépendances pour mettre à jour avec la dernière version connue.
    Généralement, les gens ne rebuildent que sur des changements de version upstream de l’application (et non d’une des dépendances) et ne changent les versions des dépendances que sur une version majeure de l’application (et non d’une dépendance).
    Je ne connais d’ailleurs pas de process de build capable d’aller détecter un changement de dépendances de manière fiable, et encore moins capable de garantir que l’image finale est toujours fonctionnelle avec la nouvelle version. C’est un processus relativement très manuel qui nécessite de revalider l’ensemble de l’applicatif suite à un tel changement, et l’automatisation demanderait des tests d’intégration très couvrants pour ça, ce qu’on a généralement jamais.
    Ton idée de maj auto vient de sauter aussi du coup.

  • [^] # Re: Espace disque partagé...

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 9.

    On est en deux mille dix huit ; 2go c'est que dalle, parce que, comme indiqué ci dessus c'est une seule fois : les applications suivantes utiliseront le même runtime. Au pire si un deuxième runtime est installé les fichiers identiques ne seront pas dupliqués sur le disque. Je préfère perdre 2go que des heures sur des problèmes idiots de dépendance. Mais votre temps est peut être moins précieux que le mien!

    Et c’est exactement avec ce type d’argumentation qu’on en est aujourd’hui…

  • [^] # Re: Espace disque partagé...

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 4.

    Pour Linux, il faut attendre la prochaine version de ta distrib, croiser les doigts et espérer un backport

    Non. Tu te prends par la main, tu codes ton appli pour utiliser les libs couramment utilisées par les plus grosses distrib’ du marché et tu livres un soft potable.

    Les gens se feront un plaisir de packager un logiciel propre.
    Ça prend 40 ans à packager pour beaucoup d’applis parce que les devs font juste n’importe quoi et ne pensent pas à leur release avant.
    Oui, un soft qui embarque la moitié du monde, les packageurs ne vont pas se presser au portillon…

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 2.

    Tu peux faire sans, ce n'est pas une nécessité loin de là, mais affirmer que ça ne sert à rien en prod c'est faux.

    Je n’ai pas dis que ça ne servait à rien en prod, j’ai juste dit que ça apportait tout plein de problème (en particulier de sécurité, cf le problème de la longue traîne des fixes de sécu qui doivent remonter tous les layers) par rapport à d’autres solutions équivalentes si tu veux de la reproductibilité.
    Le rapport avantages/problèmes est en défaveur de Docker (la sécurité pesant devant peser un ÉNORME poids quand on fait un choix technique).

    Cf ça par exemple.
    Ou ça.
    Ou encore ça.

    les 2 sont une démonstration du fait qu'il est tout à fait possible de monitorer du docker entre autre

    Oui, il est possible de monitorer. Avec des blagues dans le système en terme de sécurité.
    Cf ça.

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 6. Dernière modification le 12/10/18 à 10:57.

    A partir du moment ou les dépendances sont proprement déclarées, la plateforme de build peut tracer quels sont les packages qui ont besoin d’être rebuildes, et donc relancer un build automatiquement.
    Sur Snapcraft, ca semble etre fait comme ca (https://forum.snapcraft.io/t/further-automation-of-build-snapcraft-io/2926), et vu que les updates sont automatiques du cote de l'utilisateur, on sait que chaque mise a jour sera rapidement déployé.

    Sauf que ça va à l’encontre complet de ce qu’annonce FlatPak : stabilité et reproductibilité.
    Finit aussi l’argument de « on va faire tourner de vieilles applis comme ça ou des trucs qui dépendent de vieilles bibliothèques ! »

    Si tu veux faire des choses comme ça, ça s’appelle bizarrement apt ou pacman… :)
    Pas besoin de FlatPak encore une fois.

    Ou alors FlatPak est juste en train de faire le taff d’une distribution, et devient une inception avec une distrib dans une distrib…

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 2. Dernière modification le 12/10/18 à 10:11.

    C’est comme dire que Docker sert à rien parce que tu peux utiliser lxc/nsenter/etc. à la main

    Oui et non. Effectivement Docker ne sert à rien (en tout cas en prod) parce que tu peux utiliser LXC & cie, et parce qu’il apporte plus de problèmes qu’il n’en résout (problème du monitoring, mise-à-jour, maîtrise de l’environnement, etc).

    Tout comme FlatPak réinvente la roue en répondant à un non-problème (les applications foireuses quasi inexistantes sous GNU ou dont tu devrais te passer plutôt que de chercher à les faire tourner) via un syndrome du « pas inventé ici » (si tu veux du cloisonnement, AppArmor ou NSJail existent déjà et sont bien moins bloatware que FlatPak) tout en apportant d’autres problèmes encore plus toxiques (duplication des bibliothèques, longue traîne des mises-à-jour, incitation à continuer à ne pas migrer les applications vers les nouvelles versions des dépendances vu qu’on aura FlatPak pour les faire tourner, incitation à continuer à faire de la merde dans les applis en se disant qu’on aura de toute façon FlatPak pour les cloisoner).

  • [^] # Re: Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 0. Dernière modification le 11/10/18 à 23:22.

    Pour installer des trucs vraiment craignos ou qui risquent de t’exploser ton système, tu passes par de la virtualisation ou des chroot quoi… Pas besoin de s’emmerder avec des trucs à la flatpak…
    Et si ça ne s’installe pas sur une distrib standard, c’est peut-être que ça ne devrait pas être installé ni utilisé tout court :D

  • # Dépendances

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 10.

    Les versions obsolètes contenant des failles de sécurité
    Pas de réutilisation des bibliothèques du système (inconvénient, ou avantage…)

    Pour moi, c’est ça le vrai problème de FlatPac, AppImage, Docker, Go et plus ou moins tout ce qui embarque en dur la liste de ses dépendances.

    Ça transforme de facto le mainteneur de l’application en le mainteneur de l’ensemble de ses dépendances.
    À la moindre modification d’une dépendance, pour cause de fix de sécu par exemple, il faut explicitement reconstruire toute la chaîne jusqu’à l’image finale (les overlay chez Docker, les runtime chez FlatPak, etc).

    Ça donne une longue traîne de trucs pas patchés parce que quelqu’un s’est endormi quelque part sur la chaîne.
    Je serais par exemple curieux de connaître le nombre d’images Docker basées sur Alpine qui sont maintenant fixées depuis la grosse CVE de fin septembre.

    Ça incite les gens à ne pas mettre leurs applications à jour et à utiliser des trucs complètement dépréciés au motif qu’avec FlatPak, ça tourne.

    Bref, c’est un joyeux bordel au niveau sécurité.

  • [^] # Re: Espace disque partagé...

    Posté par  (site Web personnel) . En réponse au journal Flatpak. Évalué à 10.

    Dire "la sandbox peut être mal utilisée donc elle sert à rien" me semble un peu fallacieux, il faut juste le temps que les logiciels s'y adaptent et se confinent de mieux en mieux. Au moins on leur donne les moyens de le faire ! Si la sandbox était totalement inflexible, aucun logiciel actuel ne marcherait dedans et l'adoption de la technologie serait nulle…

    La gestion des permissions a été un désastre partout avant, que ça soit les applications Android ou les extensions Firefox. Personne ne lit jamais les permissions, on les accepte sans réfléchir, et les devs doivent viser le maximum d’utilisabilité donc le maximum de permission.
    Typiquement les accès réseaux sont généralement actifs parce qu’une appli qui n’utilise pas Internet en 2018, c’est rare, ou encore l’accès à ~ est nécessaire pour sauvegarder ses documents dans un endroit accessible (bien que FlatPak vise l’utilisation de couche d’abstraction/tunnel pour régler ça.
    Ça risque du coup de se chier encore sur les grôles sur ce sujet à la fin…

    De plus, le besoin de cloisonnement est une solution à un non problème. Qui ici a déjà eu une application malveillante sous GNU ? Quel est du coup l’utilité du cloisonnement ?

  • [^] # Re: TLS over TLS

    Posté par  (site Web personnel) . En réponse au journal Légalité de l'interception du flux SSL au sein d'une entreprise. Évalué à 3.

    Il fingerprintera pas grand chose, sauf à avoir une sonde dédiée SOCKS5…
    Et le contenu qui passe dans le tunnel est chiffré si tu consultes un site en HTTPS. Il y a alors 2 couches de chiffrement, celle du tunnel (que le proxy de ta boîte shootera peut-êter) et celle du site directement (que ta boîte ne pourra pas shooter car elle n’est plus en position de MITM, la négociation étant faite à l’autre bout).

  • # TLS over TLS

    Posté par  (site Web personnel) . En réponse au journal Légalité de l'interception du flux SSL au sein d'une entreprise. Évalué à 7.

    Perso, j’avais développé ça pour shunter le proxy de mon ex-boîte :
    https://github.com/aeris/firewall-piercer

    Ça fait du TLS avec un serveur, qui sert ensuite de proxy SOCKS5 distant.
    Du coup le proxy de la boîte est aveugle.

    Ça nécessite quand même de trouver un port accessible par le proxy (généralement ça filtre assez violamment).

  • [^] # Re: "Le Logiciel Libre fait partie de notre ADN"

    Posté par  (site Web personnel) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 4.

    Je comprend bien le soucis quand c'est plus rapide d'acheter un truc déjà fait,

    C’est en fait bien plus un problème de faisabilité qu’un problème de rapidité.
    Cozy n’a pas vocation à redévelopper un aggrégateur bancaire (comme on n’en a pas à redévelopper un webmail).
    C’est extrêmement chronophage, en particulier la maintenance permanente à assurer pour conserver la compatibilité avec toutes les banques qui changent leurs « API » tous les 4 matins.
    On doit donc forcément passer par un aggrégateur existant. Pour des raisons techniques (scallabilité, intégration…), Kresus n’est pas utilisable de notre côté pour nos offres. On envisage weboob pour les auto-hébergés, mais il y aura aussi un gros boulot d’intégration à faire.

  • [^] # Re: "Le Logiciel Libre fait partie de notre ADN"

    Posté par  (site Web personnel) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 10.

    Quand on dit qu’on fait du proprio, c’est plus un abus de langage qu’autre chose.
    Les bouts non libérés sont uniquement des bouts de gestion interne de notre infra, nos outils de gestion de notre parc, etc.
    N’importe qui souhaitant proposer le même service que nous est en mesure de le faire, il faudra juste qu’il réfléchisse à sa propre infrastructure pour faire tourner tout ça et écrive le code ad-hoc pour sa gestion.

    À l’exception de l’aggrégateur bancaire (dont on espère bien donner un équivalent libre pour les auto-hébergés), toutes les fonctionnalités proposées par Cozy sont libres et accessibles à tous.

  • [^] # Re: et le multi-utilisateurs ?

    Posté par  (site Web personnel) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 4.

    Une seule stack peut gérer plusieurs instances différentes dorénavant oui.

  • [^] # Re: Cozy ?

    Posté par  (site Web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 1.

    Pour le moment, il n’y a rien qui sort du Cozy, donc pas réellement d’aggrégation. Les cas d’usages sont donc plutôt orientés « personne ». On peut envisager des applications cozies qui remontent des données à la demande, mais ce n’est pas le but recherché, justement par soucis de confidentialité et de contrôle de tes données (on cherche plutôt à sortir les données des silos, pas à en créer de nouveaux :P).

    C’est la thèse en cours qui va nous apporter le calcul distribué tout en étant respectueux de ta confidentialité.

  • [^] # Re: Cozy ?

    Posté par  (site Web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 1. Dernière modification le 14/09/17 à 23:57.

    Le problème est qu’actuellement, on ne sait pas réellement faire d’anonymisation.

    Même anonymisées, les données peuvent encore en dire beaucoup sur une personne, via de la corrélation ou des métadonnées.
    Une anonymisation efficace fait aussi trop perdre de sens aux données, qui en deviennent moins voire plus du tout utilisables.
    Pas mal de recherches scientifiques sur le sujet vont dans ce sens : une bonne anonymisation nécessite de ne plus être capable de traiter les données…

    Par exemple pour des données démographiques, il faudrait casser le lien familial entre les individus pour réellement anonymiser le jeu de données (une famille de 7 porte beaucoup d’information par exemple puisqu’est relativement rare), lien qui est pourtant vital pour l’analyse.
    Pour des données médicales, il va falloir supprimer tous les patients à pathologies rares, qui sont pourtant les plus intéressantes statistiquement parlant.

    Traiter les données nécessitera donc, en tout cas à l’heure actuelle, de lever au moins partiellement l’anonymat des utilisateurs…

    C’est pour ça que Cozy considère que rien ne doit sortir du Cozy pour le moment et que tout est calculé localement.

  • [^] # Re: Cozy ?

    Posté par  (site Web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 4.

    On peut avoir des détails sur la thèse ? L’objectif au moins.

    Il y a 2 thèses pour être exact :

    Le but de faire plus ou moins ce que tu cherches à faire. Lancer un calcul distribué sur des données sans que celui qui a demandé le calcul ne puisse avoir accès aux données.

    Ça pose effectivement potentiellement le problème de la vérifiabilité. Au mieux tu peux retenter l’expérience, mais tu ne peux pas vraiment refaire le calcul sur les mêmes données.

  • [^] # Re: Cozy ?

    Posté par  (site Web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.

    Pour la partie calcul sur 1000 personnes, c’est une thèse qui est en cours chez nous en partenariat avec les labos de l’INRIA

    https://www.inria.fr/equipes/petrus

  • [^] # Re: Cozy ?

    Posté par  (site Web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.

    une application peut elle être exécutée depuis un serveur arbitraire et être autorisée à utiliser des données de ton instance de Cozy ?

    Non, l’application s’exécute localement sur ton cozy à toi. Tu peux envisager de remonter le résultat de tes analyses à ton serveur par la suite. À terme on aimerait bien que ça suppose l’acceptation de la part de l’utilisateur (cozy en mode pull uniquement par défaut, pour le push il faut autorisation explicite), mais pas géré pour le moment.

    Il existe un catalogue de formats quelque part ? Ils parlent de tes données de poids dans les pages de présentation, pas trouvé l’exemple.

    Il n’y a actuellement pas d’application permettant de traiter les données de poids, mais on peut déjà facilement crééer un connecteur pour aller récupérer les données des gros silos (fitbit & cie) et les stocker bien à l’abri dans ton cozy, pour ensuite développer des applications pour traiter ces données.

    Le problème de validation des expés (confiance, relecture du code) et de la pub ne semble pas être traîté non plus. Il existe des catalogues d’appli Cozy ?

    C’est en train d’arriver. On en avait un pour notre v2, là le store pour la v3 est en train de sortir.

  • # Cozy ?

    Posté par  (site Web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 3.

    Je dis ça, mais c’est un peu exactement ce que fait Cozy, non ?

    Tu veux faire des traitements sur des données, tu proposes une application Cozy qui va pouvoir utiliser les données de tes utilisateurs, en local sur leur cozy, pour faire ton traitement, sans jamais avoir toi-même directement accès aux données.

    Il y a aussi 1 thèse en cours sur la possibilité de faire la même chose avec du calcul distribué entre tous les cozies, toujours sans accès direct aux données et avec de fortes garanties de confidentialité et d’anonymat.