Le blog de Genma
Vous êtes ici : Accueil » Veille Technologique » Réflexions sur le fait d’installer une application depuis Github

Réflexions sur le fait d’installer une application depuis Github

D 11 octobre 2017     H 09:00     A Genma     C 3 messages   Logo Tipee

De plus en plus de logiciels sont mis à disposition sur Github et disponible à l’installation à partir d’un simple téléchargement ou git clone sur sa machine du code source depuis le dépôt Github. C’est une solution de facilité qui marche généralement bien (parfois il faut faire quelques commandes en plus, dans le cas d’une utilisation d’un système comme npm, node ou autre).

Les applications Yunohost

C’est le cas par exemple des applications packagées pour Yunohost. Le package se trouve sur Github, on indique le chemin du dépôt comme source d’installation et la moulinette (l’outil interne de Yunohost) fait son travail. Le package ne fait que rajouter des scripts shell et de configuration permettant l’installation et la mise à jour de l’application, l’application en elle-même étant récupérée depuis le site officiel de l’application. C’est donc bel et bien la même application qui est installé de la même façon que si on l’avait fait soi-même.

C’est quoi le soucis ?

Avant je trouvais déjà lourd le fait d’embarquer toutes les traductions d’un logiciel. Certe ce n’est pas bien lourd, surtout à l’heure actuelle où le tera-octet de disque est devenue monnaie-courante (et je ne parle pas de la quantité de RAM, il est loin le temps où l’on pouvait penser "640K ought to be enough for anybody.").

Mais désormais, avec les framework de développement, une simple application web peut faire des dizaines de méga octets. Et surtout, on a tous les fichiers de tests unitaires de l’application. Des tas de fichiers dont je n’aurai pas l’usage.

On a donc d’un côté l’application, assez lourde, et à côté, les test unitaires, la documentation et des tas d’autres fichiers qui ne servent pas et qui potentiellement peuvent contenir des failles de sécurité. Je ne suis pas assez pointu dans le domaine pour savoir si c’est quelque chose qui peut réellement poser problème (en théorie oui, plus il y a de fichiers et plus on multiplie les chances qu’il y ait une faille exploitable. Un peu comme ajouter des tas de plugin divers et variés dans un Wordpress par exemple... - On est vendredi quand je rédige ce billet).

Ce que j’aimerais ?

Il faudrait deux modes :
 un mode développeur pour lequel on a tout le code source, les jeux de tests, la documentation etc.
 un mode production permettant d’avoir les fichiers de configuration, les fichiers utiles à l’application et seulement eux.

Simple non ?

Conclusion

La prochaine fois, on parlera peut être des applications proposées uniquement sous la forme de conteneur Docker ou d’un autre sujet ;)

3 Messages

  • bonjour,
    Globalement, je suis d’accord avec toi, se serait souhaitable de pouvoir ne garder que l’application et pas les artefact du dev.
    Pour moi c’est au projet de gérer ce mode de fonctionnement.
    Avec pourquoi pas un makefile qui te fait un petit ’tar’ de ton appli avec les fichiers qui vont bien dans l’arborescence qui va bien...

    En revanche, je ne vois pas le rapport entre le nombre de fichier et la sécurité.
    Enfin si j’en vois un mais seulement dans le cas ou on souhaite auditer le code... et encore... ça peu être un peu plus brouillons et faire qu’on risque de louper une partie du code....
    Les fichiers ne risquent pas de "s’auto exécuter" et ni d’ouvrir des ports partout.
    Au niveaux des droits sur les fichiers se seront ceux qui sont mise en place par le projet. Pour les propriétaires des fichiers, ce sera ceux qui ont fait le ’git clone’ donc pas spécialement de risque d’escalade de droit intempestive.
    Et ce qui fait courir le plus de risque reste le nombre de service que tu expose à l’extérieur. Tu peu toujours faire un ’netstat -pautel’ pour voir ce qui est a l’écoute.
    Pour ce qui est des tests en général, ils sont dans un répertoire facilement identifiable genre "test". et là tu peu toujours les dézinguer... si le projet a un test en dépendance... il mérite pas d’être installé.

    Pour alléger ton ’git clone’, tu peux faire un :
    git clone mon_depot.git —depth 1
    Qui ne va télécharger que la branche principale et ne prendra que le dernier commit. (je crois qu’il ne télécharge pas non plus les sous modules si j’ai bien compris la doc).

    Ou alors tu supprime carrément le .git dans ton répertoire.


  • Installer depuis github c’est une chose, installer depuis les sources s’en est une autre, et c’est dommage.

    Github met à disposition des facilités pour mettre en places des releases sous forme d’artefact livrable (que ce soit un zip ou autre chose). Ces releases sont ensuite assez facilement récupérable. La manière de crée l’artefact de release est entièrement à la main de l’équipe projet => a eux de faire un livrable "épuré.


  • Hello,

    Ceci dit, dans la plupart des Makefile que j’ai consulté, il y a des options de build qui ne laisse que les fichiers et donc fonctionnalités nécessaires, on a le choix. Cela rejoins l’avis de nlthlr : c’est surtout au projet de s’en occuper car ils peuvent le faire assez facilement.