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 2 messages   Flattr cet article 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 ;)

 Vous aimez cet article? Soutenez le blog et partagez-le ;-)

Logo Tipee Flattr icon  Facebook icon  Twitter icon  Diapora icon   Licence Creative Commons

2 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é.


Un message, un commentaire ?
modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Conférences

Médiathèques vous recherchez un conférencier sur l’éducation populaire et l’hygiène numérique? Jetez un coup d’oeil à mon CV

Date des prochaines conférences?
Cliquer ici

Rechercher sur le blog

Liens

Logo Flattr Logo Gmail Logo Twitter
Logo RSS Logo Linkedin Logo GitHub
Logo Gitlab Logo Mastodon
Logo Diaspora

Soutenir ce blog?

Logo Tipee Logo Liberapay

Licence

Licence Creative Commons

Derniers articles

1.  Appel à soutiens pour l’Openhackademy

2.  Documentation Centreon en epub, crash avec la liseuse Bookeen

3.  Scan2Epub.sh où comment lire des Scantrad en Epub

4.  Le Cecil et son guide de survie des aventuriers d’Internet

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

6.  Il y a un an, démission

7.  Firefox Focus, le navigateur privé de Mozilla

8.  Cours sur les serveurs web par Luc Didry

9.  Yunohost - Goaccess - Rapport HTML depuis des logs d’un serveur web

10.  Il y a un an - Ma lettre de motivation


Date de mise à jour :

Le 18 octobre 2017