jeanas a écrit 73 commentaires

« [Albert] sera également mis au service […] de la gestion RH des fonctionnaires. »

Pardon ?

C'est un plaisir de lire une dépêche aussi détaillée, en plus bien écrite.

Je suis bien d'accord que c'est un cauchemar que l'État français officialise que les deux seuls compétiteurs possibles sur le marchés des smartphones soient Google et Apple. Pour les autres inconvénients, je n'en avais pas conscience et ça m'incite à me renseigner, merci pour l'info. En tous cas, je parlais plus du principe général que de l'implémentation particulière.

Personnellement, j'ai toujours trouvé l'application GNOME Software atrocement lente au point de l'avoir tout simplement désinstallée à chaque fois. Je désinstalle aussi le démon packagekitd, qui périodiquement se mettait à faire chauffer l'ordinateur en prenant beaucoup de CPU, et dont je suppose qu'il est à la racine de la lenteur de GNOME Software. J'installe tout en ligne de commande avec dnf et flatpak.

Peut-être qu'on va enfin se mettre à déployer à grande échelle des systèmes de cryptographie asymétrique comme PGP ou S/MIME, en les liant à une vraie vérification d'identité comme l'identité numérique certifiée.

Non, pardon, c'est juste moi qui rêve, là. Les mails vont continuer d'avoir une sécurité nulle et on va continuer les « Bonjour, vous avez été classé premier au concours de maître de conférences en cryptographie et nous vous en félicitons. Afin d'organiser votre recrutement, merci de nous envoyer par mail un scan de votre carte d'identité ainsi que le document ci-joint avec une photo de votre signature »…

Je suis tombé sur celui-ci par hasard : https://xkcd.com/1707/

… qui ressort d'une discussion avec un proche, c'est que ce genre de marketing n'est pas à destination des utilisateurs, mais à destination des investisseurs et de la bourse.

C'est drôle, je n'y avais absolument pas pensé, ce qui prouve bien que je n'y comprends rien au monde de l'entreprise.

https://drewdevault.com/2024/04/09/2024-04-09-FDO-conduct-enforcement.html

Réaction du Fedora project leader : https://discussion.fedoraproject.org/t/f42-change-proposal-fedora-plasma-workstation-system-wide/111343/41

En gros : la proposition a très peu de chances d'aboutir telle quelle. Par contre, il se dit ouvert à des propositions pour rendre KDE plus visible aux côtés de GNOME, sans pour autant changer le fait que GNOME est ce que vont télécharger les gens qui n'y connaissent rien et qui cliquent juste sur le premier lien dans le site de Fedora.

Rassurante : https://discuss.python.org/t/cpython-pypi-and-many-python-packages-are-not-affected-by-the-backdoor-of-xz/49873

https://refi64.dev/posts/dont-boycott-wayland.html démonte un certain nombre d'arguments plus ou moins fallacieux dans ce gist au ton excessivement polémique.

Oui, tu as absolument raison, j'aurais dû le préciser. Il y a quand même un certain nombre de cas où le compilateur ne peut pas déduire que l'indice est dans les bornes, comme quand on stocke des indices dans un tableau à l'intérieur d'un autre tableau, mais ce n'est pas si courant.

Par contre, dans le dernier exemple, j'ai l'erreur suivante:

Tu as oublié l'inversion des lignes selected_share = Some(share); et share_size = share_array.len();. Il faut d'abord finir d'utiliser share_array avant d'en transférer la propriété vers selected_share.

Il faut aussi que je m’intéresse plus à la partie unsafe et au lifetime.

La partie « unsafe » n'est pas utile pour 95% de la programmation en Rust. Mieux vaut réserver ça aux experts du langage qui en ont vraiment besoin et qui savent s'en servir correctement (comme les contributeurs à std), parce que c'est compliqué. Écrire du Rust unsafe correct est bien plus difficile qu'écrire du C correct. Il faut une compréhension fine de la sémantique du langage. Armin Ronacher a écrit un post de blog que je trouve intéressant à ce sujet.

Les lifetimes, par contre, font partie des bases du langage.

