Archives du mot-clé Gitlab

Lufi 0.03 est sorti !

Après plus d’un an, voici une nouvelle version de Lufi ! Cette nouvelle version aurait du être l’oc­ca­sion d’une refonte de l’in­ter­face en utili­sant VueJs mais j’ai pris énor­mé­ment de retard sur mon appren­tis­sage de celui-ci, donc ça sera pour la version suivante.

Le déve­lop­pe­ment de la nouvelle version n’a pas pris un an, loin de là, mais comme ce n’est pas le seul logi­ciel que je main­tiens (loin de là), bah voilà.

Vous pouvez tester la nouvelle version sur l’ins­tance de démons­tra­tion : https://demo.lufi.io.

Liste non exhau­sive des chan­ge­ments

Pour les utili­sa­teurs :

  • Amélio­ra­tion de la vitesse au niveau client via l’uti­li­sa­tion de mes plugins Mojo­li­cious GzipS­ta­tic et StaticCache, qui compressent les fichiers statiques et leur adjoint un en-tête de cache navi­ga­teur ;
  • Possi­bi­lité de choi­sir la langue de l’in­ter­face (là où le choix se faisait auto­ma­tique­ment via les préfé­rences du navi­ga­teur) ;
  • Affi­chage de la taille du fichier lors de l’en­voi ;
  • Affi­chage de la taille maxi­male accep­tée des fichiers ;
  • Ajout des traduc­tions en arabe et en alle­mand ;
  • Ajout d’une tâche récur­rente pour provi­sion­ner en avance des adresses de fichier. Pour les utili­sa­teurs, ça se traduit par des pages qui sont envoyées bien plus rapi­de­ment.

Pour la modé­ra­tion :

  • Il y a possi­bi­lité pour l’ad­min de modi­fier un champ en base de données pour bloquer le télé­char­ge­ment d’un fichier, tout en affi­chant la raison (contenu illé­gal, viola­tion des CGU, etc. Les raisons sont confi­gu­rables) au télé­char­geur. Cela n’est pas très pratique (bidouiller en base de données), mais c’est un pas en avant ;
  • Possi­bi­lité de signa­ler simple­ment un fichier aux admins d’une instance.

Pour la sécu­rité :

  • Mise à jour de la biblio­thèque javas­cript de chif­fre­ment SJCL ;
  • Gestion d’une éven­tuelle excep­tion si l’en­tro­pie du navi­ga­teur est trop faible pour géné­rer correc­te­ment une clé de chif­fre­ment ;
  • Ajout de jetons CSRF à la connexion et à la décon­nexion (si l’au­then­ti­fi­ca­tion est utili­sée, bien sûr) ;
  • Ajout de contraintes sur l’en­voi de mail pour éviter de se retrou­ver à envoyer des spams.

Pour les déve­lop­peurs :

  • Utili­sa­tion de Mojo::SQLite à la place d’ORLite pour l’uti­li­sa­tion d’une base SQLite. Ce chan­ge­ment de module me permet de réduire énor­mé­ment le code de la couche d’abs­trac­tion de la base de données : Mojo::SQLite a la même syntaxe que Mojo::Pg, du coup, c’est le même code pour les deux bases de données.
  • Créa­tion et utili­sa­tion de plugins Mojo­li­cious person­nels. Ces modules ne sont pas publiés sur le CPAN car très forte­ment liés à ma manière d’uti­li­ser le frame­work Mojo­li­cious. La publi­ca­tion de modules person­nels sur le CPAN est décon­seillée pour ne pas le polluer, mais Carton, le gestion­naire de dépen­dances que j’uti­lise permet de spéci­fier l’URL de télé­char­ge­ment des modules. Je peux donc utili­ser les tarballs four­nis par Frama­git. L’in­té­rêt de l’uti­li­sa­tion de modules person­nels est de mutua­li­ser le code commun à mes diffé­rents logi­ciels, de ne plus me répé­ter et de réper­cu­ter une correc­tion ou une amélio­ra­tion d’un logi­ciel à un autre bien plus faci­le­ment ;
  • Ajout d’un code de conduite ;
  • Ajout d’une suite de tests, lancée auto­ma­tique­ment à chaque push grâce à l’in­té­gra­tion conti­nue de Gitlab.

