pmeunier a écrit 108 commentaires

voir un accès root gratuit si le souci de config est au niveau de sshd lui-même.

(je suis l'auteur de Thrussh, et un des auteurs de Pijul)

Ça a été ma principale motivation pour écrire Thrussh. Avant, Pijul marchait à travers le client OpenSSH. Et même en temps qu'utilisateur de NixOS et NixOps, je ne sentais pas trop la configuration d'un serveur OpenSSH qui fasse appel à une base de données pour vérifier les clefs des utilisateurs, et serve en même temps pour ouvrir un shell.

Nest.pijul.com a un serveur Thrussh qui écoute les clients demander une ouverture de session, l'exécution d'un programme, mais ne fait rien de tout ça, et se contente de faire croire au client qu'il l'a fait. Quand un client présente une clef, le serveur vérifie qu'elle est dans la base de données. Ensuite, quand il demande une commande shell, le serveur la parse avec une regexp, appelle la fonction correspondante, et renvoie un code d'erreur.

La principale idée est que le code qui a le moins de failles de sécurité est celui qui n'est pas écrit.

Après, quand tu as écrit un serveur, écrire un client n'est pas bien difficile, et ça permet de tester plus en détail. J'ai récemment été assez content de voir que j'avais raison de me méfier des solutions existantes (https://www.cvedetails.com/cve/CVE-2018-10933/). Écrire de l'asynchrone en Rust te force à définir proprement l'automate du protocole, ça évite ce genre de blagues par construction (il y a sans doute plein de trous de sécurité que ça n'évite pas, hein).

Voila qui devrait aider a ce que tu comprennes mes doutes.

Merci d'avoir pris le temps d'utiliser des arguments, ça marche mieux !

J'ai bien pris note du fait que C était un langage bas niveau, et avec une histoire un peu longue.

Maintenant qu'on a bien discuté des trucs pas très jolis de C, en quoi cela permet-il de contester mon argument initial auquel tu sembles t'opposer, à savoir : C a marché parce qu'il était plus puissant et plus facile à apprendre que ses prédécesseurs ?

PAM est une système modulaire pour gérer l'authentification sur des machines Unix. Certains de ses modules parlent avec des serveurs LDAP, d'autres comprennent les tickets Kerberos, etc.

Le module le plus commun consiste à gérer l'authentification par mot de passe, mais dans le contexte d'une grosse organisation, ça devient vite très limité : les gens veulent se connecter sur plusieurs machines, parfois à distance et avec plusieurs protocoles (SSH, IMAP, etc.), veulent changer leur mot de passe, accéder à des services web avec le même mot de passe, etc.

Je ne sais pas qui utilise Slackware dans ce genre de contexte.

ça m'a toujours eu l'air vachement complexe et lourd, un peu trop peut-être pour être vraiment sûr

Oui, mais dans une grosse boîte ce n'est pas un gros problème : il y a des équipes pour le sécuriser. Dans mon cas, je n'ai pas ça. Et même si j'avais plus de gens sur le projet, je préférerais qu'ils travaillent sur d'autres trucs.

Il est vrai que prendre C et Unix comme point de comparaison est étrange

Je n'ai pas comparé Pijul à C. Il faut replacer mon commentaire dans son contexte. J'ai utilisé cet exemple pour montrer que la difficulté d'utilisation n'était pas une condition nécessaire à la puissance d'un outil, et que C a vite remplacé ses prédécesseurs parce qu'il était beaucoup plus facile à utiliser sans être moins puissant.

Bien entendu, aujourd'hui, après plein d'innovations sur les langages, et d'innombrables couches de re-standardisation, certaines des idées de C et d'Unix ont perdu de leur élégance, semblent moins canoniques ou un peu vieillottes.

Ça n'enlève rien à mon argument, puisqu'il se référait justement à l'époque où C est sorti.

quand on sait que le créateur de git n'est autre que Linus Torvalds

Je n'ai jamais nié les compétences techniques ou la vision de Torvalds. Mais je sais ne pas être seul à juger Unix (et C) élégants et Git pas du tout élégant. Il ne me semble pas choquant que des superstars de l'implémentation de systèmes d'exploitation (qui ont toute mon admiration) ne soient pas nécessairement experts en théorie de la concurrence.