Sur la partie lifetime, j'ai beau comprendre à quoi cela sert et comment ça marche en théorie, je ne suis pas encore à l'aise avec. (Quand je parlerai de le deviner automatiquement, je pensais à l’élision qui pour le coup n'est pas vraiment du devinage). Je vais creuser un peu plus cette partie.

Je ne sais pas si ça va t'aider, mais pour ma part j'ai compris comment fonctionne le système quand j'ai réalisé les choses suivantes, que je ne trouve pas très bien expliquées dans la plupart des tutoriels.

D'abord, tout le monde parle du borrow checker et comme c'est magique, mais ce n'est pas le borrow checker qui fait tout. Par exemple, cette fonction ne compile pas : fn<'a>(x: &'a str) -> &'static str { x }. Et heureusement qu'elle ne compile pas, vu qu'on ne peut pas prendre une référence valable seulement pendant une durée déterminée et la transformer impunément en une référence valable pour toute l'exécution du programme ! Mais ce n'est pas le borrow checker qui vérifie ça, c'est juste le système de typage. Tout ce que fait le borrow checker, c'est l'inférence des lifetimes implicites à l'intérieur d'une fonction. Il ne remplace pas le système de typage.

En fait, une bonne façon de comprendre les lifetimes, c'est de les voir comme des types fantômes. On peut imaginer une variante du langage qui aurait de l'héritage entre structs (à la programmation orientée objet), et où les références seraient implémentées comme ceci :

struct Ref<T, U> { // correspond à « &'T U »
  ptr: *U, // le pointeur vers la valeur de type U
  token: T, // un « jeton de validité » de type T
}

Le code

fn convert<'a, 'b: 'a>(x: &'b str) -> &'a str {
  x
}

est traduit en quelque chose comme ceci dans ce langage imaginaire :

fn convert<T, U subtype of T>(x: Ref<U, str>) -> Ref<T, str> {
  let Ref { ptr, token } = x;
  Ref {
    ptr, // ptr est déjà de type *str, pas besoin de conversion
    token as T, // token est du type U, qui est sous-type de T, donc on peut le convertir en T
  }
}

et le code

{ // 'a
  let s = String::from("foo");
  let s_ref = &s; // référence valable pour 'a
  { // 'b
    let s_ref2 = s_ref; // référence valable pour 'b
  }
}

se traduit par

{
  struct ValidityA;

  let s = String::from("foo");
  let s_ref = Ref { ptr: addr_of!(s), token: ValidityA };

  {
    struct ValidityB inherits ValidityA;

    let s_ref2 = convert::<ValidityA, ValidityB>(s_ref);
  }
}

L'héritage entre structs n'existe pas, ma syntaxe struct ValidityB inherits ValidityA est imaginaire, mais tu vois l'idée. (En fait, le sous-typage existe en Rust uniquement à cause des lifetimes.)

Bref, fondamentalement, les lifetimes sont juste des paramètres de type comme les autres. En théorie, rien n'empêcherait que tous les lifetimes soient implémentés via des paramètres de type normaux. Le fait d'avoir une syntaxe différente est surtout une question de lisibilité.

L'idée de Rust est qu'à la compilation, on ne peut pas avoir de problème de concurrence, de fuite mémoire, de segmentation.

Mais en cherchant comment faire certaines opérations sur internet, je me retrouve avec du code contenant le mot unsafe. Je me suis refusé à l'utiliser mais pourquoi faire un langage qui se veut sûr et qui permet de faire des choses unsafe ?

Dans un certain nombre de situations, qu'on le veuille ou pas, il est absolument nécessaire de faire des choses qui ne peuvent pas être vérifiées à la compilation.

Par exemple :

• Appeler une fonction dans une bibliothèque C (i.e., faire de la FFI) Le compilateur ne peut pas vérifier qu'elle est bien appelée ni que l'interaction avec le modèle de gestion mémoire de la bibliothèque est correcte.
• Sauter un bound check (vérification que i est entre 0 et t.len() quand on fait t[i]) dans une boucle appelée des millions de fois, quand on est sûr que l'indice est bien dans les bornes.
• Faire des appels à l'allocateur de mémoire et travailler avec ce qu'il donne, pour implémenter une structure de données.

unsafe est l'une des fonctionnalités les plus intéressantes du langage. Ça permet d'écrire quand même toutes ces choses en Rust, plutôt que dans des langages qui font très peu de vérifications comme le C, et quand on veut auditer la sécurité du code, il suffit de se concentrer sur les blocs unsafe plutôt que de regarder absolument tout. Par ailleurs, il y a des outils pour vérifier à l'exécution que le unsafe ne déclenche pas d'undefined behavior (Miri) et il y a des projets de recherche pour créer des outils de preuve formelle de sûreté de code unsafe (RustBelt).

Sans unsafe, la bibliothèque standard std ne pourrait pas être elle-même écrite en Rust. Le noyau Linux n'aurait pas pu incorporer du code Rust. Et tu ne pourrais pas utiliser dans ton code la bibliothèque C fuse.

