Réinstallation de mon environnement de gestion des mot de passe sous MacOS

Dans le cadre de mon emploi, j’ai pu procéder il y a peu à un changement de mon ordinateur car je commençais à m’approcher dangereusement des limites de ses capacités de stockage. Malgré une analyse du contenu du disque dur, difficile de trouver plus d’une dizaine de giga octets de place, même après nettoyage des anciennes versions de certains logiciels (versions restées sur le disque après mise à jour). Bref, qui dit changement de matériel, dit réinstallation de mon environnement de développement et une occasion à ne pas manquer de prendre quelques notes sur les étapes et autres réglages incontournables à ne pas oublier.

Avant de préciser les étapes d’installation, quelques mots sur la manière dont je gère mes mots de passe s’imposent.

Pour la gestion des mots de passe, j’utilise pass, petit utilitaire en ligne de commande, où chaque mot de passe est stocké dans un fichier chiffré sur le disque. La sauvegarde et la synchronisation sont réalisées via git. La clé de chiffrement est stockée sur un support externe de type « smartcard », une YubiKey en l’occurrence. Après maintenant trois ans d’utilisation quotidienne, le système a fait ses preuves et me convient parfaitement. Pour plus de détails, se référer aux articles de la catégorie Crypto autour de novembre 2018.

Récapitulons les éléments nécessaires:

  • gnupg.
  • pinentry, pour la saisie du mot passe protégeant la YubiKey.
  • Une YubiKey.
  • pass.
  • browserpass, pour une utilisation simplifiée dans les navigateurs.

Première étape, installer les briques logicielles nécessaires en utilisant brew.

brew install libyubikey yubikey-personalization gnupg pinentry pinentry-mac gpg-suite-pinentry pass amar1729/formulae/browserpass

Je n’entre pas dans les détails de l’étape intermédiaire de déploiement des fichiers de configuration de mon dossier dotfiles, celle-ci étant décrite dans l’article dotfiles, git et rcm. Mentionnons tout de même que ce déploiement permet la configuration de gnupg et de la variable d’environnement indiquant le chemin vers le dossier des mots de passe à pass.

Passons à la suite.

Lors de mes premiers tests, j’obtiens l’erreur suivante: gpg: WARNING: unsafe permissions on homedir '/home/path/to/user/.gnupg'. Problème de permission sur le répertoire de configuration .gnupg, une petite recherche concernant l’erreur, me donne un gist qui propose la solution ci-dessous:

chown -R $(whoami) ~/.gnupg/
# Set 600 for files
find ~/.gnupg -type f -exec chmod 600 {} \;
# Set 700 for directories
find ~/.gnupg -type d -exec chmod 700 {} \;

Je passe ensuite à la configuration de l’extension de navigateur browserpass sur les deux navigateurs que j’utilise: Firefox et Brave. Une fois l’extension installée, il faut déployer ce qui permettra à celle-ci de dialoguer en local avec pass. Ces commandes, ou une version similaire, sont rappelées à l’installation de browserpass via brew et je conseille vivement de faire une petite relecture du Readme du projet sur GitHub pour se remettre en tête la procédure.

PREFIX='/usr/local/opt/browserpass' make hosts-firefox-user -f '/usr/local/opt/browserpass/lib/browserpass/Makefile'

PREFIX='/usr/local/opt/browserpass' make hosts-brave-user -f '/usr/local/opt/browserpass/lib/browserpass/Makefile'

Je termine en configurant au niveau de l’extension le chemin vers le répertoire des mots de passe, celle-ci n’arrivant pas à utiliser la variable d’environnement dédiée et pourtant parfaitement accessible dans un terminal.

Je pensais en avoir terminé après cette opération, mais mes mots de passe restaient inaccessibles car pass ne parvenait pas à trouver les informations de clef nécessaires au déchiffrement. Après un test rapide de l’état de ma YubiKey avec gpg --card-status pour m’assurer que celle-ci était bien lisible et reconnue, je me suis souvenue qu’il me fallait importer ma clef publique. Après transfert du fichier la contenant, j’ai donc procédé à l’import via gpg --import < publickey.txt.

Nouveau test. C’est mieux, mais le programme se plaint de ne pas savoir quelle confiance accorder à la clef que je viens d’importer et limite donc grandement son utilisation. Pas de problème ! Accordons à cette clef une confiance absolue.

gpg --edit-keys <email_address> 
gpg> trust
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
gpg> quit

A l’issue de ces étapes de configuration, une nouvelle tentative d’accès à l’un de mes mots de passe se traduit cette fois par une récupération réussie de celui-ci.

La réinstallation de mon environnement de gestion des mots de passe sous MacOS s’est donc déroulée sans trop de difficulté et dans un temps plus que raisonnable, puisque je ne crois pas y avoir passé plus d’une heure. Il est toujours agréable de ne pas rencontrer trop d’erreurs en réinstallant et en reconfigurant ses outils, et de retrouver son environnement habituel propre, neuf et fonctionnel en peu de temps et sans avoir à y laisser un ou deux points de santé mentale.

