Mantenha a chave de trading e os segredos de uma aplicação fora do disco do servidor

Como a chave de trading chega à aplicação

• Onde fica guardada: o erpc worker key new cria a chave no 1Password quando o erpc login mantém a sessão lá; caso contrário, no chaveiro; caso contrário, no keystore. O erpc.toml registra a referência da chave e a chave pública dela.
• No servidor: o agente do erpc worker mantém a chave apenas na memória. Ele impede que seja feito um dump de si mesmo e bloqueia a própria memória, e entrega a chave à aplicação por um descritor de arquivo; a aplicação a apaga depois de ler.
• Depois de uma reinicialização, o worker volta bloqueado: a aplicação não roda até que o erpc worker start envie a chave de novo. Um agente que falha ou é encerrado à força é iniciado de novo pelo systemd e volta bloqueado da mesma forma.
• Uma atualização de pacote não reinicia um worker. O deploy instrui o needrestart a deixar as unidades do worker em paz: no modo automático, ele as adia, e, quando pergunta em um terminal, a resposta padrão para elas é não, então uma atualização de segurança sem supervisão não reinicia a aplicação. Quando essa regra não pôde ser escrita, a implantação avisa e continua, e o worker passa a rodar sem essa proteção.

Escolher onde os valores ficam guardados

1. 1Password, quando o erpc login mantém a sessão lá ou quando --vault é informado.
2. O chaveiro do sistema operacional, nos sistemas em que ele mantém um valor após uma reinicialização: macOS, Windows e Linux com um keyring de desktop em uma sessão com login.
3. O keystore do erpc, em uma máquina Linux sem esse keyring: um servidor headless, WSL, um login SSH. --store keychain em uma máquina assim é recusado.

Guardar um segredo

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 cria o valor: 32 bytes aleatórios, como 64 caracteres hexadecimais.
• --from-account guarda a primeira das chaves RPC da sua conta que o RPC compartilhado aceita. As chaves são testadas em ordem, a principal primeiro, com um getHealth cada, com 8 segundos para responder. Uma chave que recebe 401 ou 403 como resposta é recusada e a próxima é testada, e só é guardada uma chave que o RPC aceitou. O comando informa se é a chave principal da conta ou outra (account_key com --json).
• Nenhum dos valores é exibido, nem com --json. O primeiro uso do keystore, ou de um keystore bloqueado, exige uma pessoa em um terminal.
• As chaves são testadas a partir desta máquina, então uma chave limitada ao endereço do servidor é recusada aqui, embora funcione lá. Quando todas as chaves são recusadas, o --from-account não guarda nada, e você guarda manualmente a chave que pretende usar, digitada sem aparecer na tela ou passada por um pipe. Quando não foi possível consultar o RPC, ele não guarda nada e o erpc.toml fica como estava; execute o mesmo comando de novo.

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 guarda um novo valor para um nome que já está definido. erpc worker secret list lista as configurações secretas por nome e onde cada uma está guardada.
• Uma configuração que uma linha de dados fornece (GRPC_ENDPOINT, SHREDS_ENDPOINT, SOLANA_SEND_RPC_ENDPOINT) nunca é um segredo: --grpc, --shreds e --unlimited a definem.

O keystore

• O master.json contém uma chave mestra aleatória de 32 bytes, selada com uma chave que o PBKDF2-HMAC-SHA256 (600.000 iterações) deriva da sua frase-senha. Cada entrada contém um valor, selado com ChaCha20-Poly1305 com uma chave própria.
• A frase-senha: o primeiro key new ou secret put que usa o keystore pede que você a escolha, digitada duas vezes em um terminal, com 12 caracteres ou mais. O erpc a recebe somente desse prompt oculto, nunca de um argumento, de uma variável de ambiente ou de um pipe.
• Desbloqueio no Linux: depois que a frase-senha abre o keystore, o desbloqueio fica guardado no keyring persistente do kernel, na memória, até a máquina reiniciar, até o keyring ficar sem uso pelo tempo de expiração por inatividade (três dias, a menos que o sistema defina outro) ou até erpc worker secret lock. O erpc worker secret unlock pede a frase-senha com antecedência e informa até quando o desbloqueio vale. Em um shell iniciado sem um login próprio (su sem -, sudo -E), nenhum desbloqueio é guardado e cada comando pede a frase-senha.
• Sem ninguém em um terminal, um comando que precisa do keystore usa o desbloqueio quando ele existe e, caso contrário, falha, indicando erpc worker secret unlock. Um keystore desbloqueado entrega segredos, não a chave de trading.
• No macOS e no Windows (--store keystore), nenhum desbloqueio é guardado: cada comando que precisa do keystore pede a frase-senha uma vez e, por isso, precisa de um terminal.

O que o keystore protege e o que não protege

• Faça backup do diretório keystore e lembre-se da frase-senha. O erpc não consegue recuperar nenhum dos dois, e, se faltar qualquer um dos dois, o que o keystore guarda está perdido.
• Quem tem os arquivos do keystore e a frase-senha tem a chave. O PBKDF2 torna cada tentativa lenta, mas não torna segura uma frase-senha fácil de adivinhar.
• Enquanto o keystore está desbloqueado, qualquer programa executado com o seu usuário pode ler a chave mestra no keyring do kernel (um programa cuja sessão não contém o seu keyring pode vinculá-lo à própria sessão) e abrir todas as entradas, inclusive a de uma chave. As regras próprias do erpc (ler a chave indicada pelo [wallet] só para uma pessoa em um terminal, nunca para uma ferramenta de IA; nunca abrir como segredo uma chave guardada no keystore) são o que o erpc faz; elas não obrigam outros programas executados com o seu usuário. Execute erpc worker secret lock quando terminar.
• Os nomes das entradas não são ocultos, e o tamanho de uma entrada mostra o comprimento do valor.
• Um arquivo alterado não abre; uma cópia mais antiga da mesma entrada colocada de volta no lugar abre.
• erpc worker secret rm exclui a entrada de um segredo no keystore junto com a linha dele no erpc.toml (a menos que outra configuração da aplicação indique a mesma entrada) e deixa no lugar um valor que esteja no 1Password ou no chaveiro. Ele não limpa o disco, e as cópias nos seus backups permanecem.
• O erpc nunca exclui nem sobrescreve a entrada de uma chave de trading. Para substituir uma chave, transfira os fundos e depois remova você mesmo o arquivo dela e o [wallet].
• Uma configuração não pode se chamar WALLET, com qualquer combinação de maiúsculas e minúsculas, no keystore ou no chaveiro; o --store 1password aceita esse nome.

Trabalhar com a chave de trading