La syntaxe des durées de vie est complexe et rend le code peu lisible. Là aussi, je trouve dommage que Rust ne soit pas capable de gérer ces durées de vie tout seul.

Je ne trouve pas la syntaxe complexe. Les paramètres de lifetime sont déclarés exactement de la même manière que les paramètres de type, en mettant juste un ' devant.

« Gérer les durées de vie tout seul »… difficile de savoir ce que tu entends par là. Si tu veux dire inférer les lifetimes dans les signatures, c'est tout à fait possible, de même que l'inférence de types — en fait il n'y a pas de distinction, c'est la même chose que l'inférence de types. Et le compilateur le fait bel et bien à l'intérieur d'une fonction. Mais il y a un choix de la part des concepteurs du langage d'exiger toujours que le type d'une fonction soit déclaré explicitement, pour qu'il soit facile de comprendre comment utiliser une fonction sans avoir à lire son code.

Cela dit, l'élision des lifetimes allège très souvent les déclarations (par exemple fn id(x: &str) -> &str { x } au lieu de fn<'a> id(x: &'a str) -> &'a str { x }, les règles sont ici).

De la même manière, j'ai l'impression que Rust nous oblige souvent à utiliser le clonage d'objet. Parfois j'aurais préféré ne pas cloner l'objet mais faire une référence (pour des questions de performances), mais là on se retrouve à gérer des durées de vie. Parfois je n'ai pas trouvé comment éviter le clonage simplement.

Il faut un tout petit peu d'expérience, mais on trouve rarement des cas où le compilateur force vraiment un clonage non-nécessaire.

Je n'y ai passé que quelques minutes, mais en parcourant les appels clone(), j'en ai déjà trouvé un certain nombre qui peuvent s'éviter simplement :

