Je pense que la distinction technique ne fait sens que pour les personnes capables de la faire. Pour l'utilisateur moyen, la différence entre OS, hardware etc est perdu ou masqué, donc je serait pas étonné que la confusion des marques soit la même en matière de marque.
Le but, c'est pas d'avoir des cases toute fait pour satisfaire l'esprit compulsif du nerd moyen capable de classifier 4500 pokémons par couleur et par force avec une main parce qu'il est expert dans ce domaine et parce qu'il a passé du temps sur sa passion, mais bien de voir si quelqu'un rentrant un peu plus dans une norme vaguement défini comme etant un non expert risque de confondre et si la confusion risque de poser préjudice à un ou l'autre des groupes, et ce genre de considération.
Les modules sont liés en dynamiques avec l’interpréteur python pour lequels ils sont compilés, et avec les deps en dynamiques aussi. Si maintenant, tu veux mettre du statique, faudra en mettre d'un coté ou de l'autre ( genre soit le module python, soit l’interpréteur, soit les 2 ). Et dans tout les cas, tu va avoir des risques de conflits de symboles sauf si tu fait du dynamique et qu'ils utilisent la même version.
Genre j'utilise la libpcre dans mon module python et dans l’interpréteur, et manque de bol, c'est pas la même version, ça va coincer.
Tant de changement en si peu de temps, d'ordinaire ce n'est pas
l'usage dans le monde de la "Prod".
Tu sais, y a pourtant des boites qui font des mises en prod tout les jours. Genre facebook, etc. Je t'invite à lire "the phoenix project", malgré le fait que l'histoire soit pas terrible pour un roman et un chouia ultra cliché, mais ça montre l'avantage de faire des mises en prod réguliére, car ça accelere la boucle de retour entre la partie métier d'une boite ( et donc, les retours utilisateurs ) et les cdoeurs, ce qui permet d'augmenter la satisfaction des gens ( genre, pas attendre 6 mois qu ele service info fasse un changement ).
Ensuite, j'imagine que tout les cas d'utilisation ne s'y retrouvent pas ( même si je pense qu'une grande partie du conservatisme des services financiers pour ne coter qu'eux doit venir du fait que les trucs d'Oracle sont vieux et vieillissants ).
Sinon, si tu veux de la prod qui ne bouge pas, Centos 7 est supporté pour longtemps, RHEL aussi, et SLES également. Ce genre de distributions t'isole des releases et de la cadence du libre.
ça reste quand même investir dans une techno qui va vivre quelques années, d'une part, et dont les fondamentaux vont pas non plus changer d'autre part.
Le fait de faire du live patching, ça reste quand même très délimité comme cas d'usage, je doute fort que les gens investissent des mois dedans et que ça pose souci d'apprendre ça. C'est pas comme passer des mois sur Go pour qu'on te dise "on fait du rust" après 2 mois en prod.
Je pense que j'ai pas besoin d'expliquer en quoi la syntaxe de bash est complexe, ni en quoi le fait de faire un parser parfait est quasiment impossible, vu que personne ou presque ne connait les centaines de subtilités.
Donc le souci, si tu rajoutes un DSL en shell, c'est plus du shell. Et ça va bloquer les gens qui vont confondre les 2 syntaxes.
Mais comme j'avais pas envie de faire un paté sans fin, j'ai pas tout mis, et le véritable souci d'utiliser le shell, c'est que tu peux pas avoir le même niveau de fonctionnalité que systemd en matiére de configuration.
Et je dit pas ça parce qu'il y a pas des outils en CLI pour faire ça, car je suis sur globalement que ça peut s'écrire. Tu peux faire un chroot, un su, un changement de group, etc.
Je dit ça parce qu'il y a des endroits ou c'est juste impossible par design du shell lui même, et j'ai pigé ça y a moins de 2 semaines.
Exemple personnel. Pour rajouter ma pierre à l'édifice de la discussion du TC Debian il y a un an, j'ai codé le support de AppArmor dans systemd ( l'idée étant de réduire la différence entre systemd et upstart, mais y a que systemd ou j'ai réussi à produire du code upstreamable ).
La fonctionnalité est de pouvoir dire "tel service est lancé avec tel profile". Je teste sur une opensuse, ça marche, j'envoie, c'est mergé debut janvier. Il se trouve que je croise les gens de Tails en avril, qui sont en effet intéressé par la feature, et qui après l'intégration de systemd, testent et trouvent que ça ne marche pas en octobre ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760526 ).
Il se trouve que par hasard à la recherche de bug à corriger, je passe sur le BTS de Debian, et déjà, je vois que j'ai un premier bug sur le message d'erreur de mon code que je corrige ( envoie, merge, dans la journée ). À partir de la, j'arrive à piger que j'ai un 2eme bug.
Le bug est que pour changer de profile apparmor, tu dois écrire dans /proc/self/attr ( http://wiki.apparmor.net/index.php/Kernel_interfaces ). Tu peux changer le profile du processus courant, ou du prochain processus exécuté. Le déclencheur du bug est que le service tor du projet tails est blindé, et notamment, l'accés à /proc est restreint pour tor via systemd. Et si tu fait disparaitre /proc avant de tenter de changer de profile, ça ne marche pas, ce qui est le cas dans mon code. D'abord, systemd restreint les namespaces, ensuite, il fait la demande de changement de profil pour le prochain processus ( exec_child dans src/core/execute.c ).
Donc la solution est d'écrire dans /proc en demandant de changer le profil du prochain process , puis de faire des montages spéciaux avec les namespaces. Changer le processus courant bloque les changements avec les namespaces, et faire les changements avec les namespaces bloque le changement de contexte apparmor.
Systemd est en en C, et ça marche parce que systemd ne fait pas de fork sauf pour lancer le service.
En shell, ça ne peux pas marcher dans l'état, car tout est un fork.
Si je commence par faire le echo kivabien dans /proc pour apparmor, ça va s'appliquer au prochain processus, qui va être le processus nsenter qui va changer les namespaces, et qui va sans doute être bloqué en fonction de la politique apparmor.
Et si je rentre dans un namespace d'abord, puis que je fait l'écriture vers /proc, je peux pas car mon namespace peut supprimer /proc.
Conclusion, ça ne marche pas, et c'est à mon sens impossible de faire marcher ça, sauf à changer apparmor pour avoir un autre mécanisme de communication qui marche sans /proc.
Et même la, le mécanisme devra marcher dans un environnement très restrictif ( genre avec des syscalls désactivés, etc ).
Le fait de dire "fait le changement pour le prochain executable" est très élégant car tu peux empiler les restrictions sans que ça se marche sur les pieds, ça ne s’appliquera qu'à ton fils, le processus à lancer.
Mais en shell, tu n'as pas de séparation logique donc tu ne peux pas avoir ça.
Alors mon exemple est ultra particulier. J'ai relu le reste du code et globalement, y a rien qui ne me saute aux yeux pour dire "y a pas que apparmor" ( enfin y a le choix du contexte selinux, mais le souci est une variation de apparmor, qui souffre du même bug comme je viens de le voir, et qui a été aussi écrit par moi (j'ai un peu honte)).
Le coeur du souci est en effet d'appliquer des restrictions capables de se bloquer les unes et les autres, et les appliquer dans un ordre convenable. Sauf que comme il y a une boucle, le seul moyen est de briser la boucle en séparant l'application de la restriction de sa déclaration en appliquant à un événement dans le futur. Le fait d'appliquer "on exec" est exactement ça.
Alors une solution serait de modifier le protocole de communication pour prendre un argument en plus, le chemin de l’exécutable à confiner en plus du profile/domaine/etc.
Mais il y a des corners cases et des choses non intuitives ( genre si je veut restreindre python et qu'un des programmes pour restreindre est écrit aussi en python, ou justement, si je veux restreindre un script en python, il faut que je dise que c'est python que je veux restreindre car c'est ce que le kernel va voir, etc ).
Donc parce que des APIs et le kernel est pas vraiment toujours shell friendly, un systéme d'init qui se base sur le shell autant que possible ne va pas avoir le même niveau de fonctionnalités.
Bien sur, une solution alternative serait sans doute d'avoir juste un gros binaire comme start-stop-daemon qui prends des tas d'options, voir des variables d'environement. On en reviens du coup à la critique "je ne peux pas comprendre ce qui se passe dans le script", vu que ça devient juste "je déclare des vars et je lance un binaire magique qui fait tout". Je ne doute pas qu'on râle au manque d'esprit unix de la chose :)
C'est en effet un chouia plus déclaratif, mais ça reste du shell. C'est un pas en avant par rapport à ce qu'on trouve sur linux, sans aucun doute, mais pld le faisait aussi.
Mais ça n'est pas du 100% déclaratif, ce qui fait qu'il manque 2 points importants :
- la possibilité de faire de l'analyse statique. Ce que je veux dire par la, c'est d'automatiser la lecture du fichier, et son analyse vis à vis d'un jeu de regle. C'est un mécanisme de QA, et je pense que ça aide aussi pour des audits de configurations. Je reconnais que c'est un souci purement de distributeur.
la possibilité de fusionner proprement 2 fichiers. Ce que je veux dire par la, c'est d'avoir ta config qui écrase facilement celle du systeme. Techniquement, tu pourrais le faire en te limitant à un subset du shell, c'est vrai. Mais du coup, c'est plus du vrai shell, et tu as aucune assurance que ça va marcher comme il faut.
Et dans le cas de systemd, le fait d'avoir un language purement déclaratif permet de rajouter par dessus du templating. Chose qui serait faisable en bash aussi à priori, modulo le fait que bash fait deja ça, et que ça serait à mon sens moins élégant.
mais tu n'as pas les avantages d'un format qu'on peut parser. Et a reste du shell, ce qui fait que tu peux pas faire proprement le trick
C'est en effet un souci d'industrialisation. C'est à dire que systemd va mutualiser et industrialiser le processus métier.
Mine de rien, c'est comme passer de sendmail et son language de macro m4 ( on m'a parlé de faire une calculatrice avec ) à postfix, qui est purement déclaratif.
Au début, dans une phase d'innovation, on sait pas exactement ce qu'on veut, ça part dans tout les sens. Et puis avec le temps, on a une idée plus précise, et on repart de la.
Tu regardes l'histoire des outils de gestions de configuration ( cfengine, puppet, etc ), ça commence par des scripts shells. Puis on a passe à des outils de configurations à base de declaration ( puppet, cfengine ), il y a des gens qui veulent revenir à des scripts ( chef, le ruby DSL de puppet, ), mais les nouveaux partent par défaut vers du déclaratif avant tout ( salt, ansible ), avec le scripting en possibilité mais pas vraiment par défaut.
Et systemd se place à ce niveau. Tu peux faire des scripts shells si tu veux, mais le défaut va vers l'industrialisation.
Upstart est invasif. Il supporte pas inittab ( comme systemd ), et il a un format spécial ( comme systemd ), et il y a un plan d el'utiliser comme gestionnaire de session ( au moins unity fait ça ).
Et depuis le début, il propose de remplacer atd/crond ( je sais pas si c'est codé ceci dit ).
Ensuite, le fait aussi que personne s'intéresse à upstart, ce qui est triste.
Alors, comme je suis un mec curieux, je me suis demandé qui est derriére le fork.
Donc j'ai cherché debianfork ( aprés un coup de whois et co, qui pointe vers dyne.org, une variante Debian pour le multimedia ). Et je suis tombé sur le brouillon du site sur lab.dyne.org :
Script qui bien sur a un souci avec la gestion de /tmp dans certaines conditions, car il vérifie pas le code de retour de tmp_create, qui pourrait échouer si un autre utilisateur rempli /dev/shm. Y a des chances que ça fasse de la perte de données, et de la merde sans aucun doute.
Et comme il vérifie pas que le fichier existe déjà, comme /dev/shm est en écriture pour tous et comme le script tourne en root, je peux faire un fichier avec le nom prévisible ( vu que c'est pid + random ), et mettre les acl qui vont bien pour le lire, et le script va faire son touch, son chown et tout ça, et je vaix pouvoir choper la clé ( cf https://github.com/dyne/Tomb/blob/master/tomb#L833 ).
Alors on va me dire "faut être vachement rapide pour faire ça", je vais dire que c'est pour ça qu'on a incron. Et surtout si les PID ne sont pas randomisés, je peux juste faire une attaque qui peut statistiquement fonctionner.
Sinon, le script utilise /etc/password pour lister les users, il ne marche donc pas avec ldap ou nis. Il execute aussi directement ce que le fichier tomb lui dit d'executer, ce qui est quand même super comme fonction ( tiens, un fichier chiffré avec les données secrètes, tu peux l'ouvrir, et "oups, ma clé ssh s'est rajouté dans ton trousseau" ). Je suis sur qu'en cherchant aussi de manière créative, on peut injecter des commandes avec dans le script avec un nom de fichier qui prends des metacaractéres.
J'ose croire qu'il y a d'autres VAU avec lui pour faire ce fork, car la, ça me fait quand même doucement rire.
En même temps, à force d'avoir des gens qui harcèlent mais qui disent "nan, je suis juste un trolleur" comme par example, weev aka Andrew Alan Escher Auernheimer, il faut pas s'étonner du glissement sémantique.
Et perso, si il y a bien un mot dont je me souci fort peu, c'est celui la. ( et valétudinaire aussi, je m'en préoccupe peu ).
Autant hacker, je peux comprendre qu'on veuille reprendre l'identité et le mot, mais troll n'a jamais eu rien de positif ( sauf pour une personne que je connais, et c'était un sens différent de celui qu'on utilise AMHA ).
Depuis que j'ai lu qu'une des personnes derrière le mouvement antisystemd est MikeUSA, un mec connu pour avoir harceler pendant longtemps plein de gens, je commence à regarder d'un autre œil les posts.
Et la, ça commence fort niveau allégation. Dire que debian a été fait pour l'utilisateur est faux. Il est dit que la priorité sont les utilisateurs, mais ça ne veut pas dire que l'utilisateur sait ce qu'il veut. Ni qu'il est maitre à bord, loin de la.
Ensuite, la partie sur "le comité est rempli d'anciens de Red Hat er de Canonical" est fausse. Il y a 2 personnes de Canonical et 1 ancien, et c'est tout. Et en relisant les débats, c'est eux qui étaient contre systemd.
Ensuite, l'argument visant à faire croire qu'il s'agit d'une prise de pouvoir militaire comme en égypte est ridicule, car le pouvoir en question a toujours été la. Comparer le fait de bannir les gens avec le fait de se faire tirer dessus est aussi risible.
Mais ce qui me fait le plus tiquer, c'est de faire remarquer que tout est parti en sucette il y a 8 ans quand ils ont virer les gens qui disent du mal des femmes, donc ils sont contre la liberté d'expression ( vous savez, la liberté d'expression qui consiste à harceler les gens sur internet par exemple ).
Sachant que le mec a juste ouvert un compte pour poster ses théories fumeuses, dire qu'il s'agit d'un faux compte est un pas que je franchirais allégrement.
Tout colle, l'obsession a redire encore et toujours les mêmes trucs faux sans la moindre preuve, le fait de se positionner en martyr sur la base de choses non vérifiables, les insultes ( "these people are bastards" suite à son banissement ).
Mais il y a plein de perles, comme quand le mec tente quand même de dire que c'est pas important de mettre à jour, car y a grsec et pax, et apparmor. Bien sur, personne ne va lui dire qu'une technique de contournement de pax a été publié ( http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf ).
Alors, tu es sur du nom ? Parce que la, je tombe sur un truc d'oracle dans Google.
Et sinon, oui, le souci des discussions constantes sur le sujet est que le niveau technique et les propositions sont au raz des pâquerettes. Ayant lu debian-user@, ça vole pas haut et les gens comprennent pas pourquoi ils veulent pas certaines choses, mais ils sont sur de pas le vouloir.
Il y a sans doute plein de possibilités, mais comme une bonne part des gens semblent fatigués par le sujet qui polarisent une part des utilisateurs, les gens capables de discuter se résignent.
Bien sur, toute tentative de ramener le calme est vu comme "les pro systemd veulent nous faire taire" ( ce qui est vrai, quand quelqu'un a dit 15 fois que c'est une conspiration, la 16eme est du bruit inutile ) et ça repart de plus belle.
Je ne doute pas le moins du monde que la raison derrière ce souci soit valable et rationnel. Même si tu m'avais dit "on a retiré haproxy car on avait personne pour s'en occuper", j'aurais trouvé ça acceptable, ça fait parti du jeu des distros communautaires ( voir même commercial, avoir un peu plus de ressources implique pas d'en avoir une infinité )
Je fait confiance aux gens du libre pour faire des choix avec une bonne raison, même si parfois je peux ne pas être d'accord.
Mon point est juste que l'argument de jamais avoir de changement ou de régression est une vison idéalisée. Un autre exemple est selinux, et je pourrais raler sur le fait de pas avoir eu de réponse sur mes rapports de bugs sur la stable ( avec 2 patchs ), mais si y a personne pour faire le taf sur la stable, bah tant pis pour moi :)
Je pense que garder sysvinit n'est en effet pas le plus gros souci. Le souci, ça va être de convaincre les packageurs de garder les scripts d'init dans leur paquets, et de corriger les potentiels bugs. Et bien sur de garder et corriger les trucs de démarrage en shell ( ie, tout /etc/rcS.d/* ) si besoin. Et sur le point des bugs, je suis rassuré de voir que je suis pas le seul à citer le script de bind comme exemple de script buggué par design ( genre, y a un mec qui cite ça sur lwn ).
Et donc je pense que comme systemd élimine quand même une bonne classe de comportement problématique grace au démarrage dans un env clean, il est attractif pourles packageurs de convertir les paquets.
Par exemple, j'ai parlé avec un des devs de fusion inventory , qui m'a dit que le passage à systemd a permis de liquider 1/3 des bugs sur launchpad, cad tout les bugs à la con avec le fait qu'un des processus meurt et pas un autre, etc.
Donc sur la base de ce genre de besoin, je pense que le chemin qui marcherait serait de pousser openrc ( car portable, et encore en cours de dev ), et le rendre capable de lire les fichiers de systemd, et/ou trouver comment faire des scripts d'init depuis les fichiers de systemd ( cf projet gsoc ).
Du coup, les gens qui veulent pas systemd auront une alternative. Les gens qui veulent des scripts auront leur truc en shell, avec sans doute moins de variations. Et la charge de travail pour les packageurs resteras raisonnable.
Bien sur, ça ne régle le souci que pour la partie "init". Il resteras encore le souci pour logind et la subsistance de systemd-shim sur le long terme.
Tout ça, je pense que ça aurais pu se faire durant les mois depuis le premier vote et maintenant par quelqu'un d'assez motivé et compétent, avec assez de temps. Je ne me prononcerais pas sur le fait que ça ne soit pas arrivé pour le moment, malgré tout ces gens qui sont prêt à protester.
Sinon, c'est aussi une bonne nouvelle pour debian lts, car je suis sur que tout ces gens vont mettre la main à la poche pour financer la survie de la stable courante pour éviter le piége systemd, bien sur.
Bah, je pense qu'il a le droit d'avoir un avis différent du mien :)
Je pense qu'en effet, un apport de gens motivés pour les BSD serait une bonne chose. Je suis par contre pas forcement sur que les gens qui ralent sur systemd dans debian soient dans leur grande majorité ce genre de gens. Il y en a sans doute, et il y a des gens qui ont des critiques valables, et qui tombent sur des bugs et des régressions ( keyscript et luks, par exemple ). Ensuite, ça serait pas la première regression dans debian ( le fait de retirer haproxy dans la dernière stable par exemple ), c'est des choses qui arrivent à tous.
Idéalement, voir même installer un forum sur leur site, histoire que les gens puissent se concerter et proposer une communication construite.
Je serait le premier à lister des soucis de systemd si on me demande ( la dépendance aux cgroups était par exemple un souci sur mes VPS sans le support dans le kernel, bien que ça soit corrigé via un patch upstream ), mais j'ai relu tout les threads de debian-user, c'est extrêmement peu précis. Il y a des bugs, il y a une features bien spécifiques sur la crypto qui semblent ne pas marcher, mais le reste c'est des gens veulent pas parce qu'ils veulent pas. Y a un mec qui poste pour dire que c'est plus compliqué à réparer pour lui. C'est sans doute vrai, il faut d'autres connaissances que le shell, mais je ne voit personne faire ce genre d'argument vis à vis de tout le reste des choses en C ( à part le projet olpc, qui a tout fait en python pour laisser les gens lire le code ).
une bonne part semble agiter le spectre de "ça ressemble à windows" et "Red hat va contrôler le monde du libre avec ça". Mon favori reste quand même le mec qui postule que systemd est la pour rendre les choses plus compliqués afin de vendre plus de services et de consulting via des techniciens "forcement" certifiés par RH.
Donc je pense que faire un groupe de discussion avec quelqu'un pour répondre point à point et garder les remontés valables ( par exemple, améliorer les messages d'erreur pour rendre les fichiers d'unités plus facile à debugger en essayant de voir ce qui fait que les gens trouvent ça difficile à debugger ) serait positif.
Actuellement, ça part plus dans l'outrage personnel à base de reprendre le concept de "linux is about choice".
La question est pas de savoir si il y a ou pas des pertes de temps, c'est de savoir si il y en a significativement plus ou moins, si le fait de corriger le souci est plus ou moins couteux pour la banque ( genre, si mon doigt est sale, je le lave, le cout de la banque est proche de 0 ), et si c'est plus facile de copier une empreinte digital qu'un code à 4 chiffres.
Ensuite, il y a aussi un moment ou il faut expérimenter à grande échelle après avoir fait des pilotes qui ont du se révéler constructif.
Non, j'ai payé un sandwich chez subway, j'ai été horrifié de ne rien signer et de ne pas taper de code. On m'a dit que c'est normal quand le montant est petit.
Du coup, je pige mieux pourquoi les gens paniquent quand Target et autres se sont infiltrés.
Moi, j'ai déjà eu un blanc sur mon numéro de carte bleue. Depuis, j'ai toujours du liquide sur moi en cas de problème.
J'ai aussi une carte pro et je l'utilise pas assez souvent pour garder les 4 chiffres en tête. Du coup, j'ai une solution compliqué pour les retrouver.
Si je pouvais me contenter d'utiliser mon doigt au lieu de devoir mettre ma tête à contribution pour faire obtenir du liquide, ma vie serait vachement mieux.
J'ai du mal à piger en quoi une attaque qui requiert que l'attaquant fasse des requetes actives ( ie, la partie ou le js intervient dans le papier ) va marcher pour openldap ?
Quel client va poser souci, dans quels conditions ?
[^] # Re: Fonds
Posté par Misc (site web personnel) . En réponse au journal Gnome lance un financement et une action en Justice contre Groupon pour protéger sa marque !. Évalué à 3.
Il est aussi probable que les sponsors payent de façon annuelle.
[^] # Re: Deux critiques
Posté par Misc (site web personnel) . En réponse au journal Gnome lance un financement et une action en Justice contre Groupon pour protéger sa marque !. Évalué à 6.
Je pense que la distinction technique ne fait sens que pour les personnes capables de la faire. Pour l'utilisateur moyen, la différence entre OS, hardware etc est perdu ou masqué, donc je serait pas étonné que la confusion des marques soit la même en matière de marque.
Le but, c'est pas d'avoir des cases toute fait pour satisfaire l'esprit compulsif du nerd moyen capable de classifier 4500 pokémons par couleur et par force avec une main parce qu'il est expert dans ce domaine et parce qu'il a passé du temps sur sa passion, mais bien de voir si quelqu'un rentrant un peu plus dans une norme vaguement défini comme etant un non expert risque de confondre et si la confusion risque de poser préjudice à un ou l'autre des groupes, et ce genre de considération.
[^] # Re: Le problème est là...
Posté par Misc (site web personnel) . En réponse au journal Une idée de distribution Linux. Évalué à 2.
Les modules sont liés en dynamiques avec l’interpréteur python pour lequels ils sont compilés, et avec les deps en dynamiques aussi. Si maintenant, tu veux mettre du statique, faudra en mettre d'un coté ou de l'autre ( genre soit le module python, soit l’interpréteur, soit les 2 ). Et dans tout les cas, tu va avoir des risques de conflits de symboles sauf si tu fait du dynamique et qu'ils utilisent la même version.
Genre j'utilise la libpcre dans mon module python et dans l’interpréteur, et manque de bol, c'est pas la même version, ça va coincer.
[^] # Re: Le problème est là...
Posté par Misc (site web personnel) . En réponse au journal Une idée de distribution Linux. Évalué à 2.
Il a des modules en C. Tu veux les lier statiquement à l'interpréteur ?
[^] # Re: Le problème est là...
Posté par Misc (site web personnel) . En réponse au journal Une idée de distribution Linux. Évalué à 3.
Il reste plus que les soucis autre que les libs à régler :
- interface dbus
- langage de script
[^] # Re: Est-ce vraiment un programme de "production" ?
Posté par Misc (site web personnel) . En réponse à la dépêche systemd version 216. Évalué à 7.
Tu sais, y a pourtant des boites qui font des mises en prod tout les jours. Genre facebook, etc. Je t'invite à lire "the phoenix project", malgré le fait que l'histoire soit pas terrible pour un roman et un chouia ultra cliché, mais ça montre l'avantage de faire des mises en prod réguliére, car ça accelere la boucle de retour entre la partie métier d'une boite ( et donc, les retours utilisateurs ) et les cdoeurs, ce qui permet d'augmenter la satisfaction des gens ( genre, pas attendre 6 mois qu ele service info fasse un changement ).
Ensuite, j'imagine que tout les cas d'utilisation ne s'y retrouvent pas ( même si je pense qu'une grande partie du conservatisme des services financiers pour ne coter qu'eux doit venir du fait que les trucs d'Oracle sont vieux et vieillissants ).
Sinon, si tu veux de la prod qui ne bouge pas, Centos 7 est supporté pour longtemps, RHEL aussi, et SLES également. Ce genre de distributions t'isole des releases et de la cadence du libre.
[^] # Re: kGraft
Posté par Misc (site web personnel) . En réponse au journal SUSE Linux Enterprise 12 disponible !. Évalué à 6.
ça reste quand même investir dans une techno qui va vivre quelques années, d'une part, et dont les fondamentaux vont pas non plus changer d'autre part.
Le fait de faire du live patching, ça reste quand même très délimité comme cas d'usage, je doute fort que les gens investissent des mois dedans et que ça pose souci d'apprendre ça. C'est pas comme passer des mois sur Go pour qu'on te dise "on fait du rust" après 2 mois en prod.
[^] # Re: belle brochette
Posté par Misc (site web personnel) . En réponse à la dépêche Open World Forum 2014, c'est les 30 et 31 octobre prochains #OWF14. Évalué à 3.
J'en parlerais quand j'aurais une idée plus précise de ce que je veux dire. Autant j'ai déjà la matière, autant j'ai pas encore mis de l'ordre :)
[^] # Re: Forkons Fedora !
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Je pense que j'ai pas besoin d'expliquer en quoi la syntaxe de bash est complexe, ni en quoi le fait de faire un parser parfait est quasiment impossible, vu que personne ou presque ne connait les centaines de subtilités.
Donc le souci, si tu rajoutes un DSL en shell, c'est plus du shell. Et ça va bloquer les gens qui vont confondre les 2 syntaxes.
Mais comme j'avais pas envie de faire un paté sans fin, j'ai pas tout mis, et le véritable souci d'utiliser le shell, c'est que tu peux pas avoir le même niveau de fonctionnalité que systemd en matiére de configuration.
Et je dit pas ça parce qu'il y a pas des outils en CLI pour faire ça, car je suis sur globalement que ça peut s'écrire. Tu peux faire un chroot, un su, un changement de group, etc.
Je dit ça parce qu'il y a des endroits ou c'est juste impossible par design du shell lui même, et j'ai pigé ça y a moins de 2 semaines.
Exemple personnel. Pour rajouter ma pierre à l'édifice de la discussion du TC Debian il y a un an, j'ai codé le support de AppArmor dans systemd ( l'idée étant de réduire la différence entre systemd et upstart, mais y a que systemd ou j'ai réussi à produire du code upstreamable ).
La fonctionnalité est de pouvoir dire "tel service est lancé avec tel profile". Je teste sur une opensuse, ça marche, j'envoie, c'est mergé debut janvier. Il se trouve que je croise les gens de Tails en avril, qui sont en effet intéressé par la feature, et qui après l'intégration de systemd, testent et trouvent que ça ne marche pas en octobre ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760526 ).
Il se trouve que par hasard à la recherche de bug à corriger, je passe sur le BTS de Debian, et déjà, je vois que j'ai un premier bug sur le message d'erreur de mon code que je corrige ( envoie, merge, dans la journée ). À partir de la, j'arrive à piger que j'ai un 2eme bug.
Le bug est que pour changer de profile apparmor, tu dois écrire dans /proc/self/attr ( http://wiki.apparmor.net/index.php/Kernel_interfaces ). Tu peux changer le profile du processus courant, ou du prochain processus exécuté. Le déclencheur du bug est que le service tor du projet tails est blindé, et notamment, l'accés à /proc est restreint pour tor via systemd. Et si tu fait disparaitre /proc avant de tenter de changer de profile, ça ne marche pas, ce qui est le cas dans mon code. D'abord, systemd restreint les namespaces, ensuite, il fait la demande de changement de profil pour le prochain processus ( exec_child dans src/core/execute.c ).
Donc la solution est d'écrire dans /proc en demandant de changer le profil du prochain process , puis de faire des montages spéciaux avec les namespaces. Changer le processus courant bloque les changements avec les namespaces, et faire les changements avec les namespaces bloque le changement de contexte apparmor.
Systemd est en en C, et ça marche parce que systemd ne fait pas de fork sauf pour lancer le service.
En shell, ça ne peux pas marcher dans l'état, car tout est un fork.
Si je commence par faire le echo kivabien dans /proc pour apparmor, ça va s'appliquer au prochain processus, qui va être le processus nsenter qui va changer les namespaces, et qui va sans doute être bloqué en fonction de la politique apparmor.
Et si je rentre dans un namespace d'abord, puis que je fait l'écriture vers /proc, je peux pas car mon namespace peut supprimer /proc.
Conclusion, ça ne marche pas, et c'est à mon sens impossible de faire marcher ça, sauf à changer apparmor pour avoir un autre mécanisme de communication qui marche sans /proc.
Et même la, le mécanisme devra marcher dans un environnement très restrictif ( genre avec des syscalls désactivés, etc ).
Le fait de dire "fait le changement pour le prochain executable" est très élégant car tu peux empiler les restrictions sans que ça se marche sur les pieds, ça ne s’appliquera qu'à ton fils, le processus à lancer.
Mais en shell, tu n'as pas de séparation logique donc tu ne peux pas avoir ça.
Alors mon exemple est ultra particulier. J'ai relu le reste du code et globalement, y a rien qui ne me saute aux yeux pour dire "y a pas que apparmor" ( enfin y a le choix du contexte selinux, mais le souci est une variation de apparmor, qui souffre du même bug comme je viens de le voir, et qui a été aussi écrit par moi (j'ai un peu honte)).
Le coeur du souci est en effet d'appliquer des restrictions capables de se bloquer les unes et les autres, et les appliquer dans un ordre convenable. Sauf que comme il y a une boucle, le seul moyen est de briser la boucle en séparant l'application de la restriction de sa déclaration en appliquant à un événement dans le futur. Le fait d'appliquer "on exec" est exactement ça.
Alors une solution serait de modifier le protocole de communication pour prendre un argument en plus, le chemin de l’exécutable à confiner en plus du profile/domaine/etc.
Mais il y a des corners cases et des choses non intuitives ( genre si je veut restreindre python et qu'un des programmes pour restreindre est écrit aussi en python, ou justement, si je veux restreindre un script en python, il faut que je dise que c'est python que je veux restreindre car c'est ce que le kernel va voir, etc ).
Donc parce que des APIs et le kernel est pas vraiment toujours shell friendly, un systéme d'init qui se base sur le shell autant que possible ne va pas avoir le même niveau de fonctionnalités.
Bien sur, une solution alternative serait sans doute d'avoir juste un gros binaire comme start-stop-daemon qui prends des tas d'options, voir des variables d'environement. On en reviens du coup à la critique "je ne peux pas comprendre ce qui se passe dans le script", vu que ça devient juste "je déclare des vars et je lance un binaire magique qui fait tout". Je ne doute pas qu'on râle au manque d'esprit unix de la chose :)
[^] # Re: Forkons Fedora !
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 6.
Alors, j'ai pris un script au hasard :
https://svnweb.freebsd.org/ports/head/irc/ircd-hybrid/files/ircd-hybrid.in?revision=340872&view=markup
C'est en effet un chouia plus déclaratif, mais ça reste du shell. C'est un pas en avant par rapport à ce qu'on trouve sur linux, sans aucun doute, mais pld le faisait aussi.
Mais ça n'est pas du 100% déclaratif, ce qui fait qu'il manque 2 points importants :
- la possibilité de faire de l'analyse statique. Ce que je veux dire par la, c'est d'automatiser la lecture du fichier, et son analyse vis à vis d'un jeu de regle. C'est un mécanisme de QA, et je pense que ça aide aussi pour des audits de configurations. Je reconnais que c'est un souci purement de distributeur.
Et dans le cas de systemd, le fait d'avoir un language purement déclaratif permet de rajouter par dessus du templating. Chose qui serait faisable en bash aussi à priori, modulo le fait que bash fait deja ça, et que ça serait à mon sens moins élégant.
mais tu n'as pas les avantages d'un format qu'on peut parser. Et a reste du shell, ce qui fait que tu peux pas faire proprement le trick
[^] # Re: Forkons Fedora !
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
C'est en effet un souci d'industrialisation. C'est à dire que systemd va mutualiser et industrialiser le processus métier.
Mine de rien, c'est comme passer de sendmail et son language de macro m4 ( on m'a parlé de faire une calculatrice avec ) à postfix, qui est purement déclaratif.
Au début, dans une phase d'innovation, on sait pas exactement ce qu'on veut, ça part dans tout les sens. Et puis avec le temps, on a une idée plus précise, et on repart de la.
Tu regardes l'histoire des outils de gestions de configuration ( cfengine, puppet, etc ), ça commence par des scripts shells. Puis on a passe à des outils de configurations à base de declaration ( puppet, cfengine ), il y a des gens qui veulent revenir à des scripts ( chef, le ruby DSL de puppet, ), mais les nouveaux partent par défaut vers du déclaratif avant tout ( salt, ansible ), avec le scripting en possibilité mais pas vraiment par défaut.
Et systemd se place à ce niveau. Tu peux faire des scripts shells si tu veux, mais le défaut va vers l'industrialisation.
[^] # Re: Oubli ?
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Upstart est invasif. Il supporte pas inittab ( comme systemd ), et il a un format spécial ( comme systemd ), et il y a un plan d el'utiliser comme gestionnaire de session ( au moins unity fait ça ).
Et depuis le début, il propose de remplacer atd/crond ( je sais pas si c'est codé ceci dit ).
Ensuite, le fait aussi que personne s'intéresse à upstart, ce qui est triste.
[^] # Re: Jeu de mots
Posté par Misc (site web personnel) . En réponse à la dépêche SELKS 1.0 : une distribution . Évalué à 1.
Tu peux la faire en anglais "Selks and the CTO"
Et tu peux aussi faire une présentation sur la securisation de la distro :
"practice safe selks".
# Et le créateur est ...
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Alors, comme je suis un mec curieux, je me suis demandé qui est derriére le fork.
Donc j'ai cherché debianfork ( aprés un coup de whois et co, qui pointe vers dyne.org, une variante Debian pour le multimedia ). Et je suis tombé sur le brouillon du site sur lab.dyne.org :
https://webcache.googleusercontent.com/search?q=cache:ig5xnArsuqwJ:https://lab.dyne.org/DebianFork+&cd=9&hl=fr&ct=clnk&gl=ca&client=firefox-a
qui pointe vers Jaromil comme éditeur. Le même Jaromil qui a un article wikipedia à son nom. Et qui a posté sur twitter au sujet du fork :
https://twitter.com/jaromil
ainsi que divers appels à refuser systemd.
En cherchant un peu, on voit qu'il a une page dédié à purifier les distributions linux :
https://lab.dyne.org/GnuLinuxPurification
Et qu'il a écrit un soft de crypto en shell :
https://www.dyne.org/software/tomb/
https://github.com/dyne/Tomb/blob/master/tomb
Script qui bien sur a un souci avec la gestion de /tmp dans certaines conditions, car il vérifie pas le code de retour de tmp_create, qui pourrait échouer si un autre utilisateur rempli /dev/shm. Y a des chances que ça fasse de la perte de données, et de la merde sans aucun doute.
Et comme il vérifie pas que le fichier existe déjà, comme /dev/shm est en écriture pour tous et comme le script tourne en root, je peux faire un fichier avec le nom prévisible ( vu que c'est pid + random ), et mettre les acl qui vont bien pour le lire, et le script va faire son touch, son chown et tout ça, et je vaix pouvoir choper la clé ( cf https://github.com/dyne/Tomb/blob/master/tomb#L833 ).
Alors on va me dire "faut être vachement rapide pour faire ça", je vais dire que c'est pour ça qu'on a incron. Et surtout si les PID ne sont pas randomisés, je peux juste faire une attaque qui peut statistiquement fonctionner.
Sinon, le script utilise /etc/password pour lister les users, il ne marche donc pas avec ldap ou nis. Il execute aussi directement ce que le fichier tomb lui dit d'executer, ce qui est quand même super comme fonction ( tiens, un fichier chiffré avec les données secrètes, tu peux l'ouvrir, et "oups, ma clé ssh s'est rajouté dans ton trousseau" ). Je suis sur qu'en cherchant aussi de manière créative, on peut injecter des commandes avec dans le script avec un nom de fichier qui prends des metacaractéres.
J'ose croire qu'il y a d'autres VAU avec lui pour faire ce fork, car la, ça me fait quand même doucement rire.
[^] # Re: WTF ?
Posté par Misc (site web personnel) . En réponse au journal La chasse aux trolls est ouverte !. Évalué à 4.
En même temps, à force d'avoir des gens qui harcèlent mais qui disent "nan, je suis juste un trolleur" comme par example, weev aka Andrew Alan Escher Auernheimer, il faut pas s'étonner du glissement sémantique.
Et perso, si il y a bien un mot dont je me souci fort peu, c'est celui la. ( et valétudinaire aussi, je m'en préoccupe peu ).
Autant hacker, je peux comprendre qu'on veuille reprendre l'identité et le mot, mais troll n'a jamais eu rien de positif ( sauf pour une personne que je connais, et c'était un sens différent de celui qu'on utilise AMHA ).
# Le post de forum
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Depuis que j'ai lu qu'une des personnes derrière le mouvement antisystemd est MikeUSA, un mec connu pour avoir harceler pendant longtemps plein de gens, je commence à regarder d'un autre œil les posts.
Et la, ça commence fort niveau allégation. Dire que debian a été fait pour l'utilisateur est faux. Il est dit que la priorité sont les utilisateurs, mais ça ne veut pas dire que l'utilisateur sait ce qu'il veut. Ni qu'il est maitre à bord, loin de la.
Ensuite, la partie sur "le comité est rempli d'anciens de Red Hat er de Canonical" est fausse. Il y a 2 personnes de Canonical et 1 ancien, et c'est tout. Et en relisant les débats, c'est eux qui étaient contre systemd.
Ensuite, l'argument visant à faire croire qu'il s'agit d'une prise de pouvoir militaire comme en égypte est ridicule, car le pouvoir en question a toujours été la. Comparer le fait de bannir les gens avec le fait de se faire tirer dessus est aussi risible.
Mais ce qui me fait le plus tiquer, c'est de faire remarquer que tout est parti en sucette il y a 8 ans quand ils ont virer les gens qui disent du mal des femmes, donc ils sont contre la liberté d'expression ( vous savez, la liberté d'expression qui consiste à harceler les gens sur internet par exemple ).
Sachant que le mec a juste ouvert un compte pour poster ses théories fumeuses, dire qu'il s'agit d'un faux compte est un pas que je franchirais allégrement.
Tout colle, l'obsession a redire encore et toujours les mêmes trucs faux sans la moindre preuve, le fait de se positionner en martyr sur la base de choses non vérifiables, les insultes ( "these people are bastards" suite à son banissement ).
Et bien sur, les bonnes vielles habitudes :
http://www.debianuserforums.org/viewtopic.php?f=63&t=3055&p=29240&sid=55b6af469344f5ee822a9b3ba8404de4#p29237 et http://www.debianuserforums.org/viewtopic.php?f=12&t=3064 )
Mais il y a plein de perles, comme quand le mec tente quand même de dire que c'est pas important de mettre à jour, car y a grsec et pax, et apparmor. Bien sur, personne ne va lui dire qu'une technique de contournement de pax a été publié ( http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf ).
[^] # Re: Autant qu'ils forkent
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 4.
Alors, tu es sur du nom ? Parce que la, je tombe sur un truc d'oracle dans Google.
Et sinon, oui, le souci des discussions constantes sur le sujet est que le niveau technique et les propositions sont au raz des pâquerettes. Ayant lu debian-user@, ça vole pas haut et les gens comprennent pas pourquoi ils veulent pas certaines choses, mais ils sont sur de pas le vouloir.
Il y a sans doute plein de possibilités, mais comme une bonne part des gens semblent fatigués par le sujet qui polarisent une part des utilisateurs, les gens capables de discuter se résignent.
Bien sur, toute tentative de ramener le calme est vu comme "les pro systemd veulent nous faire taire" ( ce qui est vrai, quand quelqu'un a dit 15 fois que c'est une conspiration, la 16eme est du bruit inutile ) et ça repart de plus belle.
[^] # Re: Beaucoup de bruit
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 2.
Je ne doute pas le moins du monde que la raison derrière ce souci soit valable et rationnel. Même si tu m'avais dit "on a retiré haproxy car on avait personne pour s'en occuper", j'aurais trouvé ça acceptable, ça fait parti du jeu des distros communautaires ( voir même commercial, avoir un peu plus de ressources implique pas d'en avoir une infinité )
Je fait confiance aux gens du libre pour faire des choix avec une bonne raison, même si parfois je peux ne pas être d'accord.
Mon point est juste que l'argument de jamais avoir de changement ou de régression est une vison idéalisée. Un autre exemple est selinux, et je pourrais raler sur le fait de pas avoir eu de réponse sur mes rapports de bugs sur la stable ( avec 2 patchs ), mais si y a personne pour faire le taf sur la stable, bah tant pis pour moi :)
[^] # Re: Autant qu'ils forkent
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Je pense que garder sysvinit n'est en effet pas le plus gros souci. Le souci, ça va être de convaincre les packageurs de garder les scripts d'init dans leur paquets, et de corriger les potentiels bugs. Et bien sur de garder et corriger les trucs de démarrage en shell ( ie, tout /etc/rcS.d/* ) si besoin. Et sur le point des bugs, je suis rassuré de voir que je suis pas le seul à citer le script de bind comme exemple de script buggué par design ( genre, y a un mec qui cite ça sur lwn ).
Et donc je pense que comme systemd élimine quand même une bonne classe de comportement problématique grace au démarrage dans un env clean, il est attractif pourles packageurs de convertir les paquets.
Par exemple, j'ai parlé avec un des devs de fusion inventory , qui m'a dit que le passage à systemd a permis de liquider 1/3 des bugs sur launchpad, cad tout les bugs à la con avec le fait qu'un des processus meurt et pas un autre, etc.
Donc sur la base de ce genre de besoin, je pense que le chemin qui marcherait serait de pousser openrc ( car portable, et encore en cours de dev ), et le rendre capable de lire les fichiers de systemd, et/ou trouver comment faire des scripts d'init depuis les fichiers de systemd ( cf projet gsoc ).
Du coup, les gens qui veulent pas systemd auront une alternative. Les gens qui veulent des scripts auront leur truc en shell, avec sans doute moins de variations. Et la charge de travail pour les packageurs resteras raisonnable.
Bien sur, ça ne régle le souci que pour la partie "init". Il resteras encore le souci pour logind et la subsistance de systemd-shim sur le long terme.
Tout ça, je pense que ça aurais pu se faire durant les mois depuis le premier vote et maintenant par quelqu'un d'assez motivé et compétent, avec assez de temps. Je ne me prononcerais pas sur le fait que ça ne soit pas arrivé pour le moment, malgré tout ces gens qui sont prêt à protester.
Sinon, c'est aussi une bonne nouvelle pour debian lts, car je suis sur que tout ces gens vont mettre la main à la poche pour financer la survie de la stable courante pour éviter le piége systemd, bien sur.
[^] # Re: Beaucoup de bruit
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 7.
Bah, je pense qu'il a le droit d'avoir un avis différent du mien :)
Je pense qu'en effet, un apport de gens motivés pour les BSD serait une bonne chose. Je suis par contre pas forcement sur que les gens qui ralent sur systemd dans debian soient dans leur grande majorité ce genre de gens. Il y en a sans doute, et il y a des gens qui ont des critiques valables, et qui tombent sur des bugs et des régressions ( keyscript et luks, par exemple ). Ensuite, ça serait pas la première regression dans debian ( le fait de retirer haproxy dans la dernière stable par exemple ), c'est des choses qui arrivent à tous.
Et bon, ce genre d'article :
http://www.vitavonni.de/blog/201410/2014101801-beware-of-trolls---do-not-feed.html
ça me rappelle quand même south park ( l'épisode sur le drapeau ).
[^] # Re: Autant qu'ils forkent
Posté par Misc (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Idéalement, voir même installer un forum sur leur site, histoire que les gens puissent se concerter et proposer une communication construite.
Je serait le premier à lister des soucis de systemd si on me demande ( la dépendance aux cgroups était par exemple un souci sur mes VPS sans le support dans le kernel, bien que ça soit corrigé via un patch upstream ), mais j'ai relu tout les threads de debian-user, c'est extrêmement peu précis. Il y a des bugs, il y a une features bien spécifiques sur la crypto qui semblent ne pas marcher, mais le reste c'est des gens veulent pas parce qu'ils veulent pas. Y a un mec qui poste pour dire que c'est plus compliqué à réparer pour lui. C'est sans doute vrai, il faut d'autres connaissances que le shell, mais je ne voit personne faire ce genre d'argument vis à vis de tout le reste des choses en C ( à part le projet olpc, qui a tout fait en python pour laisser les gens lire le code ).
une bonne part semble agiter le spectre de "ça ressemble à windows" et "Red hat va contrôler le monde du libre avec ça". Mon favori reste quand même le mec qui postule que systemd est la pour rendre les choses plus compliqués afin de vendre plus de services et de consulting via des techniciens "forcement" certifiés par RH.
Donc je pense que faire un groupe de discussion avec quelqu'un pour répondre point à point et garder les remontés valables ( par exemple, améliorer les messages d'erreur pour rendre les fichiers d'unités plus facile à debugger en essayant de voir ce qui fait que les gens trouvent ça difficile à debugger ) serait positif.
Actuellement, ça part plus dans l'outrage personnel à base de reprendre le concept de "linux is about choice".
[^] # Re: L'empreinte digitale n'est pas sans soucis
Posté par Misc (site web personnel) . En réponse au journal Identification versus authentification : l'embrouille de Zwipe et Mastercard.. Évalué à 3.
La question est pas de savoir si il y a ou pas des pertes de temps, c'est de savoir si il y en a significativement plus ou moins, si le fait de corriger le souci est plus ou moins couteux pour la banque ( genre, si mon doigt est sale, je le lave, le cout de la banque est proche de 0 ), et si c'est plus facile de copier une empreinte digital qu'un code à 4 chiffres.
Ensuite, il y a aussi un moment ou il faut expérimenter à grande échelle après avoir fait des pilotes qui ont du se révéler constructif.
[^] # Re: Sans code
Posté par Misc (site web personnel) . En réponse au journal Identification versus authentification : l'embrouille de Zwipe et Mastercard.. Évalué à 3.
Non, j'ai payé un sandwich chez subway, j'ai été horrifié de ne rien signer et de ne pas taper de code. On m'a dit que c'est normal quand le montant est petit.
Du coup, je pige mieux pourquoi les gens paniquent quand Target et autres se sont infiltrés.
[^] # Re: On ne connait pas les mêmes personnes
Posté par Misc (site web personnel) . En réponse au journal Identification versus authentification : l'embrouille de Zwipe et Mastercard.. Évalué à 5.
Moi, j'ai déjà eu un blanc sur mon numéro de carte bleue. Depuis, j'ai toujours du liquide sur moi en cas de problème.
J'ai aussi une carte pro et je l'utilise pas assez souvent pour garder les 4 chiffres en tête. Du coup, j'ai une solution compliqué pour les retrouver.
Si je pouvais me contenter d'utiliser mon doigt au lieu de devoir mettre ma tête à contribution pour faire obtenir du liquide, ma vie serait vachement mieux.
[^] # Re: ProFTPd, NGinx
Posté par Misc (site web personnel) . En réponse à la dépêche CVE-2014-3566 — Vulnérabilité POODLE. Évalué à 4.
J'ai du mal à piger en quoi une attaque qui requiert que l'attaquant fasse des requetes actives ( ie, la partie ou le js intervient dans le papier ) va marcher pour openldap ?
Quel client va poser souci, dans quels conditions ?