Moonz a écrit 3657 commentaires

Je ne vois aucune condescendance.

Mon affirmation de base est que UTF-8 est universel, supporté de base dans tous les langages, OS et toolchains modernes. Et toi tu me réponds « yaka faire du format de journald un standard de fait tout aussi universel » ? Mais tu sais, « universel », ça ne se résume pas à « l’ensemble des distributions Linux qui ont adopté systemd » hein…

En manque d’arguments ?

Tu as totalement raison : quand on me prétend qu’UTF-8 est un format binaire et est moins universel que le format binaire spécifique de journalctl, j’ai tendance à avoir du mal à trouver quoi répondre. Bon, c’est surtout que lorsqu’on arrive à un tel niveau de mauvaise foi, je considère que c’est pas la peine de me fatiguer à essayer d’argumenter proprement…

UTF-8 (un nouveau format binaire)

Tu cherches à entrer dans le livre guinness des records, section mauvaise foi, c’est ça ?

On remplace ça par un autre standard de fait (le format de fichier des logs de journald)

Bonne chance pour l’imposer au reste du monde informatique, on te regarde de loin et on en reparle quand tu auras réussi :)

Heu, il y a des équivalents de cat et de less (dont j’ai oublié le nom) dans les OS Microsoft depuis MS-DOS 6.0 hein…

Tu m’expliques l’intérêt pour FreeBSD, Apple, Microsoft, SunOracle… d’intégrer j* dans leur OS ?

Et bien entendu le monde se limite aux distributions Linux récentes.

(note aux mal-comprenants : le mot clef est « Linux », pas « récentes »)

Ça ok, mais de là à dire qu'un format "binaire" (par opposition au "format texte") est forcément complexe, quand on voit le bordel des encodages de texte, faut arrêter… C'est surtout là où je voulais en venir.

Il faut arrêter la fumette (ou la mauvaise foi) parfois. Le standard de fait aujourd’hui c’est utf-8. On parle de journald là, un outil moderne, pas du problème des encodages sur les systèmes antédiluviens qui font tout par défaut en EBCDIC.

Aujourd’hui, quelque chose « encodé » en UTF-8 est universel, lisible par tous les systèmes qui ont moins de 10 ans, supporté par absolument tous les langages et tous les outils vaguement maintenus. Prétendre le contraire c’est juste un gros troll même pas drôle.

Le mot-clef est « grande échelle », pas « outil ».

Mais une fois que systemd aura dominé le reste du monde ce ne sera plus vrai…

Et comme systemd n’a aucune intention de sortir de Linux, ce ne sera jamais vrai :)

Tu t’énerves pour rien, ce n’est pas très bon pour la santé. Personne ne remet en cause la pertinence de journald, seulement le choix d’un format binaire pour l’implémentation.

ou une mauvaise version de lib

Tu as déjà entendu parler de busybox ?

Tu n’as rien compris à la problématique.

Le problème de systemd n’est pas qu’il existe et qu’il soit là par défaut, mais qu’il prédate complètement la concurrence présente et surtout à venir.

Sans systemd (init), pas de udev, pas de logind, et probablement pas de wayland. Il est là le souci. Je cite Lennart :

I have serious doubts that Canonical will play catch-up with this so quickly. The last time they tried that they took logind out of the systemd tree and ported it to Upstart. logind of course is one of the components of systemd where we explicitly documented that it is not a component you can rip out of systemd. And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around. So Ubuntu is stuck with an old and unsupported version of logind. If they advocate this as a solution, then they are in ignorance onthat what they have is already out-of-date. (And yeah, this matters, for example all the nifty stuff that allows Wayland to run nicely without privs is implemented in the newer logind versions, and not in Canonical's forked version).

Il parle de Upstart vs systemd mais c’est bien le principe général qui fait couler tant d’encre : si tu veux pourvoir implémenter un concurrent à systemd, tu seras incompatible avec le reste du monde. Ce n’est pas le cas actuellement : il y a deux ans encore j’avais des systèmes sous initng ; Pardus a fait des trucs très intéressants dans son système d’init. systemd est en train de coupler très fortement des composants du système qui n’étaient pas couplés.

Le débat n’est pas un débat technique systemd vs sysvinit, c’est un débat politique entre monoculture et diversité.

Pourquoi faire ? Hors ligne, tu peux utiliser KeePass, puisque c’est le même format (si j’ai bien suivi)

Vu la puissance de calcul disponible sur nos machines, il est important d'inciter les utilisateurs à générer des mots de passes forts

Quelqu’un qui est intéressé par gPass/LastPass/WKR est à priori déjà sensibilisé au problème je pense. En pratique je ne vois pas vraiment l’intérêt de recoder ça dans le navigateur quand un pwgen -y 15 fait la même chose.

Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.

upstream = nginx/mysql/…, pas arch/slackware/debian

Et puis :

Ben, c’est exactement ce que je dis :
- un système d’init portable tout le monde s’en fout
- systemd n’est pas et ne sera jamais portable parce qu’il expose des fonctionnalités spécifiques à Linux, donc prétendre que « systemd c’est bien parce que ça va enfin nous donner un init universel », je ris très fort

mknod existe toujours :)

Même en non low cost, je préfère 1h de downtime que de passer une semaine à me faire retirer de toutes les blacklist du monde.

Avant une solution portable était possible mais tout le monde s’en foutait (la preuve, initng n’a jamais décollé alors qu’il était là des années avant même que upstart soit en discussion, qui lui-même est antérieur à systemd…)

Maintenant une solution portable est juste impossible.

J’ai du mal à voir l’amélioration sur cet axe d’analyse…

C’est pas grave hein : comme je l’ai dit, en pratique tout le monde s’en fout (tout simplement parce que les distribs tiennent à garder le contrôle de leurs scripts d’init, cf debian qui refuse d’utiliser des unit systemd dans lesquelles les chemins seraient hardcodés, et upstream sait que c’est pas son boulot de fournir 200 scripts d’init mais celui du packageur). Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream ». Ça n’a jamais été son but de toute façon, les buts affichés de systemd c’est :

• un démarrage rapide (parallélisation des serveurs)
• exposition de fonctionnalités Linux-centric peu utilisées à cause du manque d’outils en userspace (typiquement les cgroup)
• à plus long terme, intégration des services de bas niveau (init & udev c’est fait, logind va rejoindre bientôt, à terme wayland va probablement l’être)

SysV était aussi Linux-centré dans les faits.

Pas vraiment non.

Wikipedia.

Edit : j’ai rien dit, ça avait été en discussion un moment et je croyais que ça avait été mis en place mais en fait non.

Et utiliser systemd qui est ouvertement et volontairement Linux-only est une avancée sur ce point parce que… ?

Si le but du jeu était de simplifier la vie des mainteneurs de logiciels tiers c’est OpenRC ou initng qui aurait été poussé au forceps, pas systemd.

J’avais laissé un appeau à troll pour les féministes du site et c’est un troll sur les langages qui part. Je suis déçu :(

Déjà, la version Python n’était pas une application web, c’était une application en ligne de commande que j’utilisais sous ssh pour ajouter/modifier des entrées (côté navigateur internet je ne pouvais qu’invoquer l’auto-filler avec du pur javascript, 0 ligne de code côté serveur)

De suis passé sur PHP parce que Python côté serveur je ne connais pas, et j’ai un apriori assez négatif. Disons que la dernière fois que j’avais regardé (il y a des années), le Python sur le web se divisait en deux catégories :
- des frameworks gargantuesques à la django
- des libs très très bas niveau (apache mod_python, cgi, fastcgi…)

Aucun des deux ne m’intéressent, je veux une abstraction simple de la communication au serveur web (bref, je m’en tape que derrière ce soit un mod apache, du cgi ou du fastcgi) mais pas de framework complet.

Pour finir, la partie serveur (et pas web) en Python que j’avais et la partie PHP que je fais n’ont strictement rien à voir niveau fonctionnel, je n’aurais rien pu récupérer. Tout ce qui était fait en Python est soit déjà fait côté JS soit sera fait côté JS.

J’ai une bonne nouvelle et une mauvaise nouvelle :)

