Depuis un point de vue purement utilitaire, oui, vous pouvez utiliser Keychain. Je vous encourage fortement à lire l'intégralité de la page de manuel security(1)
qui contient des avertissements supplémentaires.
Vous pouvez saisir le mot de passe en utilisant le programme Keychain ou via la ligne de commande :
# ATTENTION : expose le mot de passe dans ps(1), history(1), etc.
$ security add-internet-password -a $USER -s pop3.example.com -w 'Mellon!'
Vous pouvez extraire ceci avec :
# Remarque : par défaut, la première utilisation demandera
$ security find-internet-password -s pop3.example.com -a $USER -g
Si vous choisissez Toujours autoriser, security(1)
pourra récupérer ces informations d'identification sans demander d'autorisation supplémentaire. Cela peut représenter un risque pour votre système. Vous pourriez choisir de toujours demander votre mot de passe avant de lancer l'application, cependant.
Enfin, grâce à ceci, vous pouvez envelopper votre appel à fetchmail
avec un script tremplin qui configure le mot de passe à utiliser.
user=$USER
serveur=pop3.example.com
# ATTENTION : création et utilisation de fichiers temporaires non sécurisées
# Comme le mentionne [DAM][1], voir mkstemp(3)
fichier_temp=/tmp/fetchmailrc.$$
mot_de_passe=$(security find-internet-password -s $serveur -a $USER -g 2>&1 \
| perl -ne '/password: "(\S*)"/ et print $1')
# créer un fetchmailrc temporaire et le passer à fetchmail, etc...
cat < $fichier_temp
poll $serveur avec proto POP3 et options no dns
utilisateur $user avec mot de passe '$mot_de_passe' est $user ici
options keep mda '/usr/bin/procmail -d %T'
EoF
fetchmail -d -f $fichier_temp
rm -f $fichier_temp
Alors que cela atteint votre objectif déclaré de ne pas avoir de fichiers évidents contenant des mots de passe, j'ai noté les risques de sécurité encore présents avec cette configuration, que vous devriez prendre en compte.