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).
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par pmeunier . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 10.
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/configet 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).