Pour les admins :

  • Support de MySQL : comme le code de la couche d’abs­trac­tion a été simpli­fié, il suffit d’uti­li­ser un module possé­dant la même syntaxe que ceux des deux autres bases de données pour ajou­ter le support d’une nouvelle base. Grâce à Mojo::mysql, ça s’est fait très faci­le­ment.
  • Ajout d’une commande pour migrer simple­ment d’une base de données SQLite à un autre type de base.
  • Il y a main­te­nant une option dans la confi­gu­ra­tion pour obli­ger tous les fichiers à être suppri­més après le premier télé­char­ge­ment.
  • Il y a main­te­nant un en-tête Content-Secu­rity-Policy par défaut, qui devrait conve­nir à la plupart des instal­la­tions. Cet en-tête est bien évidem­ment surchar­geable dans la confi­gu­ra­tion.

Hack­péro

Il est à noter que cette version a été présen­tée au Hack­péro qui a eu lieu à Paris le 26 octobre dernier (un genre de hacka­thon spécia­lisé recherche de bugs ou de vulné­ra­bi­li­tés). Je tiens à remer­cier gran­de­ment l’équipe de Bounty Factory qui m’a contacté pour me le propo­ser, ainsi que les bug hunters qui y ont parti­cipé.

Artwork Lufi

Je vous ai déjà présenté l’artwork pour Lutim dans mon article précé­dent. J’avais aussi commandé à Soniop un artwork pour Lufi !

Cliquez pour avoir l’image origi­­nelle (en grande taille)

Comme pour Lutim, c’est en CC-BY-SA (fichier source Photo­shop).

Instal­la­tion

La meilleure façon d’ins­tal­ler Lufi est de suivre les instruc­tions du wiki.

Me soutenir sur Tipeee Me soutenir sur Liberapay

Signer ses commits Git et trans­fé­rer son gpg-agent sur un serveur distant

GPG, c’est bien. C’est encore ce qu’on a trouvé de mieux pour que tout un chacun puisse s’as­su­rer de l’au­then­ti­cité d’un message (non-modi­fi­ca­tion de celui-ci et que son auteur est bien celui annoncé) et chif­frer ses messages.

OK, c’est pas un exemple d’er­go­no­mie, OK, c’est pas ma mère qui va s’en servir sciem­ment tous les jours (sous le manteau, si, puisque les paquets de sa Debian sont signés avec GPG). Mais d’un autre côté, ma mère ne risque pas non plus (et je dirais même encore moins) de se payer un certi­fi­cat X509 pour signer ses mails. Ne parlons pas de mon père, à côté de lui, ma mère fait figure de hax0r.

Bon, d’ac­cord, c’est un bon gros truc de geek. OSEF, c’est cool quand même, c’était pour dire que c’était robuste et que tout le monde peut l’uti­li­ser sans bourse délier.

Que vous le sachiez (dans la colle) ou pas, on peut signer ses commits git avec GPG, histoire d’ajou­ter encore une couche de sécu­rité aux modi­fi­ca­tions qu’on apporte à un logi­ciel. Des forges comme Gitlab permettent d’ajou­ter une clé GPG à son profil permet­tant ainsi de véri­fier les signa­tures des commits d’un projet. Voyez sur ce commit le joli petit bouton « Veri­fied ».

Ceci n’est pas un cours sur GPG, on va donc consi­dé­rer que vous avez déjà une clé GPG.

Signer ses commits Git

Rien de plus simple. Il faut tout d’abord décla­rer à Git quelle clé doit être utili­sée pour signer ses commits (chan­gez l’em­preinte, ça c’est la mienne ) :

