🚲 Tanguy Ortolo a écrit 12334 commentaires

Ben oui, beaucoup mieux.

La comparaisons à Windows n'était pas censé évoquer une piètre qualité en général, mais simplement une caractéristique précise assez connue et largement reconnue comme assez mal fichue.

La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.

Ce qui n'a rien d'atomique

En effet, mais ça peut le devenir en s'aidant de fonctionnalités du système de blocs, genre LVM, ou du système de fichiers, genre Btrfs.

C'est sûr que Windows est réputé pour être vachement plus fiable.

Ça y est voilà la mauvaise foi

Bon alors pour rappel, la nécessité de redémarrer pour les mises à jour de Windows vient d'une erreur de conception historique : l'absence de compteur de liens et d'ouvertures sur les fichiers, qui sont par conséquent censés avoir un unique nom qui ne peut pas être supprimé tant qu'un fichier est ouvert.

Sous *nix, un fichier peut avoir un nombre quelconque de noms au sein du système de fichiers qui l'héberge. Un fichier a souvent un seul nom, mais il peut en avoir plusieurs, on parle alors de liens physiques. Il peut aussi avoir zéro nom, lorsque son dernier nom a été supprimé ; pour autant il peut continuer d'exister tant qu'il y a encore un processus qui a un descripteur dessus, qui l'a ouvert quoi.

Cela implique d'avoir, pour chaque fichier, un compteur de liens et d'ouvertures, puisqu'un fichier ne peut être supprimé du système de fichiers que s'il n'a plus aucun nom et n'est plus ouvert par aucun processus.

Le rapport avec les mises à jour, c'est qu'avec des compteurs de liens et d'ouvertures, on peut installer une mise à jour d'un fichier pouet.so avec un nouveau nom, disons pouet.so.new, puis supprimer le nom pouet.so même s'il est ouvert par un logiciel, et enfin renommer pouet.so.new en pouet.so sans affecter les processus en cours.

Ça, c'est infaisable sous Windows, ce qui pose un gros problème pour remplacer des trucs ouverts en utilisation normale du système. Du coup, on diffère les mises à jour au moment où on est sûr qu'il n'y a pas grand chose d'ouvert, au tout début du démarrage je crois.

Par exemple, j'ai l'impression qu'Amazon et consorts gèrent eux-mêmes la nécessité de 2FA. Quand ils ont un doute (nouvelle carte, même carte sur plusieurs comptes, pas de commandes récentes, changement d'adresse, etc), ils t'envoient une demande de 2FA, mais autrement ça passe sans passer par l'interface de la banque pour valider le payement. J'imagine qu'ils prennent sur eux du coup si la transaction s'avère frauduleuse.

Absolument.

Après, c'est subjectif, mais je trouve que les sites d'ID des banques sont toujours très très laids, c'est tout petit, tout moche, on a l'impression d'être sur une procédure de debug réservée aux sites qui n'ont pas justement implémenté un formulaire correct de saisie d'indentifiants bancaires. Donc ça donne vraiment l'impression inverse, que la norme est de gérer la saisie des identifiants, en lien avec un compte client qui se rappelle des vieux paniers, des commandes, des adresses de livraison, etc.

Le côté joli ou pas, c'est sans importance, on parle de sécurité là, pas de décoration intérieure. Mais ça participe effectivement à bien faire entrer dans la tête des gens que pour effectuer un paiement, il est important de ne vérifier que dalle parce qu'on ne peut rien vérifier.

Je ne vois pas le rapport.

Le protocole qu'ils sont censés utiliser est public, soit. Et ? Ça ne garantit pas qu'ils l'utilisent, encore moins qu'ils n'envoient pas des informations essentielles par un canal détourné.

D'autre part, la mise à jour fonctionne par état. En gros c'est comme "git" pour le code d'un projet, la mise à jour est juste un rebase à partir d'une branche spécifique. Le rebase se fait lorsque le système tourne normalement. Le redémarrage ne sert qu'à changer le commit de référence pour exécuter le système. En gros au redémarrage c'est quasiment instantanée, contrairement à Windows où ça prend du temps. Car la partie longue aura été faite quand l'ordinateur est utilisé normalement.

Oui, ça je m'en doutais. Ça vient avec le fait que c'est conçu de façon réfléchie, pas comme Windows qui a évolué sans réflexion initiale pour ce genre de problème.

Avec ce fonctionnement, comme cela a été expliqué, l'avantage c'est que de revenir en arrière est fiable et tout aussi rapide si c'est nécessaire. Cela peut même se faire automatiquement si la machine est incapable de booter entièrement avec le nouvel état du système.

