Garder la clé de trading et les secrets d'une application hors du disque du serveur

Comment la clé de trading parvient à l'application

• Où elle est conservée : erpc worker key new crée la clé dans 1Password lorsque erpc login y conserve la session, sinon dans le trousseau, sinon dans le keystore. erpc.toml contient la référence de la clé et sa clé publique.
• Sur le serveur : l'agent d'erpc worker ne garde la clé qu'en mémoire. Il se rend non dumpable, verrouille sa mémoire et transmet la clé à l'application sur un descripteur de fichier ; l'application l'efface après l'avoir lue.
• Après un redémarrage, le worker revient verrouillé : l'application ne s'exécute pas tant que erpc worker start n'a pas renvoyé la clé. Un agent qui échoue ou est tué est redémarré par systemd et revient verrouillé de la même façon.
• Une mise à jour de paquet ne redémarre pas un worker. deploy indique à needrestart de ne pas toucher aux unités du worker : en mode automatique, il les reporte, et, lorsqu'il est interrogé dans un terminal, sa réponse par défaut pour elles est non ; une mise à jour de sécurité sans surveillance ne redémarre donc pas l'application. Lorsque cette règle n'a pas pu être écrite, le déploiement le signale et continue, et le worker fonctionne alors sans cette protection.

Choisir où conserver les valeurs

1. 1Password, lorsque erpc login y conserve la session ou que --vault est indiqué.
2. Le trousseau de l'OS, là où il conserve une valeur au-delà d'un redémarrage : macOS, Windows, et Linux avec un keyring de bureau dans une session ouverte.
3. Le keystore d'erpc, sur une machine Linux sans un tel keyring : un serveur headless, WSL, une connexion SSH. --store keychain est refusé sur une telle machine.

Conserver un secret

erpc worker secret put API_TOKEN --generate          # the bot's own API token, made for you and shown to nobody
erpc worker secret put ERPC_API_KEY --from-account   # the account's RPC key, read from your account (or SOLANA_RPC_ENDPOINT in [vars])

erpc worker secret put API_TOKEN --generate          # the bot's own API token, made for you and shown to nobody
erpc worker secret put ERPC_API_KEY --from-account   # the account's RPC key, read from your account (or SOLANA_RPC_ENDPOINT in [vars])

• --generate crée la valeur : 32 octets aléatoires, sous forme de 64 caractères hexadécimaux.
• --from-account conserve la première des clés RPC de votre compte que le RPC partagé accepte. Les clés sont essayées dans l'ordre, la clé principale en premier, avec un getHealth chacune et 8 secondes pour répondre. Une clé qui reçoit la réponse 401 ou 403 est refusée et la suivante est essayée, et seule une clé que le RPC a acceptée est conservée. La commande indique s'il s'agit de la clé principale du compte ou d'une autre (account_key avec --json).
• Aucune des deux valeurs n'est affichée, pas même avec --json. La première utilisation du keystore, ou un keystore verrouillé, nécessite une personne devant le terminal.
• Les clés sont essayées depuis cette machine : une clé limitée à l'adresse du serveur est donc refusée ici, bien qu'elle fonctionne là-bas. Lorsque toutes les clés sont refusées, --from-account ne conserve rien, et vous conservez vous-même la clé voulue, saisie sans affichage ou transmise par un pipe. Lorsque le RPC n'a pas pu être interrogé, rien n'est conservé et erpc.toml reste tel quel ; relancez la même commande.

erpc worker secret put ERPC_API_KEY        # asks for the value, unseen

erpc worker secret put ERPC_API_KEY        # asks for the value, unseen

• --replace conserve une nouvelle valeur pour un nom déjà défini. erpc worker secret list liste les paramètres secrets par nom, avec l'endroit où chacun est conservé.
• Un paramètre que fournit une ligne de données (GRPC_ENDPOINT, SHREDS_ENDPOINT, SOLANA_SEND_RPC_ENDPOINT) n'est jamais un secret : --grpc, --shreds et --unlimited le définissent.

Le keystore

• master.json contient une clé maîtresse aléatoire de 32 octets, scellée sous une clé que PBKDF2-HMAC-SHA256 (600 000 itérations) dérive de votre phrase de passe. Chaque entrée contient une valeur, scellée avec ChaCha20-Poly1305 sous une clé qui lui est propre.
• La phrase de passe : le premier key new ou secret put qui utilise le keystore vous la fait choisir, saisie deux fois dans un terminal, de 12 caractères ou plus. erpc ne la prend que depuis cette invite masquée, jamais depuis un argument, une variable d'environnement ou un pipe.
• Déverrouillage sous Linux : une fois que la phrase de passe a ouvert le keystore, le déverrouillage est conservé dans le keyring persistant du noyau, en mémoire, jusqu'au redémarrage de la machine, jusqu'à ce que le keyring reste inutilisé pendant son délai d'expiration d'inactivité (trois jours, sauf si le système en décide autrement), ou jusqu'à erpc worker secret lock. erpc worker secret unlock demande la phrase de passe à l'avance et indique jusqu'à quand. Dans un shell lancé sans connexion propre (su sans -, sudo -E), aucun déverrouillage n'est conservé et chaque commande demande la phrase de passe.
• Sans personne devant le terminal, une commande qui a besoin du keystore utilise le déverrouillage s'il en existe un, et échoue sinon, en indiquant erpc worker secret unlock. Un keystore déverrouillé transmet les secrets, pas la clé de trading.
• Sous macOS et Windows (--store keystore), aucun déverrouillage n'est conservé : chaque commande qui a besoin du keystore demande la phrase de passe une fois, et nécessite donc un terminal.

Ce que le keystore protège, et ce qu'il ne protège pas

• Sauvegardez le répertoire keystore et retenez la phrase de passe. erpc ne peut récupérer ni l'un ni l'autre, et s'il manque l'un ou l'autre, ce que contient le keystore est perdu.
• Quiconque possède les fichiers du keystore et la phrase de passe possède la clé. PBKDF2 ralentit chaque tentative, mais ne rend pas sûre une phrase de passe devinable.
• Tant que le keystore est déverrouillé, tout programme qui s'exécute sous votre utilisateur peut lire la clé maîtresse dans le keyring du noyau (un programme dont la session ne contient pas votre keyring peut l'y rattacher) et ouvrir chaque entrée, y compris celle d'une clé. Les règles propres à erpc (ne lire la clé désignée par [wallet] que pour une personne devant le terminal, jamais pour un outil d'IA ; ne jamais ouvrir comme secret une clé conservée dans le keystore) décrivent ce que fait erpc ; elles ne s'imposent pas aux autres programmes qui s'exécutent sous votre utilisateur. Exécutez erpc worker secret lock lorsque vous avez terminé.
• Les noms des entrées ne sont pas masqués, et la taille d'une entrée révèle la longueur de la valeur.
• Un fichier modifié ne s'ouvre pas ; une copie plus ancienne de la même entrée remise à sa place s'ouvre, elle.
• erpc worker secret rm supprime l'entrée de keystore d'un secret ainsi que sa ligne dans erpc.toml (sauf si un autre paramètre de l'application nomme la même entrée), et laisse en place une valeur stockée dans 1Password ou le trousseau. Il n'écrase pas les données sur le disque, et les copies présentes dans vos sauvegardes subsistent.
• erpc ne supprime ni n'écrase jamais l'entrée d'une clé de trading. Pour remplacer une clé, transférez les fonds, puis retirez vous-même son fichier et [wallet].
• Un paramètre ne peut pas s'appeler WALLET, quelle que soit la casse, dans le keystore ou le trousseau ; --store 1password accepte ce nom.

Utiliser la clé de trading