Forem: Maxime BEUIL

Open source et Hacktoberfest

Maxime BEUIL — Thu, 29 Oct 2020 15:59:29 +0000

Qui dit: mois d'Octobre, dit: Hacktoberfest et donc Open Source . Organisé chaque année par DigitalOcean, cet événement d'une durée d'1 mois à pour but de mettre en avant le monde de l'open source car c'est bien d'open source dont je veux parler dans ce billet.

Personnellement, j'avais déjà entendu parler d'open source avant mon arrivée dans le monde de l'informatique. Via la pop culture, les films et séries mais aussi mon entourage, nous avons tous quelqu'un, un ami, un proche ou un prof, qui utilise un logiciel open source plutôt qu'un autre.

Un logiciel en open source est un software dont le code source est public (sur Github par exemple) et est sous licence. Et parce que le code est public, tout le monde peut donc travailler dessus et essayer d'y apporter ses modifications.

Ces modifications peuvent aller de la plus petite correction à la restructuration de l'application en passant par l'ajout de fonctionnalités. L'objectif étant de venir résoudre une problématique. Vous pouvez soit prendre l'initiative d'une modification soit répondre à une open issue indiquant un problème.

Comment participer ?

Il faut commencer par trouver un projet auquel vous voulez participer.
Créer une copie du repo d'origine sur votre propre espace perso, faire un "fork".
Coder les changements que vous jugez nécessaires.
Commit et push ces modifications sur votre copie du repo, faites en sorte que le commit résume l'objectif des modifications apportées. Vous pouvez suivre, ou non, quelques conventions.
Et après seulement, vous pourrez faire une "Pull Request", PR, et demander à ce que vos modifications soient "merge" sur le repo d'origine. Pensez à détailler les changements apportés en commentaire de votre PR. Et, si vous répondez à une issue, pensez à ajouter au commentaire le numéro de l'issue en question.

Ce merge n'est pas automatique. Il doit passer par une étape de validation. C'est aux "maintainers" du projet de juger si ce que vous proposez est intéressant.

L'intérêt de participer à un projet en Open Source ?

Plus que pour appliquer un savoir faire, surtout pour les jeunes développeurs, accéder à un code sur lequel a collaboré une équipe de développeurs, c'est une occasion en or pour s'entraîner à lire le code d'autrui. C'est aussi un excellent moyen d'assimiler un maximum de bonnes pratiques, surtout auprès de projets populaires et ayant un fort trafic.

Je vous conseille de faire un tour sur le repo de DIM si le ReactJs vous intéresse.

Après 4 PRs et selon un standard à respecter, nous avons la possibilité de recevoir un t-shirt ou de planter un arbre ! Rien de mieux pour donner envie de participer que d'avoir à la clef un goodie ou de faire une bonne action, win-win !

Quelques idées

Pour ceux qui angoissent un peu avant de se lancer il existe des plateformes qui regroupent les issues avec le tag good first issue.

Enfin, merci à l'Hactoberfest de mettre sur le devant de la scène l'Open Source. C'est parfois juste ce qu'il faut à un jeune dev tel que moi pour enfin s'y intéresser ainsi que de faire parler de projets autour du climat et du COVID-19.

Comment signer ses commits sur Github

Maxime BEUIL — Mon, 21 Sep 2020 08:07:07 +0000

Qui se souvient de son époque au collège, au lycée ou à la fac, l'époque des contrôles continus et des exams? De ces tas de copies rendues sur lesquelles seul le nom en tête de page pouvait vous identifier?

Eh bien, lorsqu'on "commit" c'est la même chose!
On peut commit avec notre propre compte Github mais aussi en utilisant les infos d'un autre utilisateur.

Pour cela il suffit de récupérer les infos d'un autre compte, par exemple, en clonant un des "repos" du compte en question et de faire un simple:

git log

Puis de modifier vos infos, avant le commit, avec celles récupérées ainsi:

git config user.name 'xxx'
git config user.email 'xxx.yyy@mail.com'

Et voila, vous pouvez maintenant commit une modification sous le nom d'un tiers.

Les détails liés à la personne d'origine du commit n'a pas pour but de servir de moyen d'authentification.

En usurpant le nom d'un compte pour commit, il n'y a pas de faille de sécurité. Ce changement ne permet pas de commit sur les repos du dit compte. Github demanderait alors de s'authentifier avec ses logs avant de pouvoir faire le moindre "push".

