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.
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 ?
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).
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.
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.
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é.
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.
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.
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.
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.
Le problème de l’arrondi dans le bancaire n’est pas qu’il se fasse, mais qu’il se fasse toujours dans le même sens, occasionnant à long terme une perte ou un gain « important » pour le créditeur ou le débiteur.
Par exemple sur une facturation mensuel de calcul de la TVA, si tu arrondis toujours 10.222€ à 10.22€, tu vas perdre 24 centimes au bout de 10 ans de paiement. Tu aurais plus intérêt à arrondir à 10.22€ certains mois et à 10.23€ d’autre, pour éviter les dérives.
Le fait d’être en virgule flottante ajoute aussi l’erreur (indétectable) de perte de précision lors de la conversion, alors qu’en virgule fixe, tu peux détecter qu’un arrondi s’est produit et réagir en conséquence.
C’est pour ça que des langages comme COBOL sont très présents encore aujourd’hui dans le secteur bancaire, parce que sa gestion des arrondis et des débordements ainsi que le fait qu’il soit en calcul à virgule fixe et non flottante permet un suivi plus propre de ces dérives sur le long terme.
En même temps, vu la complexité astronomique nécessaire pour accéder aux infos d’un serveur distant, ça ne devrait pas prendre longtemps pour coder un truc propre et empaquetable :)
Et donc c’est tout sauf gratuit en terme de perfs… Et certainement pas l’outil magique.
Surtout que du bit rot, en pratique, je ne suis pas sûr d’en avoir rencontrer une seule fois dans ma vie…
Les disques du commerce grand public sont garanti à 1014 octets pour 1 erreur de bit, soit 12To avant de voir la moindre erreur. Les disques professionnelles sont à 1015 (120To). Et d’ailleurs ce chiffre concerne les HDD, les SDD ont une durée de vie plus faible.
J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.
Oui, et aucun article n’explique comment fait btrfs pour corriger une erreur de bit rot, sachant qu’il n’y a pas de sur-redondance de données (seulement 2 strips) et uniquement 1 bloc de parité (donc indécidable si c’est le bloc de parité qui s’est pris le bitrot ou un strip de data).
Tout le monde est d’accord pour dire que ça détecte le bitrot (comme tout système raid). Nul part je ne vois que ça le corrige (sauf raid5 minimum où un consensensus est possible), sinon via un retour arrière via l’historique COW (qui risque alors soit de corrompre le fichier si le rollback est au niveau bloc, soit avec pertes de données s’il est au niveau fichier).
Si j'ai une donnée corrompue, je peux récupérer la donnée avec l'autre disque du RAID1.
Sauf que comme je l’ai dis, on ne sait PAS corriger une erreur avec RAID1. on ne peut que détecter une erreur, on ne sait pas quelle donnée est la bonne. Ça ne protège donc pas d’un bitrot, ça permet uniquement de le détecter et de dégager une des grappes au pif pour pouvoir laisser la prod continuer à tourner en attendant une resynchro.
Il faut du RAID5 pour savoir corriger l’erreur une fois détecter, via la comparaison avec les 2 disques fonctionnels qui disent la même chose alors que le disque défectueux dit une connerie.
Un snapshot read-only, il faut quand même se lever de bonne heure pour arriver à l'effacer par erreur ou via un logiciel. Même avec un "rm *" en root tu n'y arrives pas. Le seul cas que l'on peut envisager c'est une erreur dans le kernel.
Je ne sais pas ce que tu entends par corruption de données/disques ?
Un secteur défectueux. Un dd à la con qui te ruine ta table des partitions.
Parce que j'ai plusieurs fois répété que pour les corruptions type « bit rot », j'étais protégé par Btrfs RAID1.
Et bien reli bien les docs, ce n’est pas le cas. Pas en RAID1.
Cela ne signifie pas du tout que j'utilise mon RAID1 comme backup ! Cela signifie juste que cela me protège contre les données corrompues (bit rot par exemple).
Un RAID1 cela ne protège certainement pas contre les "rm -rf" ou "dd /dev/sd0" (i.e. les erreurs utilisateurs).
La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Ça ne protège pas plus d’un bitrot justement.
Le controlleur RAID détectera une incohérence, ne sera pas capable de déterminer qui des 2 strips a raison et éjectera un des 2 côtés sans aucune semonce.
C’est RAID5 minimum qui permet de corriger le bitrot en regardant le consensus des grappes. RAID1 ne permet que de le détecter et ne permet aucune action corrective (sinon à la hache en dégageant une grappe).
Et ça ne fait pas ce que tu dis.
C’est effectivement COW, ce qui veut dire qu’en cas de corruption, les données PRÉCÉDENTES vont être dispos.
Si ton fichier est dans sa 1ère version et que tu te prends un bitrot, t’es cramé, il n’y a pas plus d’historique.
Et même dans le cas où tu as des données plus ancienne, tu ne sais pas revenir à l’état intègre de la version « bitrotée ». Ça continuera à te donner un fichier final corrompu d’ailleurs si le FS ne rollback qu’un bloc et non tous les blocs de ton fichier (et dans ce cas tu perds encore plus de données).
Faut pas croire que c’est magique les FS hein. Même ceux « next-gen ».
Tu n'as pas cherché à comprendre mon explication qui démontre qu'un fichier corrompu (sur ton disque dur d'origine) n'est pas forcément détecté par ton système et peut par la suite remplacer tes sauvegardes.
Je ne vois pas ce que ça vient faire là.
Et tu as le même problème sur ton truc local hein.
Un fichier corrompu non détecté merdera ad vitam éternam partout. En local, online, offline, offloadé. C’est pour ça qu’il est important de tester régulièrement ses backups.
gestion de versions et sauvegarde de données me semble très similaire
Similaires techniquement peut-être, mais dans leurs usages pas du tout.
Comme déjà dis, un backup ne suppose pas que ton système soit opérationnel pour pouvoir faire une restauration. Ta copie locale si.
C'est ta propre définition de la notion de sauvegarde, Wikipedia (en particulier la définition anglaise) donne une autre vision (que je partage, mais c'est mon avis).
« Backups have two distinct purposes. The primary purpose is to recover data after its loss, be it by data deletion or corruption. »
La page anglaise dit la même chose que moi : un backup suppose la perte complète du système principal. its loss, ce n’est pas its corruption. Tes données ne sont plus là, et considérées comme non réparables depuis le système principal.
« The secondary purpose of backups is to recover data from an earlier time »
La possibilité de restauration d’un backup après la perte de données implique un retour en arrière. Ton système local ne couvre que le 2nd usage (« retourner en arrière »), pas le 1er (« récupérer une perte de données »).
J’aurais tendance à dire que ta solution locale est de l’archivage, et non de la sauvegarde.
D’ailleurs, je trouve le dernier article assez clair au niveau des définitions :
« Je veux pouvoir récupérer mes données en cas d’évènements majeurs altérant leur accessibilité » ⇒ sauvegarde (côté « everything is doomed »)
« Je veux m’assurer de pouvoir récupérer mes données sur le long terme à tout instant » ⇒ archivage (côté « something fucked »)
« Je veux pouvoir accéder à mes fichiers où que je sois, et les partager avec mes collègues » ⇒ stockage (côté « the world is cool »)
| Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
C’est là que je ne te suis absolument pas…
Tu fous quoi en RAID1 si tu n’as pas confiance en tes disques ? :s
C’est du RAID5 minimum qu’il te faudrait du coup, puisque qu’un disque qui pète sur du RAID1 peut entraîner la perte de la grappe complète si c’est le mauvais disque qui est sorti de la grappe en 1er (déjà vécu plusieurs fois)…
| La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi.
N’appelle pas ça sauvegarde alors.
| Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Et c’est typiquement ces cas-là où une sauvegarde (donc offline ou a minima sur disque physique séparé) est utile.
Tes trucs locaux ont une probabilité plus que non nulle d’être AUSSI impacté en cas d’erreur humaine ou logicielle ou d’une corruption de données/disques.
Elles sont physiquement trop proches des données « live » pour pouvoir dire l’inverse.
| ZFS & Btrfs checksum les données, en cas d'utilisation d'un RAID (1/5/6), la version corrompue est automatiquement réparer.
Je veux bien un papier sur le sujet, parce que je ne vois pas comment c’est possible, en tout cas sur RAID1.
Si ZFS|Btrfs se rend compte d’une incohérence de données entre le checksum et les données remontées par le disque, ils n’ont aucun moyen de corriger l’erreur puisqu’ils ne peuvent pas savoir quelle erreur a réellement été commise entre
la data D1 du disque 1 est corrompue
la data D2 du disque 2 est corrompue
le checksum C1 du disque 1 est corrompu
le checksum C2 du disque 2 est corrompu
Après tu peux faire des heuristiques à la con pour chercher à corriger (si D1≠D2 on vérifie si D1 ou D2 match C1=C2, ou encore si C1≠C2, on garde le C qui matche D1=D2), mais il reste plein de trous dans la raquête (D1≠D2 et aucun C qui match, C1≠C2 et pas de D qui match, C1≠C2 & D1≠D2, etc) et tu peux empirer encore plus la situation en choisissant une mauvaise heuristique.
C’est tout le problème du RAID1 : dès qu’un truc pète (hors erreurs matos), il est préférable de dégager un disque au pif que de chercher à corriger les erreurs.
Et c’est aussi pour ça que RAID1, c’est pour moi uniquement une question de résilience et certainement pas de robustesse. Ça permet de conserver une infra physique fonctionnelle en cas de corruption, à quelques glitches près sur les zones éventuellement erronées qu’on restorera depuis les backups si nécessaires une fois le matos changé.
Si tu veux de la résilience (pas de down) et de la robustesse (pas de perte), tu passes sur du RAID5.
Je disais que dire qu'une sauvegarde « locale » est complètement inutile par rapport à une sauvegarde « distante » c'est comme dire qu'un dépôt « local » est complètement inutile par rapport à un dépôt « distant ». C'est ton avis extrême que je critiquais.
Avoir une copie locale a effectivement de l’intérêt (c’est même pour ça qu’a été inventé DSCM). Mais ce n’est pas une sauvegarde (en tout cas pas du point de vue « admin sys »). Faudrait trouver un autre terme.
Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ?
Ben c’est toi qui mentionne RAID1 comme la solution qui te protège hein…
La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Faux. Il ne lutte pas contre la corruption de données/bit rot. À la moindre erreur, c’est toute ta grappe qui peut partir (et partira en dans le cas du RAID1) en sucette. Et pour le cas du RAID1, tu peux même ne pas savoir du tout quel disque contient la donnée incorrecte et lequel la données correcte (problème indécidable avec seulement 2 disques).
RAID n’apporte que de la résilience, et rien d’autre. Ça permet éventuellement d’éviter un arrêt de prod le temps de remplacer le disque.
Si justement. Tu peux avoir un disque dur qui rend l'âme silencieusement sans rien montrer dans le SMART ou dans le syslog.
Ça n’est pas génant dans le cas des backups offline/offloadés.
Tu le détecteras lors de la synchronisation que le disque est fucked. Et du coup tu pourras changer de disque pour tes nouvelles rotations et basta.
La probabilité qu’un disque OK au moment de la synchro (et donc d’un test de restauration :P) devient KO 1 semaine/1 mois après alors qu’il n’a même pas été utilisé entre les 2 est quand même vachement faible… (Et d’abord on n’a jamais dis non plus qu’un backup est infaillible, et que c’est facilement gérable avec du multi-disk.)
J'ai un peu l'impression que tu te braques sur certains mots-clés après avoir lu en diagonal sans chercher à comprendre ce que je cherchais à exprimer ?
Quelqu'un d'autre peut confirmer si je me suis bien exprimé ou bien c'est à moi de m'exprimer plus clairement ?
Tu viens ici en disant que copie online/DSCM/cow/btrfs/raid/whatever est un système de backup. C’est même le sujet de ton journal : « Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ? ».
La réponse est non et sera invariable.
Une sauvegarde doit permettre de revenir à un état cohérent et utilisable passé, en faisant un minimum d’hypothèses sur la procédure à suivre et sur l’état courant du système (en particulier, on doit supposer le système d’origine inutilisable au moment de la restauration).
En particulier, un backup est un système qui devrait te permettre une restauration de service même si l’ensemble de ton système d’origine a disparu de la surface de la planète.
Ou dit encore autrement, la seule hypothèse de restauration doit être la possession d’un backup (sachant que ton système lui, doit être considéré 100% KO).
Une copie online/DSCM/cow/btrfs/raid/whatever ne répond qu’à peu voire aucune des propriétés de ce que doit être une sauvegarde (en particulier nécessite un système disponible et l’outil de backup fonctionnel au moment de la restauration).
Appelle ça comme tu veux (« cache », « snapshot », « dumb-user-proof », « fast-rewind »…) mais pas « sauvegarde ».
# Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 10.
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 Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 10.
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 Aeris (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 Aeris (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 Aeris (site web personnel) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 4.
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 Aeris (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 Aeris (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 Aeris (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 Aeris (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 septembre 2017 à 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 Aeris (site web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 4.
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 Aeris (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 Aeris (site web personnel) . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
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 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.
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 Aeris (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.
# Cumul des arrondis
Posté par Aeris (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 4.
Le problème de l’arrondi dans le bancaire n’est pas qu’il se fasse, mais qu’il se fasse toujours dans le même sens, occasionnant à long terme une perte ou un gain « important » pour le créditeur ou le débiteur.
Par exemple sur une facturation mensuel de calcul de la TVA, si tu arrondis toujours 10.222€ à 10.22€, tu vas perdre 24 centimes au bout de 10 ans de paiement. Tu aurais plus intérêt à arrondir à 10.22€ certains mois et à 10.23€ d’autre, pour éviter les dérives.
Le fait d’être en virgule flottante ajoute aussi l’erreur (indétectable) de perte de précision lors de la conversion, alors qu’en virgule fixe, tu peux détecter qu’un arrondi s’est produit et réagir en conséquence.
C’est pour ça que des langages comme COBOL sont très présents encore aujourd’hui dans le secteur bancaire, parce que sa gestion des arrondis et des débordements ainsi que le fait qu’il soit en calcul à virgule fixe et non flottante permet un suivi plus propre de ces dérives sur le long terme.
[^] # Re: Tests fragiles
Posté par Aeris (site web personnel) . En réponse à la dépêche OpenSSH : configuration des algorithmes de cryptographie. Évalué à 1.
Pour Cryptcheck, c’est plus un problème de scheduler qu’autre chose.
C’est 100% compatible toute version de OpenSSL et toute configuration :D
[^] # Re: Test offline
Posté par Aeris (site web personnel) . En réponse à la dépêche OpenSSH : configuration des algorithmes de cryptographie. Évalué à 2.
En même temps, vu la complexité astronomique nécessaire pour accéder aux infos d’un serveur distant, ça ne devrait pas prendre longtemps pour coder un truc propre et empaquetable :)
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à -1.
Et donc c’est tout sauf gratuit en terme de perfs… Et certainement pas l’outil magique.
Surtout que du bit rot, en pratique, je ne suis pas sûr d’en avoir rencontrer une seule fois dans ma vie…
Les disques du commerce grand public sont garanti à 1014 octets pour 1 erreur de bit, soit 12To avant de voir la moindre erreur. Les disques professionnelles sont à 1015 (120To). Et d’ailleurs ce chiffre concerne les HDD, les SDD ont une durée de vie plus faible.
C’est d’ailleurs confirmé par des études empiriques chez Microsoft : https://www.microsoft.com/en-us/research/publication/empirical-measurements-of-disk-failure-rates-and-error-rates/?from=http://research.microsoft.com/pubs/64599/tr-2005-166.pdf
Et enfin, ils préviennent aussi que quand un truc disjoncte, d’autres trucs disjonctent en même temps pas très loin :
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 2. Dernière modification le 18 juin 2017 à 02:41.
J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
Oui, et aucun article n’explique comment fait btrfs pour corriger une erreur de bit rot, sachant qu’il n’y a pas de sur-redondance de données (seulement 2 strips) et uniquement 1 bloc de parité (donc indécidable si c’est le bloc de parité qui s’est pris le bitrot ou un strip de data).
Tout le monde est d’accord pour dire que ça détecte le bitrot (comme tout système raid). Nul part je ne vois que ça le corrige (sauf raid5 minimum où un consensensus est possible), sinon via un retour arrière via l’historique COW (qui risque alors soit de corrompre le fichier si le rollback est au niveau bloc, soit avec pertes de données s’il est au niveau fichier).
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à -2.
Sauf que comme je l’ai dis, on ne sait PAS corriger une erreur avec RAID1. on ne peut que détecter une erreur, on ne sait pas quelle donnée est la bonne. Ça ne protège donc pas d’un bitrot, ça permet uniquement de le détecter et de dégager une des grappes au pif pour pouvoir laisser la prod continuer à tourner en attendant une resynchro.
Il faut du RAID5 pour savoir corriger l’erreur une fois détecter, via la comparaison avec les 2 disques fonctionnels qui disent la même chose alors que le disque défectueux dit une connerie.
Un secteur défectueux. Un dd à la con qui te ruine ta table des partitions.
Et bien reli bien les docs, ce n’est pas le cas. Pas en RAID1.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0. Dernière modification le 18 juin 2017 à 02:06.
Ça ne protège pas plus d’un bitrot justement.
Le controlleur RAID détectera une incohérence, ne sera pas capable de déterminer qui des 2 strips a raison et éjectera un des 2 côtés sans aucune semonce.
C’est RAID5 minimum qui permet de corriger le bitrot en regardant le consensus des grappes. RAID1 ne permet que de le détecter et ne permet aucune action corrective (sinon à la hache en dégageant une grappe).
Et ça ne fait pas ce que tu dis.
C’est effectivement COW, ce qui veut dire qu’en cas de corruption, les données PRÉCÉDENTES vont être dispos.
Si ton fichier est dans sa 1ère version et que tu te prends un bitrot, t’es cramé, il n’y a pas plus d’historique.
Et même dans le cas où tu as des données plus ancienne, tu ne sais pas revenir à l’état intègre de la version « bitrotée ». Ça continuera à te donner un fichier final corrompu d’ailleurs si le FS ne rollback qu’un bloc et non tous les blocs de ton fichier (et dans ce cas tu perds encore plus de données).
Faut pas croire que c’est magique les FS hein. Même ceux « next-gen ».
Je ne vois pas ce que ça vient faire là.
Et tu as le même problème sur ton truc local hein.
Un fichier corrompu non détecté merdera ad vitam éternam partout. En local, online, offline, offloadé. C’est pour ça qu’il est important de tester régulièrement ses backups.
Similaires techniquement peut-être, mais dans leurs usages pas du tout.
Comme déjà dis, un backup ne suppose pas que ton système soit opérationnel pour pouvoir faire une restauration. Ta copie locale si.
« Backups have two distinct purposes. The primary purpose is to recover data after its loss, be it by data deletion or corruption. »
La page anglaise dit la même chose que moi : un backup suppose la perte complète du système principal. its loss, ce n’est pas its corruption. Tes données ne sont plus là, et considérées comme non réparables depuis le système principal.
« The secondary purpose of backups is to recover data from an earlier time »
La possibilité de restauration d’un backup après la perte de données implique un retour en arrière. Ton système local ne couvre que le 2nd usage (« retourner en arrière »), pas le 1er (« récupérer une perte de données »).
https://www.appvizer.fr/magazine/services-informatiques/sauvegarde/sauvegarde-archivage-stockage-quelles-differences-1443109474
http://blog.watsoft.net/actualite-watsoft/difference-entre-larchivage-et-la-sauvegarde-dun-serveur-de-messagerie/
http://www.gestion-documents.fr/archivage-vs-sauvegarde/
https://blog.netexplorer.fr/stocker-archiver-sauvegarder-differences/
J’aurais tendance à dire que ta solution locale est de l’archivage, et non de la sauvegarde.
D’ailleurs, je trouve le dernier article assez clair au niveau des définitions :
« Je veux pouvoir récupérer mes données en cas d’évènements majeurs altérant leur accessibilité » ⇒ sauvegarde (côté « everything is doomed »)
« Je veux m’assurer de pouvoir récupérer mes données sur le long terme à tout instant » ⇒ archivage (côté « something fucked »)
« Je veux pouvoir accéder à mes fichiers où que je sois, et les partager avec mes collègues » ⇒ stockage (côté « the world is cool »)
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
| Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
C’est là que je ne te suis absolument pas…
Tu fous quoi en RAID1 si tu n’as pas confiance en tes disques ? :s
C’est du RAID5 minimum qu’il te faudrait du coup, puisque qu’un disque qui pète sur du RAID1 peut entraîner la perte de la grappe complète si c’est le mauvais disque qui est sorti de la grappe en 1er (déjà vécu plusieurs fois)…
| La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi.
N’appelle pas ça sauvegarde alors.
| Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Et c’est typiquement ces cas-là où une sauvegarde (donc offline ou a minima sur disque physique séparé) est utile.
Tes trucs locaux ont une probabilité plus que non nulle d’être AUSSI impacté en cas d’erreur humaine ou logicielle ou d’une corruption de données/disques.
Elles sont physiquement trop proches des données « live » pour pouvoir dire l’inverse.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à -1.
| ZFS & Btrfs checksum les données, en cas d'utilisation d'un RAID (1/5/6), la version corrompue est automatiquement réparer.
Je veux bien un papier sur le sujet, parce que je ne vois pas comment c’est possible, en tout cas sur RAID1.
Si ZFS|Btrfs se rend compte d’une incohérence de données entre le checksum et les données remontées par le disque, ils n’ont aucun moyen de corriger l’erreur puisqu’ils ne peuvent pas savoir quelle erreur a réellement été commise entre
Après tu peux faire des heuristiques à la con pour chercher à corriger (si D1≠D2 on vérifie si D1 ou D2 match C1=C2, ou encore si C1≠C2, on garde le C qui matche D1=D2), mais il reste plein de trous dans la raquête (D1≠D2 et aucun C qui match, C1≠C2 et pas de D qui match, C1≠C2 & D1≠D2, etc) et tu peux empirer encore plus la situation en choisissant une mauvaise heuristique.
C’est tout le problème du RAID1 : dès qu’un truc pète (hors erreurs matos), il est préférable de dégager un disque au pif que de chercher à corriger les erreurs.
Et c’est aussi pour ça que RAID1, c’est pour moi uniquement une question de résilience et certainement pas de robustesse. Ça permet de conserver une infra physique fonctionnelle en cas de corruption, à quelques glitches près sur les zones éventuellement erronées qu’on restorera depuis les backups si nécessaires une fois le matos changé.
Si tu veux de la résilience (pas de down) et de la robustesse (pas de perte), tu passes sur du RAID5.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
Avoir une copie locale a effectivement de l’intérêt (c’est même pour ça qu’a été inventé DSCM). Mais ce n’est pas une sauvegarde (en tout cas pas du point de vue « admin sys »). Faudrait trouver un autre terme.
Ben c’est toi qui mentionne RAID1 comme la solution qui te protège hein…
Faux. Il ne lutte pas contre la corruption de données/bit rot. À la moindre erreur, c’est toute ta grappe qui peut partir (et partira en dans le cas du RAID1) en sucette. Et pour le cas du RAID1, tu peux même ne pas savoir du tout quel disque contient la donnée incorrecte et lequel la données correcte (problème indécidable avec seulement 2 disques).
RAID n’apporte que de la résilience, et rien d’autre. Ça permet éventuellement d’éviter un arrêt de prod le temps de remplacer le disque.
Ça n’est pas génant dans le cas des backups offline/offloadés.
Tu le détecteras lors de la synchronisation que le disque est fucked. Et du coup tu pourras changer de disque pour tes nouvelles rotations et basta.
La probabilité qu’un disque OK au moment de la synchro (et donc d’un test de restauration :P) devient KO 1 semaine/1 mois après alors qu’il n’a même pas été utilisé entre les 2 est quand même vachement faible… (Et d’abord on n’a jamais dis non plus qu’un backup est infaillible, et que c’est facilement gérable avec du multi-disk.)
Tu viens ici en disant que copie online/DSCM/cow/btrfs/raid/whatever est un système de backup. C’est même le sujet de ton journal : « Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ? ».
La réponse est non et sera invariable.
Une sauvegarde doit permettre de revenir à un état cohérent et utilisable passé, en faisant un minimum d’hypothèses sur la procédure à suivre et sur l’état courant du système (en particulier, on doit supposer le système d’origine inutilisable au moment de la restauration).
En particulier, un backup est un système qui devrait te permettre une restauration de service même si l’ensemble de ton système d’origine a disparu de la surface de la planète.
Ou dit encore autrement, la seule hypothèse de restauration doit être la possession d’un backup (sachant que ton système lui, doit être considéré 100% KO).
Une copie online/DSCM/cow/btrfs/raid/whatever ne répond qu’à peu voire aucune des propriétés de ce que doit être une sauvegarde (en particulier nécessite un système disponible et l’outil de backup fonctionnel au moment de la restauration).
Appelle ça comme tu veux (« cache », « snapshot », « dumb-user-proof », « fast-rewind »…) mais pas « sauvegarde ».
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
J’ajouterai même mieux :
Un DSCM permet de remonter à tout instant T sous réserve que le dépôt soit encore opérationnel à l’instant T+X
Un backup assure que s’il était opérationnel à l’instant T, il est restaurable et fonctionnel à l’instant T+X
Un DSCM est un « rewind-backup », alors qu’un backup est un « forward-backup ».