La bonne nouvelle est que la prochaine version ne nécessitera plus hash_pbkdf2. Le but est de ne faire aucune opération cryptographique sur le serveur ; ce but n’est pas encore atteint à cause du manque d’une interface HTML+JS pour créer un compte (je dois donc créer le ring root sur le serveur, d’où hash_pbkdf2), mais c’est le prochain point sur la todo-list.

La mauvaise nouvelle c’est qu’il faudra quand même une version récente de PHP pour l’interface jsonSerialize (5.4 si j’en crois la documentation).

Sur le pourquoi de AES+PBKDF2 au lieu de crypt, plein de réponses :
- La page Wikipedia sur [DES] explique très bien que ce dernier est déconseillé
- La version PHP est très récente, avant c’était du Python. Et c’était AES+PKBDF2.
- http://fr2.php.net/manual/en/function.crypt.php indique : crypt() will return a hashed string using the standard Unix DES-based algorithm or alternative algorithms that may be available on the system.. Pas envie de faire de la rétro-ingénierie par savoir dans quels cas crypt utilise quels algorithmes.

Carte réclamée à fond par des gens qui hurlaient que c'était necessaire, et elle a fait un flop. Quasi personne n'en veut.

Le machin à 15€ que tu gères à l’aide d’un logiciel codé avec les pieds par un stagiaires payé au lance-pierre ? Comme c’est étonnant…

Je suis totalement passé à côté lorsque j’ai fait WKR, je ne l’ai vu qu’il y a quelques jours. Je n’ai pas étudié la chose (utilisation + lisage de code) pendant plus de quelques heures, donc ce que je dis est à prendre avec des pincettes, mais voilà ce que j’en retire :

• On a pas vraiment le même usage en tête. TeamPass se veut une version intranet de KeePassX, dans lequel la gestion multi-utilisateur des mots de passe est au centre du système. Dans WKR la seule gestion multi-utilisateur est « on s’échange le mot de passe ». Ça peut paraître secondaire comme différence au premier coup d’œil mais ça implique des choix assez différents

• À l’usage WKR est pensé pour s’intégrer le plus aisément possible dans le workflow d’un internaute (je me met sur la page de login du site, j’appuie sur C-x, WKR apparaît et me remplit le formulaire) ; TeamPass ne l’est pas du tout (je me met sur la page de login du site, j’ouvre un nouvel onglet, je me connecte sur TeamPass, je cherche le site associé, je copie le mot de passe, je repasse sur le premier onglet, je colle). Rien de fondamental mais ça montre la priorité de chacun des projets (qu’on s’entende : ce n’est pas une critique de TeamPass, j’utilise KeePass au boulot, ce n’est juste pas le même usage)

• TeamPass n’a pas de gestion hiérarchique telle que pensée dans WKR. TeamPass peut organiser hiérarchiquement les entrées dans plusieurs dossiers, il est vrai, mais il est impossible de définir un mot de passe spécifique à un dossier qui permettrait d’ouvrir un dossier fils avec son propre mot de passe ou le mot de passe du dossier père. En fait, dans TeamPass, à toute entrée est associée au plus un et un seul mot de passe permettant de la chiffrer/déchiffrer, parfois 0

• TeamPass possède deux systèmes de chiffrement des mots de passe. Le premier, pour les dossiers dits « personnels » (c’est à dire limités à 1 utilisateur et non partageables) est un simple AES dont la clé est dérivée du mot de passe de l’utilisateur, très exactement comme gPass, WKR ou (en tout cas c’est ce qu’ils disent) LastPass.

• On en arrive au gros point noir (de mon point de vue) de TeamPass. Le second système de chiffrement des mots de passe est utilisé pour tous les dossiers partageables. C’est aussi de l’AES… avec une clé stockée dans un .php sur le même serveur, clé générée à l’installation et utilisée pour absolument tous les mots de passe excepté les mots de passe personnels. Autrement dit, toute personne qui a pu accéder en lecture à ce fichier est en mesure de déchiffrer la grande majorité des mots de passe. Dans WKR, la seule manière pour l’administrateur du service d’accéder aux mots de passe des utilisateurs est de modifier le javascript envoyé au navigateur pour y insérer un keylogger.