(on pourrait aussi remarquer que Linus Torvalds n'a créé ni C ni Unix)

Bien que j'ai déjà lu des personnes défendant la position (qui se tient) que C est un langage fonctionnel pur.

Je ne sais pas si c'est une blague, mais si je lis ce lien, j'y trouve cette phrase :

As with any purely functional language, cpp consists only of (nestable) expressions, not statements. Now here’s the clever part: when evaluated (not executed), a cpp expression yields a (pure) value of type C, which is an ADT (abstract data type) that represents imperative programs.

Ça me semble faux : en CPP, suivant l'ordre d'évaluation des macros, on peut tomber sur du code différent (avec des sémantiques différentes).

Affichage de chaînes de caractères: printf, puts. Idem pour la lecture.

C'est pour ça qu'il y avait un "souvent" dans ma phrase. Je suis totalement d'accord que les entrées-sorties en C sont la principale raison pour laquelle ce n'est pas un "toujours".

Je suis d'accord qu'il y a plein de petites fonctions pour simplifier le code (puts/printf), et surtout une double API très moche sous Unix entre les pointeurs et les descripteurs de fichiers (open / fopen).

Passer plusieurs données à une fonction? Variadic arguments, pointeurs sur listes.

Ça ne fait pas vraiment la même chose, les listes sont sur le tas, les arguments sur la pile. C sert d'abord à manipuler finement la mémoire, non ?

je ne connais pas assez l'API des kernels pour juger, mais je doute fort que les choses ne puissent se régler que d'une seule façon

Vu que j'ai un peu utilisé Unix dans ma vie, je doute un peu de tes doutes.

On tourne en rond. Je te dis que git est génial pour des choses qui n'ont rien à voir avec la théorie des patchs, et tu me rétorques qu'il lui manque la théorie des patchs…

Je comprends que ça pouvait être mal interprété. C'était uniquement un exemple d'un principe sur lequel Git pourrait être basé. On n'a pas besoin de théorie des patchs pour avoir l'associativité. Peut-être qu'il existe une alternative à 3-way merge qui est associative.

Ceci dit, cette question est étrange : les gens qui croient que Git donne certaines garanties à l'utilisateur devraient être en mesure d'énoncer ces garanties (garanties = axiomes = principes), plutôt que l'inverse.

Mais j'avoue que je n'aime pas trop tes arguments se rapportant à « on a discuté avec des gens qui savent, et vous ne pouvez pas comprendre leurs problèmes », en gros, si je caricature.

C'est une caricature d'autant plus grossière que j'avais énoncé quelques unes des raisons factuelles pour lesquelles un très gros utilisateur pourrait ne pas vouloir de Git, et que des liens vers des blogs de Facebook et Google ont été postés dans la même discussion (pas par moi).

Moi par exemple je kiffe le design orienté format de données plutôt qu'API

Là-dessus, on est totalement d'accord. À tel point que Pijul est exactement ça : une nouvelle structure de données, dont la principale nouveauté est d'être tolérante aux conflits.

(dire qu'on ne retrouve pas les concepts d'Unix dans git, inventé par le créateur de l'Unix libre majoritaire aujourd'hui… je comprends pas)

Je suis d'accord qu'il y a un peu de l'esprit Unix dans Git. Par exemple, le fait que beaucoup de choses soient accessibles avec des scripts shell.

Mais Torvalds n'a pas inventé C et Unix (et c'est un argument d'autorité).

Du point de vue des concepts, les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose (je ne parle pas des commandes shell, qui sont une petite partie du design d'Unix, mais plutôt des appels systèmes), un petit nombre de concepts avec des rapports clairs et déterministes entre eux. Si tu prends deux concepts quelconques d'Unix ou de C, ils ne seront jamais liés par une heuristique qui peut parfois se planter. Exemple : mmap n'utilise pas une heuristique pour savoir s'il doit mapper un seul fichier, ou deux l'un au-dessus de l'autre (cet exemple est tiré par les cheveux, mais comme Unix est designé très rigoureusement, on ne peut pas trouver ce type d'exemples).

Dans Git, ce n'est pas le cas pour tout. Par exemple, il y a plein de façons de faire ce qu'on veut (de l'aveu de Torvalds lui-même).

Un autre exemple, on voit régulièrement des explications de Git pour des débutants qui commencent par "un commit n'est pas un patch" (plutôt que de dire ce que c'est), on voit plus rarement des explications d'Unix qui commencent par "un fichier n'est pas …" ou "un pointeur n'est pas …".

C'était une blague, même si elle n'était pas drôle. Désolé.

Bon, vu les commentaires d'autres sur ce fil, je ne pouvais pas trop savoir. Désolé !

En quoi ce commentaire est-il constructif ?

Si tu avais lu le commentaire auquel tu réponds, tu n'écrirais pas ça. Mais je peux répondre à ce que tu dis :

Moi aussi je trouve plus simple d'écrire 5000 lignes de code (orienté crypto qui plus est…) que d'installer le serveur OpenSSH packagé par ma distrib

Ce que tu écris est faux : Windows, une "distrib" très courante, ne package pas le client d'OpenSSH.

5000 lignes, ce n'est pas Thrussh, c'est les bindings que j'avais entrepris vers Libssh, une bibliothèque C existante qui implémente SSH. La prochaine fois, essaie de lire avant de répondre.

qui fournit une config maintenue et sécurisée.

Oui, pour un cas d'utilisation complètement différent du mien. Je veux que mon serveur accepte des patchs, ne fasse rien d'autre, et vérifie les mots de passe et les clefs avec une base de données.

OpenSSH ne fait pas ça. La combinaison OpenSSH + shell + pam + dix modules de pam fait peut-être ça, après plusieurs semaines à temps plein de configuration.

En plus quand je comprends pas l'install et la config de 50 lignes d'un serveur, il est évident que je ferai mieux en l'écrivant moi-même…

Autre exemple de mépris, et autre exemple d'ânerie : la configuration d'OpenSSH avec PAM pour parler à PostgreSQL, avec toutes les barricades pour éviter que le client ne fasse des trucs louches avec les commandes shell, ce n'est pas 50 lignes, ça ne s'écrit pas en deux minutes, et ce n'est pas facile à sécuriser.

En plus, il est hors de question pour le Nest de laisser OpenSSH lancer Pijul à chaque commande. Le Nest est asynchrone, et Pijul prend un lock sur le dépôt, ce qui bloquerait au moins un thread du serveur (très grave en asynchrone), et potentiellement le serveur entier, à chaque fois que quelqu'un pousse un patch.

Un détail non-technique : je comprends qu'il soit tentant de juger Pijul en discutant des détails d'implémentation de Git.

Ceci dit, pour être cohérent, il faudrait aussi éviter de dire d'énormes âneries sur des concepts élémentaires d'informatique ("élémentaires" dans le sens "essentiels", pas forcément "simples"). Par exemple, la décidabilité, ça a une définition précise.

Ou sinon, quand tu écris

Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat.

Je veux pas te provoquer de douleur psychique à base de dissonance cognitive, mais, breaking news, dans ce cas de figure (modifications non colocalisées) git fera la même chose !

C'est complètement faux, dans tous les cas. Git n'est jamais commutatif, au contraire : il ordonne scrupuleusement les commits, c'est même sa principale utilité.

C'est une différence fondamentale entre Git et Pijul : Pijul a un nouveau type de structure de données qui rend la commutativité possible, et cette structure de données est même l'idée centrale (les merge corrects dans 100% des cas sont importants, mais moins).

Il aurait fallu mieux comprendre l'argument avant de le mépriser : ça m'étonnerait que tu penses que les commits de Git commutent, d'ailleurs tu as parlé de graphes orientés acycliques dans un autre commentaire.

Ceci n'est pas une critique sur le fait de dire des âneries (c'est cool de se laisser le droit de dire des âneries, de l'accepter et de le reconnaître), mais uniquement sur le mépris.

Autre exemple du même mépris : toute boulangère ou boulanger qui se déplace de chez lui à sa boulangerie en passant par des rues a chaque jour une expérience directe des graphes orientés, avec des étiquettes sur les arêtes.

Cet exemple est loin d'être anodin : le seul truc que Pijul essaie de faire, c'est de modéliser proprement l'expérience directe et quotidienne de millions de programmeur, et d'implémenter une théorie conforme à leur expérience quotidienne directe.

Les deux types de mépris (envers "la boulangère" et envers Pijul) se ressemblent étrangement, non ?

J'ajouterais un petit détail technique supplémentaire : les conflits dans Git sont bien un truc qu'il "essaie" de résoudre, parce que 3-way merge est une heuristique.

De plus, certains conflits sont provoqués par l'outil lui-même, comme par exemple quand on cherry-pique plusieurs fois depuis la même branche.

Dans Pijul, au contraire, les conflits sont définis clairement. Ce n'est pas un truc qu'il "n'arrive pas à faire et doit jeter l'éponge", mais au contraire une situation normale. Et c'est d'ailleurs la solution raisonnable : si un outil de résolution automatique de conflits sur du texte était possible, on pourrait essayer de l'appliquer sur des textes produits par des Israéliens et des Palestiniens.

je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml.

Ok. J'ai oublié aussi autre chose : Rust n'a pas de GC, mais un système de propriété des variables qui est très marrant à utiliser.

Sur les threads: "ce n'est pas la bonne façon de programmer" est bien le genre de réponses auquel je faisais référence. Même les téléphones portables ont des tas de cœurs, et la communauté OCaml est encore en train d'expliquer à qui veut l'entendre que ce n'est pas la bonne façon de programmer.

Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ?

Je te cite :

Genre le système sous-jacent exposé et exploitable, les formats de données simples et centraux, l'état du VCS exposé dans le filesystem, l'utilisation en shell facile (pas mal de fonctions de merge de git sont même juste du shell !).

En gros: trop bien, on peut aller le bricoler. Sauf qu'on n'a essentiellement besoin de le bricoler parce qu'on se retrouve dans une situation pourrie à cause du manque de théorie solide dessous.

Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ?

Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.

Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici

Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".

WTF2 ?! Git ne stock aucun diff lié à un commit

C'est vrai, j'ai écrit ça un peu tard et en décalage horaire, excuse-moi, ça fait bien longtemps que je n'ai pas regardé les entrailles de Git.

Ceci dit, ça n'enlève rien à mon argument, au contraire : le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.

Après, je vois qu'on a une idée du design logicielle assez différente

Plus de détails !

je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.

Ce n'est pas exactement ce que j'ai dit dans mon commentaire précédent ? À part le fait qu'on ne retrouve à mon avis pas les concepts d'Unix dans Git, pour les raisons que j'ai déjà données, et que tu n'as pas vraiment commentées directement (à part à coups de WTF sur mes imprécisions techniques, et de "Git est mieux de toute façon").

je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi

C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.

Le mieux serait que pmeunier expose ses raisons, mais il est peut être passé à côté de la question.

J'ai bien vu la question, mais j'ai espéré jusqu'au bout qu'on n'allait pas me demander de commenter ce choix ;-)

Comparer des langages de programmation est difficile, et il est facile d'être mal interprété. Je ne vais donc pas comparer, et seulement dire des trucs que j'aime bien dans Rust.

• Windows est supporté comme une plateforme considérée comme standard par l'équipe de développement. Notre ambition, c'est de mettre le contrôle de version à la portée de tous, en restant aussi puissant que Git. Exclure les utilisateurs Windows nous éloigne de cet objectif.

• La communauté Rust est géniale et croît rapidement, il est facile de parler de Rust en dehors de la France.

• On peut écrire des trucs comme Sanakirja (le backend de Pijul) en Rust, qui a besoin de manipuler des chaînes de caractères sur la pile (sans avoir à écrire du C et des bindings).

• Il y a une vraie culture crypto dans la communauté Rust, ce qui permet d'apprendre rapidement et de discuter.

• Petits détails techniques : compiler des programmes en Rust est très facile, et il y a des threads (et personne pour nous expliquer que ce n'est pas la bonne façon de programmer).

Au fait petite suggestion, si jamais vous voulez que votre outils soit adoptes il doit y avoir un moyen de communiquer et d'echanger au minimum avec git (dans les deux sens).

Oui, bien entendu. D'ailleurs on a déjà commencé à écrire ça.

Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents.

Git ne conserve pas toujours suffisamment d'information pour pouvoir importer l'historique correctement, mais on peut très bien imaginer un outil qui marche dans suffisamment de cas.

Eh bien qu'ils partagent leurs raisons.

Il y avait les raisons dans mes commentaires précédents, ce n'était pas un argument d'autorité.

Les arguments d'autorité ne servent à rien, à part envenimer la discussion.

Mon commentaire était en quelque sorte l'inverse d'un argument d'autorité : "ne jette pas les arguments de quelqu'un que tu ne considères pas comme une autorité, il y a plein de gens qui disent la même chose, on peut peut-être considérer leur opinion".

tu pourrais passer à côté des choses géniales que tu ne remarques même pas.

Encore une fois, si on a commencé Pijul, c'est qu'on connaissait suffisamment bien Git pour en être insatisfaits.

Une partie des "avantages géniaux" que tu évoques sont utiles uniquement parce qu'ils permettent de compenser les problèmes posés par le manque de principes solides dessous.

Mais il y a aussi plein de trucs absolument géniaux dans Git ! Je n'ai jamais dit le contraite ! À commencer par la vitesse, designer des algos avec le potentiel pour le battre en vitesse a été vraiment intéressant.

Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git

Suggestion : suppose que les ingénieurs de Google et Facebook (et plus généralement les gens avec qui tu parles, dont moi) connaissent ces options quand ils disent ce type de trucs.

Les shallow clones améliorent un peu ce problème dans certains cas, en particulier ils permettent de compiler le projet, mais pas forcément de "travailler" sur le projet, comme par exemple de fusionner des commits qui ont divergé depuis plus longtemps que la profondeur.

Et chaque commit a besoin de calculer un hash de tout le dépôt, même si ce n'est que pour un seul fichier (j'imagine que ce n'est pas le principal souci, même dans une grosse instance).

C'est drôle que tu prennes l'exemple du C, parce que justement il a une courbe d'apprentissage un peu rude quand même, il n'est pas parfait, et j'aurais donc fait le parallèle avec git.

Je n'ai pas pris C au hasard. Encore une fois, la courbe d'apprentissage n'est pas toujours égale à la puissance de l'outil.

C est certes difficile à maîtriser, mais il est basé sur un petit nombre de concepts simples (fonctions, variables, pointeurs, préprocesseur) et orthogonaux, qu'on peut expliquer facilement, ce qui n'était pas le cas des langages d'avant.

Git a un point commun avec C, le petit nombre de concepts (branches, commits, trees).

Par contre, il est très différent de C sur deux points :

• ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.

• les relations entre ces concepts sont compliquées et floues, voire incohérentes : par exemple, les fichiers sont rebricolés à partir du contenu par des heuristiques, et les merges entre branches sont faits par 3-way merge, qui n'est pas associatif (pas associatif = des lignes ajoutées par Alice se retrouvent dans un morceau que Bob a écrit indépendamment).

Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds »

Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.

Torvalds lui-même le considère comme très imparfait, même si je suis d'accord que Git a connu un développement impressionnant (j'ai l'impression que c'est en très grande partie grâce à GitHub).

Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.

Cependant, je suis convaincu que ça en vaut la peine.

Je n'ai aucun problème à apprendre des trucs. Dans la vie, je suis chercheur : mon métier est d'apprendre des trucs qui n'ont pas de courbe d'apprentissage connue.

Pour des outils standards et connus, je n'ai pas non plus de problème, mais seulement quand ça vaut le coup.
Si tu as besoin d'exemples, regarde les langages qu'on utilise (Rust, Nix) et les dépendances de Pijul qu'on a dû écrire (Sanakirja, Thrussh).

Par exemple, il est beaucoup plus difficile d'apprendre le monocycle que le vélo. Si l'objectif est de se déplacer, ton commentaire ressemble à "oui mais le monocycle est plus difficile à apprendre, donc il est forcément plus efficace".

Pour les cas désespérés, il y a toujours https://git-man-page-generator.lokaltog.net/

Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose…

C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.

Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.

soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration

Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts, parce qu'il a besoin de tout l'historique de tout pour fonctionner.

Et ces gros industriels veulent de très gros dépôts parce qu'ils ont plein de projets interdépendants compliqués à compiler.

(même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique)

Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.

Oui, c'est vrai. Apparemment j'ai oublié comment était la vie avant l'administration système à distance ;-)

Sur la distinction protocole SSH / serveur OpenSSH, c'est totalement vrai. Par contre, pour le coup de la clef sans mot de passe, je ne suis pas sûr de suivre : tout ce que fait le mot de passe est de crypter la clef secrète sur le disque. Si ton disque est déjà crypté, c'est redondant, parce que le noyau linux remplit alors exactement le même rôle qu'un agent SSH,
avec cryptsetup comme interface (sauf que le noyau tourne en root, ce qui protège même un peu mieux la clef).

Sur les gros hacks de HTTP, je suis totalement d'accord. Les websockets sont un autre exemple de trucs pour lesquels le protocole n'était clairement pas prévu.
Mais HTTP 2 résout une partie des problèmes de performance de HTTP 1/1.1, et c'est vrai que plein d'entreprises ont des systèmes d'authentification basés sur les hacks en question. Étant donné que le principal argument de Pijul pour des entreprises d'une taille suffisante pour utiliser ce type de hacks est "on passe à l'échelle bien mieux que Git", je suis d'accord que ça vaut le coup de s'y préparer.

Le seul truc un peu relou pour l'instant étant la transition "je récupère un cookie/ticket SSO dans mon navigateur, et je le file à Pijul en ligne de commande".
Notre objectif (on n'y est pas encore) est que n'importe quel débutant en programmation soit capable d'utiliser Pijul sur son premier projet, et qu'il n'ait (presque) rien à apprendre ensuite, même pour aller travailler sur un énorme projet propriétaire.

Merci pour les références ! Mon problème d'interface utilisateur était essentiellement lié à l'authentification (je ne connais pas grand chose à tout ça en HTTP).

Effectivement, c'est envisageable.

Oups, je me rends compte que j'avais oublié autre chose : les performances de HTTP <= 1.1 n'égalent pas SSH, qui a des paquets binaires, le multiplexage de flux, et les connexions ouvertes longtemps (websocket est un peu un hack, quand même).

Avec HTTP 2, on pourra comparer.

Tu peux déjà avoir une infra qui toute la chaine d'authentification en place pour HTTP (LDAP, Kerberos, TLS client…) .

Bonne remarque. Mais sauf si j'ai loupé un truc, la question n'est donc pas "je voudrais bien pousser en HTTP", mais plutôt "je voudrais bien que Pijul gère les cent-cinquante standards différents d'authentification en HTTP".

Ou alors il doit y avoir un moyen générique de faire faire ça à un proxy ? Je serais bien content d'avoir une référence à lire sur le sujet.

On arrive bien à faire du TLS client, du Kerberos, du 2factor, du Yubikey en SSH en ligne de commande.

On pourrait certes y arriver, mais ce n'est quand même pas (à mon avis) le même degré de complexité. SSH est un seul protocole, qui comporte trois façons de s'authentifier (password, public key, none), plus une extension très utilisée (keyboard-interactive, utilisée par OpenSSH pour les mots de passe à la place de password).

Tout est spécifié de manière extrêmement précise dans une seule RFC (plus l'extension dans une autre RFC), et on a déjà une bonne sécurité une fois qu'on a ça. C'est tellement facile à implémenter que les implémentations les plus utilisées ont des failles de sécurité qui se comptent sur le doigts de la main, alors qu'OpenSSL a un très gros problème par an, et plusieurs petits chaque mois.

Je me sens nul…

C'est pas trop l'objectif.
Au contraire, viens coder avec nous, il y a du boulot !

Très bonne remarque. Note que nest.pijul.com, notre service d'hébergement, a évidemment une partie HTTP. Il contient aussi un petit serveur SSH maison qui ne sert qu'à ça. Il est impossible d'ouvrir une session pour "faire de l'administration" dessus, non pas parce qu'il est "très bien sécurisé", mais parce qu'il ne gère pas un paquet de trucs, entre autres les sessions.

La bibliothèque elle même saurait les gérer, mais le serveur ne contient pas le handler qui permettrait d'ouvrir un pseudo-terminal ou une session.

Note d'autre part que SSH est un protocole bien plus général que ce qu'on lui fait souvent faire : il a deux ou trois commandes pour ouvrir des sessions et renvoyer des ports TCP, mais il sait aussi envoyer des données arbitraires sans avoir besoin d'une session, d'un shell ou d'un programme autre que le client et le serveur.

À la dernière RustFest, j'avais par exemple live-codé un prototype de communication entre microservices.

Pour répondre à ton commentaire, depuis Pijul, on peut cloner ou puller depuis HTTP, mais pusher seulement par SSH.
On aura peut-être des pushs par HTTP dans le futur (et on accepte très volontiers une contribution là-dessus, même si ce n'est "que" du design), mais il y a plusieurs inconvénients aujourd'hui au niveau de l'expérience utilisateur :

• J'ai du mal à voir un cas de figure précis où on voudrait ça. Si tu as une machine dans le cloud par exemple, d'où viendrait le serveur HTTP capable de gérer ça ? Et pourquoi avoir besoin d'une authentification/proxy très sophistiquée ? Pourquoi SSH ne serait pas suffisant ? Faire de l'UX sans cas un peu précis, c'est compliqué. Mais je suis ouvert à la discussion là-dessus.

• S'authentifier en HTTP est compliqué, et nous n'avons pas encore imaginé de manière de rendre ça fluide en ligne de commande (c'est quand même le principal objectif du projet). Dans un navigateur, il y a plein de manières de s'authentifier : SSO, OAuth, Mots de passe, Yubikeys, pseudo-2-factor avec un téléphone, gestionnaires de mots de passe… Comment on fait ça en ligne de commande ?

apt install openssh-server ou équivalent c'était trop compliqué, donc pour faire plus simple je réimplémente SSH ? Si la page Wikipedia pour NIH avait besoin d'une illustration, elle est servie.

Ce n'est pas du tout ce que j'ai écrit dans mon commentaire. D'abord il y a d'autres raisons que j'ai expliquées, par exemple au sujet de Windows. Était-ce "trop compliqué" de lire ces lignes dans mon commentaire avant de répondre n'importe quoi ?

Ensuite, le cas précis de mon serveur est particulier : je veux pouvoir laisser n'importe qui envoyer des patchs, ou enregistrer une nouvelle clef publique, par SSH. Je veux aussi que mon serveur tourne vite. En fait je veux qu'il tourne super vite. Et d'ailleurs ses utilisateurs le remarquent ici ou là.

Pour ça j'ai besoin de plusieurs choses :

• Un contrôle total sur les interactions entre le client et le serveur, alors qu'OpenSSH ne me permet que de lancer un exécutable à distance. Je veux aussi pouvoir enregistrer les clefs de l'utilisateur s'il m'a donné un password correct, par exemple, et s'il me confirme qu'il veut enregistrer sa clef. OpenSSH ne me permettrait de faire ça qu'à grands renforts de scripts pour parser les logs, qu'il serait difficile à intégrer au reste du service, à moins de hacks qui finiraient par casser rapidement.

• Une connexion avec une base de données. Les clefs publiques des utilisateurs ne sont pas stockées dans un fichier, mais dans une base de données PostgreSQL.

• Une interdiction absolue de faire quoi que ce soit d'autre que les trucs autorisés. Je ne sais pas sécuriser ce type de trucs, il y a trop de pièges qu'on peut envoyer dans des arguments de shell, et ça nécessite une équipe pour veiller dessus, quand on veut faire les choses bien. Pareil pour les mécanismes d'authentification : OpenSSH peut certainement utiliser des tas de modules pam, mais je ne sais pas faire, et les experts de ça que je connais y ont passé dans leur vie environ 100 fois le temps-homme que Thrussh, et il reste encore sans doute plein de failles dans leurs configurations.

• Je veux une performance de ouf sur mon serveur. Fork + exec de la part d'OpenSSH serait déjà beaucoup, et je ne parle pas du changement de contexte entre process à chaque connexion.

Maintenant j'ai tout ça à la fois, avec en prime des trucs de sécurité intéressants fournis par l'IO asynchrone, comme des délais avant accept() de plus en plus grands quand les connexions n'aboutissent pas à une authentification réussie.
Avant de commencer j'avais un peu discuté avec un ingénieur de chez SSH (l'entreprise finlandaise) quand j'habitais à Helsinki, ce qui a un peu achevé de me convaincre.

Et déléguer tout ça à OpenSSH (comme le fait Git, sous GNU/Linux du moins), ce n’était pas envisageable ?

Excellente question ! D'autant que je suis moi-même un utilisateur de Yubikey, et j'ai une clef SSH cryptée avec.
En fait j'aurais même pu déléguer à libssh et/ou libssh2. Il y a eu plusieurs raisons à ce choix :

• OpenSSH ne marche pas bien sous Windows. Des projets avec peu de moyens d'ingénierie, comme par exemple Darcs, sont empêtrés là-dedans depuis des années.

• J'avais https://nest.pijul.com en tête quand j'ai commencé à écrire Thrussh. Maintenir une version d'OpenSSH à jour et sécurisée sur un serveur distant était une tâche au-dessus de mes compétences en administration système, et du temps que nous pouvions passer à l'administration. En fait, j'ai commencé par écrire un binding Rust vers la partie serveur de libssh. Au bout de 5000 lignes de bindings, de cheveux arrachés à lire leur code C (la doc n'existe presque pas), et toujours pas de serveur en vue, j'ai craqué.
  Bien sûr, je pourrais maintenir une version de Pijul qui parle à OpenSSH, et une autre qui parle au client de Thrussh. Ou même ne pas maintenir le client, et seulement un serveur. Mais écrire/maintenir un client et un serveur est moins cher que l'un des deux seulement, parce qu'on peut tester plus facilement avec des tests d'intégration. Comme je n'ai pas un temps infini, c'est pratique. En plus, le serveur de Thrussh n'a pas beaucoup d'utilisateurs (il est vraiment jeune), donc les rapports de bugs sont plutôt sur le client, et les réparations sont souvent communes avec le serveur.

• On finira par lire ~/.ssh/config et prendre en compte les agents, mais ce n'est pas du tout le rôle de Thrussh de faire ça. L'idée de Thrussh (contrairement au monolithique OpenSSH) est d'offrir une petite bibliothèque facile à utiliser et à auditer, et qui contient tout le protocole SSH 2. J'ai commencé à implémenter les agents dans une autre bibliothèque, et j'ai été pour l'instant bloqué par des choix contradictoires entre *ring* (une bibliothèque de crypto en Rust) et le protocole. Mais ça viendra !

• Il y a eu un gros effort sur la crypto en Rust. Des bibliothèques comme *ring* ont commencé à tourner un petit peu avant Thrussh, et c'était l'occasion de contribuer à faire évoluer l'écosystème. Le problème des agents met en valeur un cas que *ring* n'avait pas prévu, par exemple.

• Pareil pour Mio et Tokio, deux excellents projets pour les entrées-sorties asynchrones en Rust. Mio est arrivé avant Thrussh, et Tokio un peu après (mais maintentant Thrussh ne parle plus qu'à Tokio, Mio est la couche du dessous).

je ne suis meme pas sur que mon cerveau supporte la charge!

Bon, il y avait plein de trucs à faire. Et on apprenait Rust en même temps, ce qui est une expérience assez agréable.

Mais je ne suis pas non plus en train de dire que mon cerveau a totalement supporté la charge ;-)