Il vous est donné la possibilité de rajouter un niveau supérieur de certification, pour cela apprenons à signer nos commits !

1 - Préparer le terrain

Avant tout, vous aurez besoin, dans un premier temps et si ce n'est pas déjà fait, d'installer GPG :

Pour mac :

Lancez la commande :

brew install gpg

Créez ou ajoutez à votre fichier ~/.gnupg/gpg.conf :

# Enable gpg to use the gpg-agent
use-agent

Pour vous éviter de réécrire votre phrase secrète trop souvent (cette phrase arrive dans la partie "les clefs GPG") installez pinentry-mac :

brew install pinentry-mac

Et, créez ou ajoutez à votre fichier ~/.gnupg/gpg-agent.conf :

# cache your passphrase in your mac keychain
pinentry-program /usr/local/bin/pinentry-mac

Modifiez votre ~/.bashrc, ~/.zprofile... en y ajoutant les lignes suivantes :

export GPG_TTY=$(tty)
gpgconf --launch gpg-agent

Il sera parfois nécessaire de redémarrer votre agent GPG :

gpgconf --kill gpg-agent

gpgconf --launch gpg-agent

Vous pouvez vérifier si tout marche bien :

echo "test" | gpg --clearsign

Vous devrez alors voir apparaitre le prompt suivant, n'oubliez de cocher la case save in keychain.

Pour les pc sous windows :

Allez directement sur le site de GnuPG et téléchargez la dernière version de GnuPG.

2 - Les clefs GPG

Maintenant que les préparatifs sont finis, la 2ième étape consiste à créer la paire de clefs GPG, une publique et une privée, qui vous serviront à vous identifier à l'avenir. Pour les générer, commencez avec la commande :

gpg --full-gen-key

Une fois lancée, plusieurs questions vous serons posées :

Le type de clef désiré, j'ai personnellement opté pour une clef RSA.
La taille des clefs.
La duré de validité.
Vos informations.
La phrase pour chiffrer la clef secrète sur votre disque dur. Attention ne perdez pas cette phrase !

Vous pouvez ainsi générer autant de paires que nécessaire. Il vous faut maintenant déterminer laquelle de ces paires vous utiliserez. Pour lister vos clefs :

gpg --list-secret-keys --keyid-format LONG

/Users/max/.gnupg/pubring.kbx
-----------------------------
sec   rsa4096/XXXXXXXXXXXXXXX 2020-09-17 [SC] [expire : 2021-09-17]
      YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
uid        [  ultime ] user (commentaire) <user@mail.com>

Dans l'exemple ci-dessus la série de chiffre XXXXXXXXXXXXXXX représente l'identification d'une clef privée, son ID.

3 - Configurer le compte Github

Après avoir généré une paire de clef GPG passez à la configuration de Github. Il vous faut, pour cela, votre clef GPG publique trouvable grâce à l'ID vu précédemment :

gpg --armor --export XXXXXXXXXXXXXXX

-----BEGIN PGP PUBLIC KEY BLOCK-----

.
.
.

-----END PGP PUBLIC KEY BLOCK-----

Il ne vous reste plus qu'à ajouter votre clef publique dans les paramètres de votre compte Github.

4 - Se simplifier la tâche

Et c'est à peu près fini. A partir de maintenant vous allez pouvoir signer l'ensemble de vos commit en rajoutant l'option -S suivie de l'ID de votre clef secrète. Cela marche aussi pour les tag. Pas bien compliqué non ?

git commit -S XXXXXXXXXXXXXXX

Bon, rien que de penser à tapper ces nouvelles infos à chaque commit j'en ai des vertiges. Heureusement, on peut aller plus loin dans notre démarche.

Pour ce faire, il faut éditer le ~/.gitdonfig :

git config --global user.signingkey XXXXXXXXXXXXXXX

Voila ! Plus besoin d'inscrire l'ID a chaque commit. Un simple git commit -S suffira.

Si vous avez dans l'idée de signer l'intégralité de vos commits et d'en finir avec le -S il suffit de le spécifier sur votre gitconfig :

git config --global commit.gpgSign true

git config --global tag.gpgSign true

Votre fichier ~/.gitconfig devrait ressembler à ça maintenant:

[user]
  name = user
  email = mail
  signingkey = XXXXXXXXXXXXXXX
[commit]
  gpgsign = true
[tag]
  gpgsign = true