git config --global user.signingkey EA868E12D0257E3C

Main­te­nant, soit vous ajou­tez -S quand vous commit­tez :

git commit -S

Soit vous confi­gu­rez Git pour signer tous vos commits :

git config --global commit.gpgsign true

Voilà, c’est bon. Pour véri­fier un commit :

git verify-commit cce09ca

C’est bien beau, mais ça m’ar­rive de déve­lop­per direc­te­ment sur des serveurs, et surtout, je déve­loppe géné­ra­le­ment dans une machine virtuelle sur mon PC. Je ne vais certai­ne­ment pas aller copier ma clé privée sur les-dits serveurs ou dans la machine virtuelle ! C’est là qu’in­ter­vient le trans­fert du gpg-agent sur le serveur distant.

Ceci n’est toujours pas un cours sur GPG, on va donc consi­dé­rer que vous avez déjà un gpg-agent fonc­tion­nel sur votre ordi­na­teur.

Trans­fé­rer son gpg-agent sur un serveur distant

ATTENTION On ne trans­fère son agent gpg que sur une machine dans laquelle on a confiance, et dont on sait que les personnes y ayant accès ne s’amu­se­ront pas à utili­ser votre agent (rien de plus simple si on a un accès root à la machine). Cela vaut aussi pour l’agent ssh !

Premiè­re­ment, on va dire à l’agent de créer un socket supplé­men­taire en mettant dans ~/.gnupg/gpg-agent.conf (rempla­cez <user> par votre login) :

extra-socket /home/<user>/.gnupg/S.gpg-agent.extra

Ce socket a des restric­tions que n’a pas le socket habi­tuel (ne me deman­dez pas lesquelles) mais surtout, le logi­ciel qui vous deman­dera votre mot de passe (pinen­try de son petit nom géné­rique) vous présen­tera la demande de mot de passe diffé­rem­ment d’ha­bi­tude. Moi, il m’a dit en gros « Cette demande provient d’une machine distante », ce qui permet de repé­rer d’où vient la demande (déjà pas de votre machine pour déchif­frer un mail par exemple) et de réflé­chir à si c’est bien vous qui avez fait une action deman­dant la clé GPG.

On redé­marre l’agent pour prendre en compte la nouvelle confi­gu­ra­tion :

gpg-connect-agent /bye

Ensuite, il va falloir modi­fier sa confi­gu­ra­tion SSH. Comme un bon adminSys est fainéant, vous avez bien sûr utilisé concierge pour gérer votre fichier ~/.ssh/config. Il suffit d’ajou­ter dans le bloc de confi­gu­ra­tion du serveur souhaité la ligne (rempla­cez uid par votre uid (id pour le connaître) et <user> par votre login):

RemoteForward /run/user/<uid>/gnupg/S.gpg-agent /home/<user>/.gnupg/S.gpg-agent.extra

Enfin, il faut ajou­ter ceci dans le /etc/ssh/sshd_config du serveur distant (et redé­mar­rer son dæmon ssh après) :

StreamLocalBindUnlink yes

C’est fini ! Vous pouvez main­te­nant utili­ser votre clé GPG sur un serveur distant en vous y connec­tant en SSH, sans copier votre clé sur le serveur

Connec­tez-vous en SSH et testez avec

echo "test" | gpg2 --clearsign

Si, lorsque vous tentez de signer un commit sur votre serveur distant, cela échoue, assu­rez-vous que git utilise bien gpg2 :

git config --global gpg.program gpg2

Merci à Thomas Citha­rel pour avoir mis la signa­ture GPG des commits sur le tapis d’une discus­sion, ce qui m’a poussé à me pencher sur le trans­fert de l’agent GPG.

Crédit image d’en-tête de ce billet : logo de GnuPG, licence GPL, récu­péré sur Wiki­me­dia Commons

Me soutenir sur Tipeee Me soutenir sur Liberapay