Yes, merci, quel honneur 
Au passage, j’ai le même besoin que @Frederic_Renault : avoir une authentification automatique par salt + password.
As-tu prévu d’ajouter cette fonction à Silkaj, vu que Frederic l’a codée dans son fork ? J’ouvre une issue ? “mon” fork de Silkaj est en conflit avec la branche dev, je ne sais pas comment en sortir pour contribuer 
Mais je ne me suis pas penché dessus très sérieusement.
L’authentification via la méthode Scrypt (salt + password) est-elle absolument nécessaire dans vos applications (cc @Frederic_Renault) ?
Sinon, il y a l’authentification par fichier. En générant préalablement un fichier puis en le passant en argument lors d’une autre commande.
Si c’est vraiment nécessaire, il faut voir ce qu’il est possible de faire.
Je ne souhaite pas introduire la possibilité de pouvoir écrire des identifiants secrets directement dans le shell, car ils sont ensuite sauvegardés dans l’historique des shells.
Le prompts vous empêche d’entrer ces information avec un outil automatisé autour.
Je sais pas si on peut trouver un compromis entre ces deux solutions. Avoir une configuration pour pouvoir activer ça. Je sais pas. Je vous laisse réfléchir à une solution, car le besoin vient de vous.
De mon coté, ce n’est pas absolument nécessaire (le script actuel utilise l’authentification par fichier), simplement plus pratique si l’on a besoin de communiquer les identifiants aux utilisateurices non-techos.
edit - et pour automatiser la configuration. Mais au pire, un peu de passage en manuel, c’est pas la mort.
Merci de ta réponse 
Une authentification Scrypt (salt + mot de passe) par fichier pourrait être aisément implémenté dans DuniterPy puis Silkaj.
Dans ce cas, l’application au-dessus de Silkaj s’occupe de la sécurité de ces informations et ça n’est plus de la responsabilité de Silkaj.
Je me délègue de responsabilités de sécurité 
Hop, ticket créé !
La branche dev a pas mal changé. Tu peux tenter de résoudre les conflits.
Après avoir récupéré les dernières modifications sur dev localement, il y a deux méthodes, merge ou rebase.
En te plaçant sur ta branche, git merge dev, ça rajoutera un commit et tu devras résoudre manuellement des conflits.
Autre méthode qui va réécrire tes commits (les hash des commits vont changer), et va placer tes commits après les nouveaux commits de la branche dev.
Toujours en te plaçant sur ta branche, git rebase dev. Pareil, résolution de conflit, mais cette fois commit pas commit. Comme le code n’est plus le même, GitLab va refuser que tu publies. Il faudra git push --force.
Dans les deux cas, tu vas te retrouver avec du code asynchrone.
Il y a une fonction que tu utilises qui est devenue asynchrone. Il faut attendre son exécution en la préfixant du mot-clé await et ça devrait rouler sur des roulettes.
Ouch. Merci, je devrais me débrouiller avec ça 
. Sinon, j’ai des personnes compétentes à portée de vélo, je vais m’y pencher.
Le “history” n’est pas conservé le script est en exécution automatique (cron ou appel système)…
De toute façon qu’on ai un fichier clef privée dans son home ou son login/mdp dans son history, on est fichu si une brèche de son système a laissé entrer l’intrus!
Il y a aussi le fait de devoir écrire un parser pour interpréter les retours des appels silkay. Si jamais les textes changent les clients silkay risquent de ne plus s’y retrouver…
ex:
pubkey=$(cat /tmp/result | grep “Authentication file ‘authfile’ generated and stored in current folder for following public key:” | cut -d’:’ -f2 | sed 's/.$
echo “clef pub : $pubkey”
duniterpy répond en json il me semble… J’y vois l’intérêt de dialoguer avec les data des Pod Cesium+… Mais je n’ai pas encore eu le temps de me pencher dessus…
Pas faux. Mais, dans un usage direct de Silkaj, permetre de passer les identifiants secrets en paramètres ça les écrit dans des logs du système. Ce qui n’est pas le cas actuellement avec les prompts (insertions) cachés.
C’est ça que je veux éviter.
Astuce :
@moul, on peut me donner plus d’infos sur le fichier d’authentification à supporter dans Duniterpy ?
Un fichier texte avec le salt sur la première ligne et le passe sur la seconde, comme les credentials samba pour un montage fstab ? Est-ce que ça irait ?
Merci pour l’astuce, c’est toujours bon à savoir.
Je connais pas le fichier de configuration de Samba. Mais, je pense voir ce que tu veux dire. Ça ressemble au fichier PubSec.
Après, je suis pas très emballé par ce format de fichier, car les identifiants secrets sont en clair sur le système. Mais pourquoi pas.
Je ne saisis pas, en quoi est-ce moins sécurisé que d’avoir un fichier d’authentification ? Il contient la clef privée, non ? Un WIF également permet de se connecter, etc…
Les identifiants secrets sont immédiatement récupérables.
Avec les autres formats de stockage, il faut transformer pour obtenir les identifiants originaux. Bien que je ne sois pas sûr que ça soit possible de le faire dans l’autre sens.
Mais bon, ce document permet quand même de signer des documents et d’écrire dans la chaîne dans le cas du format PubSec.
Uniquement EWIF permet d’avoir un format sécurisé comme une clé ssh sécurisé avec une phrase de passe.