Et ça nécessite vraiment une distinction artificielle entre logiciels de base et logiciels supplémentaires ?

Enfin, oui l'approche de Windows reste théoriquement une bonne approche malgré tout. Des bogues qui arrivent et qui sont difficiles à corriger ou à identifier car on met à jour lorsque que le système tourne, cela arrive même sous Linux. Et si ton système crashe en pleine mise à jour pour X ou Y raisons, les problèmes peuvent vite s'accumuler. Appliquer les mises à jour quand le système est dans un environnement minimaliste réduit ces problèmes, en terme de fiabilité c'est mieux quoiqu'on en pense.

C'est sûr que Windows est réputé pour être vachement plus fiable.

La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.

Ah, parce que ça va avec le concept de système vs applications. Typiquement le genre de truc que je n'ai jamais réussi à comprendre et qui à mon sens ne fait qu'ajouter de la complexité.

S'il y a bien un truc que je trouve super sous Debian et autres, c'est bien le fait que tout, y compris le noyau et la libc, vient de paquets qui se gèrent de la même façon.

Désolé, je ne comprends toujours pas. Es-tu en train de suggérer que les développeurs de Signal ont accès au code source actuel de WhatsApp et pourraient ainsi se rendre compte si Meta y ajoutent de quoi fuiter les clefs par exemple ?

Pour rappel, il n'y a aucune preuve que WhatsApp utilise actuellement ce fameux protocole historiquement utilise pour le chiffrement de bout en bout. Et même en supposant que c'est bien le cas, ce qui repose déjà sur une confiance aveugle, ça ne suffirait pas. Le chiffrement de bout en bout, ça ne sert à rien si c'est chiffré entre un interlocuteur et un MitM, ou si les conversations sont ensuite envoyées à la NSA (chiffrées de bout en bout entre le terminal et la NSA, évidemment).

Je ne sais pas d'où sort cette confiance, mais tout ce que je vois, c'est un éditeur de logiciel qui dit : vous ne pouvez pas vérifier notre code mais vous pouvez juste nous confiance, les communications sont chiffrées de bout en bout. Eh bien, en matière de sécurité, la confiance aveugle ça vaut de la merde, et c'est historiquement prouvé.

Merci pour cette définition, qui mériterait de figurer en haut de l'article.

Pour rappel, “atomique” est l’expression qui tend à remplacer celles d'“immuable” (traduction anglaise d'"immutable") ou "image-based", et qui désigne une façon bien particulière de construire et distribuer un système d’exploitation. Solène Rapenne propose une définition dans un billet de 2023, où elle résume les principes essentiels des systèmes immuables :