Et un jour, qui sait, je disposerais peut-être enfin d’un script de réinstallation pour simplifier encore le processus.

Erreur 401 à l’installation d’une dépendance depuis le registre privé de GitHub avec npm v7

Au quotidien, sur l’une des briques logicielles sur laquelle je travaille, nous avons dans les dépendances de notre projet Node, une bibliothèque partagée à partir du registre privé de GitHub. Après une mise à jour de npm de la version 6 à la version 7, j’ai commencé à voir apparaître des erreurs 401 à l’exécution de la commande npm install. Ayant d’autres sujets plus urgents à traiter, nous avons donc pris la décision de rester sur la version 6 de npm.

Quelques mois après, avec le passage de Node 16 en version LTS et la publication de npm version 8, je me suis penché une nouvelle fois sur la question. En changeant la syntaxe de mon fichier .npmrc et en utilisant le nouveau format de token GitHub déployé il y a plusieurs semaines, les erreurs ont fini par disparaître. Voici donc la syntaxe utilisée:

//npm.pkg.github.com/:_authToken=ghp_xxxxxxxxxxxxxxxxxxxx
@scope:registry=https://npm.pkg.github.com

J’ai été devancé alors que je m’apprêtais à partager la disparition des erreurs avec cette configuration dans le ticket de bug dédié, où nous apprenons que cette correction fonctionne correctement pour les versions 6, 7 et 8 de npm.

Unity : Résolution d’un problème d’affichage entre deux objets possédant des shaders transparents

J’ai réalisé aujourd’hui quelques correctifs sur mon jeu Bulldozer sortie sur Android l’an dernier, dont la correction d’un problème d’affichage sur les scores affichés quand le Bulldozer se déplace, mais uniquement si le score est affiché au-dessus de la mer.

Le problème survient entre la mer et les objets de type TextMeshPro que j’utilise pour afficher le texte des scores.

Constatation

  • La mer a son propre shader que j’ai récupéré dans un asset.
  • L’objet TextMeshPro utilise une police d’écriture sous forme d’image et son shader sert à définir la façon de rendre la police.

Pour les deux shaders, celui de la mer et celui de la police d’écriture, il y a utilisation du canal alpha. Le canal alpha c’est le canal qui est utilisé pour gérer la transparence. Le canal alpha n’est pas utilisé dans les shaders utilisés les cases, les bulldozers ou les arbres. Or j’ai des problèmes d’affichage uniquement entre la mer et le texte des scores.

Cet élément après de longue recherche m’a fait trouver qu’il y avait des problèmes d’affichages de ce type lorsque deux shaders utilisant la transparence sont paramétrés sur la même renderQueue.

La renderQueue selon la documentation unity c’est ce qui détermine dans quel ordre les objets sont rendus. Dans mon cas les deux étaient paramétrés sur 3000. En modifiant la valeur de la renderQueue de 3000 à 3000-1 soit 2999 pour le shader de mer j’ai résolu le   problème et mes objets s’affichent dans le bon ordre sans se marcher dessus l’un et l’autre.

En conclusion si vous avez des problèmes d’affichage entre deux objets qui utilisent la transparence alors vérifiez et modifiez la valeur de la renderQueue en fonction de l’objet que vous souhaitez voir afficher au-dessus de l’autre.

Télécharger le jeu Bulldozer pour Android

Fusion automatique de branches avec Github Actions

Un projet récent sur lequel je travaille dispose d’une branche, qui, lorsque celle-ci reçoit des modifications, déclenche un événement dans notre système de déploiement continue, afin de déployer le contenu de la branche sur notre environnement de développement. Avec l’augmentation des effectifs de développeurs sur le projet, et pour essayer de garder un environnement de développement le plus à jour possible et faciliter le test des nouvelles fonctionnalités ou des corrections, je me suis penché sur la question de la fusion automatique de branches avec les Github Actions.

Voici un exemple de configuration fonctionnelle:

name: auto-merge
on:
  workflow_dispatch:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron: '0 7 * * 1-5'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: master
          fetch-depth: 0
      - name: Merge on dev-env
        run: |
          git config user.name github-actions
          git config user.email github-actions@github.com
          git config --global pull.ff only
          git checkout dev-env
          git pull
          git merge master
          git push

Dans cet exemple, tous les jours du lundi au vendredi à 7h, la branche master sera fusionnée dans la branche dev-env et poussée dans le dépôt distant, déclenchant ainsi le processus de déploiement automatisé.

cmd#9 – Git: mise à jour « forcée » depuis le dépôt distant

Dans un script automatique, dont le but est de mettre à jour le code local d’un dépôt git avec celui du dépôt distant, sans prendre en compte ni même conserver les éventuelles modifications locales, l’enchaînement de commande git est le suivant:

git fetch
git reset --hard HEAD
git merge '@{u}'

Avec '@{u}', un raccourci pointant vers la branche upstream de la branche courante.