diff --git a/src/filesystem.rs b/src/filesystem.rs
index f416c02..2a2530d 100644
--- a/src/filesystem.rs
+++ b/src/filesystem.rs
@@ -49,7 +49,7 @@ pub struct BackupPCFileAttribute {
 impl BackupPCFileAttribute {
     pub fn from_file_attribute(file: FileAttributes, child_ino: u64) -> Self {
         BackupPCFileAttribute {
-            name: file.name.clone(),
+            name: file.name,
             attr: FileAttr {
                 ino: child_ino,
                 size: file.size,
diff --git a/src/util.rs b/src/util.rs
index 28b7b4f..3c4705c 100644
--- a/src/util.rs
+++ b/src/util.rs
@@ -133,9 +133,6 @@ pub fn mangle(path_um: &str) -> String {
 ///
 /// A new iterable with only unique values
 pub fn unique<T: Eq + Hash + Clone>(iterable: impl IntoIterator<Item = T>) -> Vec<T> {
-    let mut seen = HashSet::new();
-    iterable
-        .into_iter()
-        .filter(|e| seen.insert(e.clone()))
-        .collect()
+    let unique_elts : HashSet<T> = HashSet::from_iter(iterable);
+    unique_elts.into_iter().collect()
 }
diff --git a/src/view.rs b/src/view.rs
index 7a6abac..6b1d59d 100644
--- a/src/view.rs
+++ b/src/view.rs
@@ -69,12 +69,12 @@ impl BackupPCView {
             .filter_map(|share| {
                 let share_array = sanitize_path(&share);
                 if path.starts_with(&share_array) {
-                    selected_share = Some(share.clone());
                     share_size = share_array.len();
+                    selected_share = Some(share);
                     None
                 } else if path.eq(&share_array) {
-                    selected_share = Some(share.clone());
                     share_size = share_array.len();
+                    selected_share = Some(share);
                     None
                 } else if share_array.starts_with(path) {
                     Some(share_array[path.len()..][0].to_string())

https://www.lemonde.fr/pixels/article/2024/03/13/france-travail-victime-d-une-cyberattaque-les-donnees-de-43-millions-de-personnes-menacees_6221831_4408996.html

C'est assez dément, quand même.

J'avais juste la flemme de chercher quels pays arabophones avaient la plus grande population 🙂 (Apparemment, c'est l'Égypte avec 110 millions d'habitants, suivie de l'Algérie, le Soudan, l'Irak, le Maroc et l'Arabie Saoudite, qui sont tous entre 30 millions et 40 millions d'habitants.)

Où est le « bloat » qui augmenterait ? On parle d'un jeu de caractères, de trois encodages et de quelques algorithmes plutôt simples, pas d'un logiciel qui grossirait en nombre de lignes de code. Ce n'est pas rajouter des caractères qui va augmenter la complexité de quoi que ce soit, tout au plus cela grossira un peu les tables (remarque : le rythme des ajouts s'est considérablement ralenti ces dernières années, cf. https://www.unicode.org/versions/stats/chart_charbyyear.html, et puis franchement, la taille des tables n'est généralement pas un facteur critique, sauf sans doute dans l'embarqué où chaque Ko compte). Quant aux catégories de caractères et aux algorithmes, ils sont essentiellement stables à ma connaissance.

Unicode est ce qui permet au monde d'avoir essentiellement un unique jeu de caractères, et, avec certes des poches de résistance de latin1 et UTF-16, un unique encodage, UTF-8, ce qui est incontestablement mille fois plus simple que la prolifération d'encodages qui avait cours avant, parce que non, on ne peut pas se contenter de l'ASCII quant il y a 65 millions de Français, 1,4 milliards de Chinois, etc. Donc l'argument de simplification joue fortement en faveur d'Unicode, à mon sens.

Quand à la complexité des algorithmes comme la normalisation etc. (qui du reste est toute relative, les algorithmes sont assez simples, le problème est plutôt que les programmeurs ne savent pas s'en servir) : comme Einstein ne l'a probablement pas dit, « Everything should be made as simple as possible — but no simpler ».

Puisqu'on va demander aux 1,4 milliards de Chinois, aux 1,3 milliards d'Indiens, aux 120 millions de Japonais, au 75 millions de Coréens et aux 150 millions de Russes de changer leur alphabet, je propose qu'au passage on change l'anglais et le français pour ne plus utiliser que les 32 premiers caractères de l'ASCII. Cela permettrait de n'utiliser que 5 bits par caractère, ce qui aiderait rudement la transition écologique. Accessoirement, ces caractères étant invisibles, on épargnerait aux générations suivantes le grand déplaisir de découvrir par la recherche historique notre usage irresponsable des ressources naturelles.

Signé : David Newton, développeur :)

J'ai fait cette page pour résumer un certain nombre d'idées reçues sur Unicode (par exemple : on peut comparer des chaînes de caractères de manière insensible à la casse avec string1.lowercase() == string2.lowercase()).

Si vous trouvez une erreur, n'hésitez pas à me la signaler.

J'ai mis à jour la page https://jean.abou-samra.fr/password.html avec des explications et des remarques issues des commentaires (merci à tous !). J'ai aussi mis un avertissement clair de « à vos risques et périls ».

J'ai rajouté également un peu de CSS. (Mais franchement, c'est plus pour me forcer à apprendre un minimum de CSS qu'autre chose. D'ailleurs je suis sûr que je m'y prends comme un pied et qu'il y a des Web-devs dans le coin qui vont voir mes erreurs, ne vous gênez pas, j'aime apprendre. Et je pourrais ranter sur le fait les navigateurs ne rendent pas une page HTML simple sans CSS avec avec un thème suffisamment lisible par défaut pour qu'il n'y ait pas besoin de systématiquement rajouter du CSS, mais c'est pour un autre journal.)

en fait c'est surtout cette question :

Pourquoi un tel système n'est-il pas universel ? Je me le demande bien.

qui m'a faire répondre "mauvaise idée". Dans un cadre individuel, si tu es conscient des limites de ton système, tu fais bien ce que tu veux :p. Je suis pas blanc-blanc non plus, je ne vais pas donner des leçons :D.

Ah, merci pour la clarification. Mais quand je disais ça, je parlais du principe général, pas de l'algorithme exact. Il est évident qu'il ne faudrait pas qu'un outil utilisant un tel système devienne standard dans la population générale sans que des chercheurs en crypto se penchent très sérieusement sur les algorithmes exacts qui sont utilisés.

Par ailleurs, un sel par personne, je ne crois pas que ce soit si pire par rapport à un sel par mot de passe, vu que tu n'as généralement pas deux comptes sur un même site. Ça continue de protéger de la tabulation de mots de passe courants et des collisions entre mots de passe dans une même DB. Mais je ne suis pas assez expert pour juger vraiment.

En fait, je pense que le plus gros problème avec cette histoire, c'est que l'utilisateur moyen va avoir du mal à retenir le message qu'il ne faut jamais mettre son mot de passe maître dans quoi que ce soit dans lequel on n'a pas une confiance absolue. Je crois que voir la différence entre « je me connecte au site foobar en entrant mon mot de passe maître dans un widget de l'OS ou dans un site séparé, et en copiant le résultat sur foobar » et « le site foobar me demande mon mot de passe maître, je le rentre », c'est un peu trop demander à Madame Michu ☹

Je me suis dit qu'on pouvait le voir dans l'autre sens : l'apex est le sel, et le "mot de passe" est réutilisé sur tous les sites. Sauf que dans ce cas, ton sel est très simple à connaître (typiquement ebay, linuxfr, impots…). Reste le mot de passe qui est costaud, mais réutilisé partout.

Oui, je ne pense pas qu'on puisse vraiment parler de sel pour l'apex. C'est plutôt le mot de passe qui doit être suffisamment fort pour être équivalent à un mot de passe normal + un sel décent.

Si tu n'as pas de bol, et que tu tombes un jour sur une machine avec un keylogger ou un logiciel espion quelconque (genre chez le neveu qui rulez sur le darknet), ton mot de passe maître se retrouve compromis et le générateur n'est pas protégé par de la double authentification. Tu as donc tes fameuses 3/4 heures pour rechanger tes mots de passes partout, en compétition avec les amis de ton neveu. 3, 2, 1, partez !

Alors oui. Mais d'un autre côté… Si je tombe sur un keylogger et que je consulte ma boîte mail, j'ai perdu parce que le mail aujourd'hui est la clé d'accès à tout (outre que je n'ai pas envie qu'on lise mes mails perso). Donc je trouve que la sécurité n'est pas si différente du système usuel des mots de passe : après tout, le mot de passe de la boîte mail est une sorte de mot de passe maître. Le but n'était pas d'améliorer la sécurité du système « normal », plutôt d'améliorer l'utilisabilité à sécurité plus ou moins constante. Et je suis d'accord sur le fait qu'à défaut de WebAuthn, la MFA devrait se généraliser le plus possible, pour les sites à données sensibles (bon, honnêtement, seulement sur eux, parce que je n'ai pas spécialement envie d'avoir besoin d'un appareil pour MFA à portée de main dès que je me connecte sur le moindre forum ou blog sur lequel je veux commenter).

J'accepte la critique d'autodidaxie. Cela dit, on reste sur un système qui n'est utilisé que par moi et qui n'engage que moi, pas quelque chose que j'utiliserais dans une Web-application grand public (tiens, je devrais mettre un avertissement sur la page password.html).

C'est vrai que j'aurais pu mettre un sel, c'est un peu bête de ma part. Cela dit, le mot de passe maître est plutôt long (20 caractères aléatoires), ce qui compense un peu. L'intérêt du sel est multiple, mais il permet en particulier d'éviter que les hashs ne soient matchés contre une base de données de mots de passe courants, et en l'occurrence ça ne va pas y être. Un autre intérêt, c'est d'éviter les collisions entre mots de passe qui se trouveraient être égaux, pour répartir le risque, mais tous mes mots de passe sont différents par construction (à cause de l'apex). Et il y a une question d'échelle qui joue aussi : si j'étais Facebook, il serait clairement essentiel d'associer à différents mots de passe des sels différents, parce qu'il y a tellement de mots de passe dans la DB et tellement de valeur à retirer d'un craquage — donc tellement d'enjeu — qu'il y a un risque évident, si on prend le même sel à chaque fois, que des gens investissent des ressources de calcul importantes pour créer une table géante des hashes des mots de passe courants concaténés avec ce sel particulier. Mais là, on parle d'une personne dans le monde avec cent pauvre mots de passe, et qui n'est pas non plus ciblée par la NSA. Je ne crois pas que changer le sel à chaque fois soit essentiel dans ce cas de figure.

Et j'accepte aussi la critique d'avoir utilisé SHA256 et pas une fonction de hachage un peu dure à calculer. Mais l'API window.crypto.subtle.digest des navigateurs n'a que le SHA1 (pas sécurisé), le SHA256, le SHA384 et le SHA512. Je ne voulais pas introduire des dépendances JavaScript, d'abord je n'y connais rien au développement Web, et ça fait de la maintenance (et, paradoxalement, un risque de vulnérabilités si j'oublie de mettre à jour la dépendance…).

Dans le dernier paragraphe tu indique qu'il est possible de modifier rapidement les mots de passe aléatoirement en quelques minutes mais par expérience cela me prends une bonne journée pour modifier les centaines de comptes qui sont stocké dans mon coffre.

Relis le paragraphe en question :) J'ai dit que ça devrait être facile, pas que ça l'est (c'est bien le problème).

Le hic, c'est que si je m'auto-héberge un VaultWarden… je dépends de mon hébergeur. Je n'ai pas envie / pas le temps de m'occuper d'un serveur chez moi accessible sur le réseau extérieur.

Là, j'ai certes une page HTML sur le site qui est servi par mon hébergeur, mais c'est une simple commodité. Tant que la commande cksum existera, le système marchera toujours.