• les mises à jour système ne sont pas effectuées sur le système en cours d’utilisation (celui-ci n’est jamais censé changer, d’où le qualificatif d'“immuable”)
• les modifications de paquets sont appliqués au prochain démarrage (mais pas celles des Flatpak par exemple)
• vous pouvez revenir en arrière (roll back) et restaurer le système dans l’état exact où il se trouvait avant une mise à jour

Le dernière point est très intéressant, en revanche, pour les deux premiers, j'ai dû louper le moment où le fonctionnement à la Windows, où il faut redémarrer pour appliquer des mises à jour, avait commencé à être considéré un modèle.

Sérieusement, il y a des gens qui aiment ça, devoir redémarrer pour mettre à jour des logiciels ? Quel intérêt ? Relancer les logiciels concernés, évidemment. Redémarrer l'ordinateur si le logiciel concerné est le noyau, évidemment. Mais redémarrer dans tous les cas, ça ressemble à du masochisme.

C'est pas un argument du vrai écossais, ça? Si on donne des exemples de commerçants qui ne font pas d'iframe, tu peux toujours dire que c'est les "craignos".

La façon propre pour un site, ce n'est pas d'utiliser un iframe, ni de choper toi-même les informations de CB hein. Il existe une troisième voie, la bonne : rediriger, tout simplement.

Les sites spécialisés sur le commerce en ligne ont toujours leur propre interface et ne renvoient sur le site de la banque uniquement pour la validation de la transaction, et jamais pour la saisie du numéro de carte et du code de sécurité.

Et c'est de la merde, qui devrait être interdite. Je sais, rediriger, ça fait une expérience utilisateur moins bonne, mais ce n'est pas une raison, au contraire, c'est juste un caprice de designer, et les designers aux commandes de trucs de sécurités, ça se gère en les contraignant à faire des choses sérieuses.

Je n'ai pas compris, désolé.

Ah non, donner directement les infos de CB au commerçant, ce n'est pratiqué que par les commerçants les plus craignos, genre Amazon. Les sites sérieux envoient sur un intermédiaire. Qui, à son tour, va envoyer sur une page de validation de ta banque.

Toutes ces questions de sécurisation des paiements par CB sont bien amusantes dès qu'on se rend compte d'une faille béante dont tout le monde se moque : les paiements sont autorisés dans une iframe. Ou dans une application native, ça revient au même : l'utilisateur n'a aucune idée de quel est l'intermédiaire de paiement, s'il est fournie, et même si la connexion est sécurisée.

Un site marchand pourrait siphonner ainsi les infos de CB sans que ça se voie. Un phishing invisible en somme.

La règle de base avant de transmettre des informations un peu sensibles, genre numéro de CB, c'est de vérifier l'URL du site. Eh bien dans une iframe ou une application, c'est juste impossible.

Tant que ça n'est pas proprement interdit, ça continuera à me faire bien marrer, ces précautions pour la porte blindée d'un mur en papier.

Et je soutiens : toute procédure ou activité qui exige une appli mobile doit de facto proposer son alternative, sans surcout, sur ordinateur.

Pour quel système d'exploitation ? Windows, MacOS, GNU/Linux (quelle distro ?), FreeBSD ? On s'arrête où ?

Et le smartphone, on sait tous qu'il est pas vraiment à toi.. ou alors t'as pas l'appli de ta banque.

Mon téléphone est à moi, le système d'exploitation dessus est libre, je suis root, et j'utilise le logiciel de la banque. Bon, je lui cache que je suis root, mais rien de plus.

Le texte exact :

En ce qui concerne l’initiation des opérations de paiement électronique visée au paragraphe 1, point b), les États membres veillent à ce que, pour les opérations de paiement électronique à distance, les prestataires de services de paiement appliquent l’authentification forte du client comprenant des éléments qui établissent un lien dynamique entre l’opération, le montant et le bénéficiaire donnés.

Une façon de faire serait que, côté site de paiement, la validation invite à se rendre sur l'appli ou le site de gestion bancaire (au choix), qui afficherait l'opération à valider et demanderait un TOTP (pour le site) ou autre chose (pour l'appli, vu que visiblement pour une appli bancaire, un simple code secret statique est considéré comme suffisant).

Il y a un précédent en fait : la Corée du Sud avec ActiveX sur Internet Explorer.

Ou alors, il y a le TOTP. C'est portable, c'est implémenté sur ordinateur, sur téléphone, sur ce qu'on veut, il n'y a rien à développer, c'est aussi intégrable sans difficulté dans une appli bancaire, du coup c'est certainement moins cher, c'est sûrement pour ça que les banques ne s'y mettent pas.

On peut aussi y imprimer une Vcard sous forme de QR-Code au dos. Et se rendre compte que les fonctionnalités d'import de Vcard sont très, très variables selon les téléphones.

Je sais, ce pensais à ce genre de truc, et à la situation avant ça. Face au risque de fuit de données ou d'espionnage, “rien ne prouve que nous sommes espionnés” n'est pas une attitude raisonnable.

Si on avait une preuve que la NSA a un accès direct aux communications hébergées aux États-Unis…

Pourquoi Pokémon ?

Correction, Whatsapp dit faire du chiffrement de bout en bout. La nuance est de taille.

Que ce soit chiffré, aucun doute, ça peut se vérifier. Que ce soit chiffré avec la clef de ton correspondant, c'est déjà moins vérifiable. Que la clef secrète correspondante n'ait jamais été transmise à Meta et stockée par leurs soins, c'est carrément invérifiable.

La chiffrement de bout en bout, avec un logiciel propriétaire, désolé mais c'est à considérer comme du chiffrement sans garantie aucune.

Ça c'est une pratique à ranger parmi celles qui font le plus de mal à Internet de nos jours. Concrètement, ça signifie, à l'échelle d'une population entière, à aller voir Google et à leur dire : maintenant, l'email, c'est vous.

Bien sûr que ça ne les gêne pas. Ça ne dérange déjà pas la majorité des adultes, qui ont appris depuis des dizaines d'années que les GAFAM faisaient de la merde et qui s'en moquent éperdument.

Alors, des jeunes gens, qui ont encore moins de culture informatique que leurs aînés, vous pensez bien…