25 fév. 2010

webvcs - un système de contrôle de version sans serveur

Pour mes projets personnels, je suis en train de développer un logiciel que j'ai nommé webvcs, et qui n'est autre qu'un SVCS (pour serverless version control system) composé de deux parties :

  • un client (fonctionnant sous Windows 32/64, mais le porter sous Linux ou Mac OS X ne devrait pas poser de problèmes)
  • un ensemble de scripts PHP pouvant s'installer sur n'importe quel serveur web autorisant l'exécution de scripts PHP 5.

Le but : héberger sur mon site web mes propres projets open source, sans avoir besoin de passer par un plateforme telle que codeplex, sourceforge ou google code.

Le fonctionnement, coté web

Les scripts PHP émulent un serveur VCS simple, capable de comprendre quelques notions de base :

  • import : importer un projet dans le système
  • get revision : récupère une version particulière d'un fichier
  • commit : enregistrer les fichiers modifiés sur le serveur web
  • branch : crée une branche.

Les trois notions manipulées sont, dans l'ordre de taille :

  • le fichier : c'est l'unité de base du système. Les fichiers sont pour l'instant stockés dans une base de donnée SQL (mysql pour l'instant, mais l'écriture d'un driver pour un autre SGBC ne me semble pas trop complexe), mais je pense développer un sous-système permettant l'utilisation de webvcs sur des serveurs sans accès à une base de donnée.
  • le travail (job) : lorsqu'un commit est effectué, il est nécessairement lié à une activité (activity) - qui peut être une évolution, une correction de bug, etc - pour produire un job. L'idée est de ne pas permettre un commit si ce commit n'est pas motivé par quelque chose. Les jobs sont gérés sur la base de transactions - un seul job peut être appliqué à la fois, ce qui permet d'assurer la possibilité de travail concurrentiel sur un même ensemble de fichiers. Bien évidemment, les activities doivent exister avant le commit pour que celui-ci puisse se faire.
  • la branche (branch) : un utilisateur travaille nécessairement sur une branche - que cette branche soit la branche principale (mainline) ou une branche secondaire (marquée par un label). Dès qu'il y a création d'un label, il y a création d'une branche - et inversement. Il est possible d'intégrer un job dans une autre branche que celle dans laquelle il a été produit.

Le tout fonctionne sur la base d'un protocole web très simple inspiré par les technologies du type "web service" et que je documenterais plus tard (ce qui, je l'espère, autorisera la création de versions ASP.Net de webvcs).

Le fonctionnement, coté client

L'application cliente webvcs est relativement simple. Elle ne comporte qu'un nombre réduit de fonctions : connect/disconnect, import, get, commit, branch. La question de la sécurité est gérée sommairement via les commandes connect/disconnect (le connect a une durée de vie limitée à une dizaine de minutes d'inactivité, donc le disconnect n'est pas nécessaire dans la plupart des cas). Un hash est calculé à partir des informations d'identification et des informations liées à la machine cliente, ce hash étant systématiquement durant les dialogues entre le logiciel client et les scripts installés sur le serveur. Un saupoudrage de gestion pas trop idiote permet de s'assurer avec une "certaine certitude" que la personne dialoguant avec les scripts serveur est bien celle qu'elle prétends être. Point important : les mots de passe ne circulent jamais en clair sur le réseau.

Les autres actions sont assez triviales, donc je ne vais pas m'étendre sur le sujet.

Beta-testeurs ?

Le logiciel est en cours de développement. Il n'est pas mûr pour être testé, j'en suis à la phase de pré-alpha. Dès que j'entrerais dans une phase alpha (avec un produit suffisamment fonctionnel pour être testé et utilisé mais comportant encore des problèmes de stabilité voire des fonctions manquantes), je vous tiendrais au courant.

Idem pour ceux qui veulent rejoindre le développement : je les encourage pour l'instant à me faire part de leurs idées. Dès que le logiciel sera en pré-alpha, il apparaîtra comme par magie sur mon site web, et il sera utilisé pour continuer le développement sur lui-même (lire : webvcs sera utilisé pour héberger le projet webvcs ; c'est la raison pour laquelle j'ai besoin de m'assurer qu'il fonctionne suffisamment avant de le lâcher dans la nature...)

En conclusion : dès que j'ai quelque chose à vous dire sur le projet en cours, je mettrais à jour ce blog. Vous n'avez donc qu'à le suivre régulièrement pour être informé de l'avancement du projet :)

Commentaires

1. Le mercredi, mars 17 2010, 21:38 par web design montreal

Bon article ! merci pour le partage !

2. Le lundi, juillet 5 2010, 15:25 par Ekinox

"Point important : les mots de passe ne circulent jamais en clair sur le réseau."
Ceci ne changera rien au fait qu'une personne sniffant le réseau pourra se connecter.
Exemple :
Alice se connecte à Serv, donne son mot de passe à Prog
Prog crypte le mot de passe, l'envoie à Serv
Bob, qui sniffe le réseau, voit passer 1AE34281 (par exemple)
Alice se déconnecte
Bob envoie à Serv (sans passer par Prog) 1AE34281
Bob est connecté comme Alice l'était

En bref, je pense qu'il n'y a pas de possibilité pour "bien" gérer la sécurité autrement qu'en passant par un tunnel SSL ...

3. Le jeudi, juillet 15 2010, 10:37 par Emmanuel Deloget

En bref, je pense qu'il n'y a pas de possibilité pour "bien" gérer la sécurité autrement qu'en passant par un tunnel SSL ...

C'est la vérité vraie. Dans mon cas, il faut aussi que Bob se connecte avec la même IP (soit du même poste, soit en spoofant Alice) parce que l'adresse IP de celui qui se connecte est (plus ou moins) dans les hash qui sont échangés (et vérifiée par le serveur). Ca reste insuffisant, mais ça ajoute une barrière supplémentaire.

De toute façon, on est sur internet : la sécurité des transactions ne peut s'obtenir qu'avec le chiffrement des informations qui circulent. Sans chiffrement, ces informations peuvent être exploitées par un attaquant dans un but quelconque (sachant que je crois pas aux défenses du type "je fais ça pour tester le système et démontrer qu'il n'est pas sûr". Non. les scripts kiddies font ça parce qu'ils sont idiots et qu'ils ne sont pas à une imbécilité près. Le fait qu'ils tentent de se défendre de la sorte montre qu'en plus, ils sont lâches).

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet