--- title: "Tieni la chiave di trading e i secret di un'app lontano dal disco del server" description: "erpc worker tiene chiave di trading e secret di un'app in 1Password, nel portachiavi del sistema operativo o in un keystore cifrato e li dà all'app in memoria." canonical: "https://erpc.global/it/doc/erpc-cli/worker-secrets/" locale: "it" --- # Tieni la chiave di trading e i secret di un'app lontano dal disco del server `erpc worker` conserva la chiave di trading e i secret di un'app in 1Password, nel tuo portachiavi o in un keystore cifrato, e li consegna all'app in memoria, mai al disco del server. Questa pagina descrive ERPC CLI `v0.1.0-rc.4`, una versione pre-release. ## Come la chiave di trading raggiunge l'app Un'app con un wallet riceve la sua chiave su una pipe all'avvio. Sul server non c'è alcun `wallet.json`, nessun `.env` e nessuna copia. erpc non scrive la chiave in chiaro su nessun disco: l'unico file in cui la mette è quello del keystore, sulla tua macchina, cifrato con la tua passphrase. - **Dove viene conservata:** `erpc worker key new` crea la chiave in 1Password quando `erpc login` vi conserva la sessione, altrimenti nel portachiavi, altrimenti nel keystore. `erpc.toml` registra il riferimento della chiave e la sua chiave pubblica. - **Sul server:** l'agente di erpc worker tiene la chiave solo in memoria. Si rende non soggetto a dump, blocca la propria memoria e consegna la chiave all'app su un file descriptor; l'app la cancella dopo averla letta. - **Dopo un riavvio,** il worker torna bloccato: l'app non gira finché `erpc worker start` non invia di nuovo la chiave. Un agente che si arresta per un errore o viene terminato viene riavviato da systemd e torna bloccato allo stesso modo. - **Un aggiornamento dei pacchetti non riavvia un worker.** `deploy` indica a `needrestart` di lasciare stare le unità del worker: nella sua modalità automatica le rimanda, e quando chiede in un terminale la sua risposta predefinita per esse è no, così un aggiornamento di sicurezza non presidiato non riavvia l'app. Quando non è stato possibile scrivere quella regola, la distribuzione lo segnala e prosegue, e il worker gira poi senza questa protezione. La chiave di trading è indicata da `[wallet]` e da nient'altro, ed erpc la legge solo per una persona al terminale: non per uno strumento AI, e non con un account di servizio di 1Password. Una riga di `[secrets]` che indica il riferimento di `[wallet]`, o un account `keychain:` o `keystore:` che termina in `.wallet`, viene rifiutata. Nel keystore, una voce conservata come chiave non si apre come secret. In 1Password, e sotto un account del portachiavi con un altro nome, nulla contrassegna una chiave: un `erpc.toml` senza `[wallet]` che indica un elemento del genere sotto `[secrets]` lo fa leggere come secret. ## Scegliere dove conservare i valori 1Password è facoltativo. `erpc worker key new` e `erpc worker secret put` conservano ciò che ricevono nel primo di questi archivi che si applica, a meno che `--store` non ne indichi uno (`--store 1password --vault `, `--store keychain`, `--store keystore`): 1. **1Password**, quando `erpc login` vi conserva la sessione o quando è indicato `--vault`. 2. **Il portachiavi del sistema operativo**, dove conserva un valore anche dopo un riavvio: macOS, Windows e Linux con un keyring desktop in una sessione con accesso effettuato. 3. **Il keystore di erpc**, su una macchina Linux senza un keyring di questo tipo: un server headless, WSL, un login SSH. `--store keychain` su una macchina del genere viene rifiutato. Nel portachiavi o nel keystore, la chiave esiste solo su quella macchina, senza copie né sincronizzazione, e un'altra macchina non può leggere un riferimento `keychain:` o `keystore:`. Una macchina persa o cancellata significa che il wallet è perso: tienici poco, oppure usa 1Password, che ogni macchina con l'accesso al vault può leggere. Accedi a 1Password con `erpc login --store 1password-desktop`, oppure tramite `op signin` dove non c'è l'app desktop. Un account di servizio di 1Password può contenere i secret di un'app, ma erpc non legge una chiave di trading con un account di questo tipo. Con 1Password, ogni lettura può mostrare una richiesta di approvazione nell'app, ed erpc mostra uno spinner mentre attende. ## Conservare un secret I secret, come i token API e le chiavi RPC, vengono conservati allo stesso modo, ma raggiungono l'app come variabili d'ambiente, non su una pipe. `erpc worker secret put ` conserva il valore, e `[secrets]` in `erpc.toml` ne contiene solo il riferimento. ```bash 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`** crea il valore: 32 byte casuali, come 64 caratteri esadecimali. - **`--from-account`** conserva la prima delle chiavi RPC del tuo account che l'RPC condiviso accetta. Le chiavi vengono provate in ordine, a partire dalla principale, con un `getHealth` ciascuna e 8 secondi per rispondere. Una chiave che riceve la risposta 401 o 403 viene rifiutata e si prova la successiva, e viene conservata solo una chiave che l'RPC ha accettato. Il comando dice se si tratta della chiave principale dell'account o di un'altra (`account_key` con `--json`). - Nessuno dei due valori viene stampato, nemmeno con `--json`. Il primo uso del keystore, o un keystore bloccato, richiede una persona al terminale. - Le chiavi vengono provate da questa macchina, quindi una chiave limitata all'indirizzo del server viene rifiutata qui anche se lì funziona. Quando ogni chiave viene rifiutata, `--from-account` non conserva nulla, e conservi tu a mano la chiave che intendi usare, digitata senza che venga mostrata oppure passata tramite pipe. Quando non è stato possibile interrogare l'RPC, non conserva nulla e `erpc.toml` resta com'era; esegui di nuovo lo stesso comando. Per conservare una chiave a mano: ```bash erpc worker secret put ERPC_API_KEY # asks for the value, unseen ``` - `--replace` conserva un nuovo valore per un nome già impostato. `erpc worker secret list` elenca per nome le impostazioni secret e dove è conservata ciascuna. - Un'impostazione fornita da una linea dati (`GRPC_ENDPOINT`, `SHREDS_ENDPOINT`, `SOLANA_SEND_RPC_ENDPOINT`) non è mai un secret: la impostano `--grpc`, `--shreds` e `--unlimited`. Un riferimento in `[secrets]` o `[wallet]` è uno di questi: | Riferimento | Dove si trova il valore | | --- | --- | | `op:////` | 1Password, per id del vault e dell'elemento | | `keychain:/` | Il portachiavi del sistema operativo della macchina che lo ha conservato | | `keystore:/` | Il keystore di erpc sulla macchina che lo ha conservato | ## Il keystore Il keystore è la directory `~/.erpc/keystore` (`keystore` sotto `ERPC_HOME` quando questa è impostata). Su Linux e macOS le sue directory hanno i permessi `0700` e i suoi file `0600`; su Windows erpc non imposta permessi propri. - `master.json` contiene una chiave master casuale di 32 byte, sigillata con una chiave che PBKDF2-HMAC-SHA256 (600.000 iterazioni) ricava dalla tua passphrase. Ogni voce contiene un solo valore, sigillato con ChaCha20-Poly1305 sotto una chiave propria. - **La passphrase:** il primo `key new` o `secret put` che usa il keystore te la fa scegliere, digitandola due volte in un terminale, di 12 caratteri o più. erpc la accetta solo da quel prompt nascosto, mai da un argomento, da una variabile d'ambiente o da una pipe. - **Lo sblocco su Linux:** una volta che la passphrase ha aperto il keystore, lo sblocco viene conservato nel keyring persistente del kernel, in memoria, finché la macchina non si riavvia, finché il keyring non resta inutilizzato oltre la sua scadenza per inattività (tre giorni, salvo diversa impostazione del sistema) o fino a `erpc worker secret lock`. `erpc worker secret unlock` chiede la passphrase in anticipo e dice fino a quando vale lo sblocco. In una shell avviata senza un login proprio (`su` senza `-`, `sudo -E`), nessuno sblocco viene conservato e ogni comando chiede la passphrase. - **Senza nessuno al terminale,** un comando che ha bisogno del keystore usa lo sblocco quando c'è, e altrimenti fallisce, indicando `erpc worker secret unlock`. Un keystore sbloccato consegna i secret, non la chiave di trading. - **Su macOS e Windows** (`--store keystore`), nessuno sblocco viene conservato: ogni comando che ha bisogno del keystore chiede la passphrase una volta, e quindi richiede un terminale. ### Cosa protegge il keystore e cosa no - **Fai il backup della directory `keystore` e ricorda la passphrase.** erpc non può recuperare né l'una né l'altra, e se ne manca anche solo una, ciò che il keystore contiene è perso. - Chi ha i file del keystore e la passphrase ha la chiave. PBKDF2 rende lento ogni tentativo, ma non rende sicura una passphrase facile da indovinare. - Mentre il keystore è sbloccato, qualsiasi programma eseguito con il tuo utente può leggere la chiave master dal keyring del kernel (un programma la cui sessione non contiene il tuo keyring può collegarlo alla propria sessione) e aprire ogni voce, anche quella di una chiave. Le regole proprie di erpc (leggere la chiave indicata da `[wallet]` solo per una persona al terminale, mai per uno strumento AI; non aprire mai come secret una chiave conservata nel keystore) sono ciò che fa erpc; non vincolano gli altri programmi eseguiti con il tuo utente. Esegui `erpc worker secret lock` quando hai finito. - I nomi delle voci non sono nascosti, e la dimensione di una voce rivela la lunghezza del valore. - Un file modificato non si apre; una copia più vecchia della stessa voce rimessa al suo posto invece sì. - `erpc worker secret rm` elimina la voce del keystore di un secret insieme alla sua riga in `erpc.toml` (a meno che un'altra impostazione dell'app non indichi la stessa voce), e lascia dov'è un valore in 1Password o nel portachiavi. Non cancella i dati dal disco in modo sicuro, e le copie nei tuoi backup restano. - erpc non elimina né sovrascrive mai la voce di una chiave di trading. Per sostituire una chiave, sposta i fondi, poi rimuovi tu stesso il suo file e `[wallet]`. - Un'impostazione non può chiamarsi `WALLET`, con qualsiasi combinazione di maiuscole e minuscole, nel keystore o nel portachiavi; `--store 1password` accetta questo nome. ## Lavorare con la chiave di trading | Comando | Cosa fa | | --- | --- | | `erpc worker key new` | Crea la chiave di trading e stampa la chiave pubblica da finanziare | | `erpc worker key import ` | Sposta un file di chiave in 1Password, nel portachiavi o nel keystore, poi propone di cancellare il file | | `erpc worker key show` | Mostra la chiave pubblica della chiave e dove è conservata | | `erpc worker key balance` | Mostra il saldo della chiave, tramite l'impostazione RPC dell'app stessa | | `erpc worker key send --to
--sol ` | Firma un trasferimento in memoria dopo il tuo sì in un terminale. `--all` invia tutto tranne la commissione | Quando erpc termina senza sapere se un trasferimento è andato a buon fine, cerca la sua firma prima di inviare di nuovo: un secondo invio è un secondo trasferimento.