Dorénavant, sur Github, vos commits seront marqués d'un petit encart vert "verified". De même sur votre terminal pour pouvez vérifier dans les logs les commits signés :

git log --show-signature -5

commit 67ff2326d2ea9f6d86c582f6c842bee7a95de9d1 (HEAD -> master, origin/master)
gpg: Signature faite le Jeu 17 sep 16:15:16 2020 CEST
gpg:                avec la clef RSA XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gpg: Bonne signature de « user <user@mail.com> » [ultime]
Author: user <user@mail.com>
Date:   Thu Sep 17 16:15:16 2020 +0200

    signed commit

Personnellement, j'ai ajouté à mon .zshrc ce petit alias glog='git log --pretty="format:%h %G? %aN %d %s"' :

$ git log --pretty="format:%h %G? %aN %d %s
12ddb92 G user   signed commit
5855463 G user   signed commit
0b867fc N user   non signed commit
887a067 N user   non signed commit
d45be7b N user   non signed commit

Si le commit est signé il sera alors accompagné de l'option G sinon l'option sera N.

5 - Plus de sécurité

Il est important de créer un certificat de révocation de votre clef secrète. Car si celle-ci est compromise ou perdue ce certificat est alors le seul moyen de dire aux autres d'ignorer la clef volée.

gpg --output <user@mail.com>.gpg-revocation-certificate --gen-revoke XXXXXXXXXXXXXXX

On peut aussi faire une sauvegarde des paires de clefs en les exportant :

gpg --export-secret-keys --armor XXXXXXXXXXXXXXX > <user@mail.com>.private.gpg-key

gpg --export --armor XXXXXXXXXXXXXXX > <user@mail.com>.public.gpg-key

Surtout ne stockez pas le certificat et la clef secrète au même endroit.

Bonus de fin

On va finir par une petite astuce. Les commandes git merge et git pull peuvent vérifier et rejeter si nécessaire les commits non signés avec l'option --verify-signatures.

Par exemple, la fusion ne s'effectuera que si tous les commits sont signés

git merge --verify-signatures -S non-verify

fatal: Commit e9c079b does not have a GPG signature.

Ajouter une bannière a votre profil Github

Maxime BEUIL — Sat, 29 Aug 2020 17:12:22 +0000

Depuis l'arrivée de Microsoft, Github a connu quelques changements. En vrac, on peut citer une application mobile ou encore, dernièrement, l’ajout du pseudo twitter à votre profil. Mais ce qui nous intéresse ici est une autre de ces nouveautés: la possibilité d’épingler un README.md, une bannière, à votre page d'accueil sur Github.

Comment faire?

Rien de plus simple.
Commencez par créer un nouveau dossier, un “repo”. 3 petites choses sont à faire pour que la magie opère :

Le repo doit avoir pour nom votre pseudo Github.
Rendez ce repo public.
Initialisez le repo avec un README.

Et voilà, votre profil vient juste de gagner un petit entête avec pour contenu le readme du repo fraîchement ajouté.
Attention, un repo vide fera que rien ne s’affichera.

Personnalisable?

Plutôt deux fois qu’une.
C’est maintenant que vous allez pouvoir faire parler votre créativité, sortir de la masse et vous mettre en avant. Comme tout README classic, vous pouvez y ajouter emojis, images, gifs … laissez parler votre imagination !

Personnellement, j'ai opté pour une simple petite image faite sur Sketch. Pour utiliser une image dans un README, vous pouvez soit héberger votre image sur un site tiers, ou directement utiliser une image stockée sur votre repo:

![from_url](https://i.imgur.com/your-profile-picture.png)

![from_assets](https://github.com/username/username/xxx/master/assets/your-profile-picture.png)

https://github.com/mbeuil/mbeuil

Votre bannière peut faire dans le simple ou le descriptif:
https://github.com/jh3y/jh3y
https://github.com/stephenajulu/stephenajulu

Et si vous en voulez toujours plus:
https://github.com/abhisheknaiidu/awesome-github-profile-readme

Ressources utiles:

Si vous voulez toujours plus d'exemple de README:
https://github.com/abhisheknaiidu/awesome-github-profile-readme

Pour ceux, un peu perdu, qui veulent en apprendre plus sur le système de markdown, GFM, utilisé par Github : https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github

Ou si vous voulez égayer votre texte d’emojis en tout genre:
https://gist.github.com/rxaviers/7360908