O SecretSpec sempre manteve a declaração em secretspec.toml separada do valor armazenado. A versão 0.18 traz ambos os lados desse ciclo de vida para o CLI.
secretspec add adiciona uma declaração ao perfil selecionado enquanto preserva os comentários, formatação e tabelas não relacionadas do manifesto:
$ secretspec add STRIPE_API_KEY --description "Token de acesso do Stripe API"
✓ Adicionado segredo 'STRIPE_API_KEY' ao perfil 'default' em secretspec.toml
Defina seu valor com: secretspec set STRIPE_API_KEY --profile default
$ secretspec set STRIPE_API_KEY
Entre com o valor para STRIPE_API_KEY: ********
✓ Segredo 'STRIPE_API_KEY' salvo no keyring (perfil: default)
O comando add nunca solicita ou armazena o valor. A declaração pode ser revisada e comprometida antes que cada desenvolvedor ou implantação forneça seu próprio valor.
secretspec delete faz o inverso no lado de armazenamento: remove um valor sem alterar a declaração. O próximo check, portanto, relata o segredo como ausente em vez de removê-lo silenciosamente:
$ secretspec delete STRIPE_API_KEY
1 segredo removido; 0 já ausentes
A exclusão é idempotente, invalida uma entrada de cache associada e segue a mesma roteirização primária-escrita-provedora que set. O comando delete --all requer uma confirmação interativa ou um --yes explícito em uso não interativo.
Migrações de provedores podem agora remover cada valor fonte após provar que a transferência foi bem-sucedida:
secretspec import dotenv:~/.config/payments/.env --delete-source
O comando import --delete-source lê o destino de volta e compara com a fonte antes de excluir qualquer coisa. Um valor idêntico já no destino é seguro para remover da fonte; um valor conflitante mantém a fonte intacta. O SecretSpec também rejeita uma fonte sem suporte à exclusão antes de escrever o destino e reconhece escritórios equivalentes como o mesmo armazenamento, então uma migração não pode excluir o valor que acabou de escrever por meio de outro alias.
Juntos esses comandos mantêm a distinção explícita: add altera o que a aplicação declara, set e delete alteram o valor armazenado em um ambiente e import --delete-source move esse valor entre os armazenamentos.
O primeiro comando SecretSpec em um projeto existente é frequentemente secretspec init --from .env. Na versão 0.18, init --from aceita cada provedor que pode descobrir declarações, incluindo age, AWS Parameter Store e Bitwarden Password Manager.
Armazenamentos hierárquicos também recebem um projeto e perfil explícitos para que o SecretSpec procure apenas dentro do namespace que o novo manifesto usará:
--from 'awsps://production@us-east-1?template=/{profile}/{project}/{key}' \
✓ Created secretspec.toml with 12 secrets
Para um cofre de gerenciador de senhas, descubra o escopo para a coleção e tipo de item que pertencem ao aplicativo:
$ secretspec init --from 'bw://Acme%20Inc@dev-secrets?type=login'
✓ Created secretspec.toml with 8 secrets
A descoberta escreve nomes e descrições geradas, nunca valores secretos. Após revisar o manifesto, mantenha o provedor descoberto como a fonte do perfil ou use secretspec import para copiar os agora declarados valores para outro lugar.
A versão 0.18 traz SecretSpec para 24 provedores, com quatro adições abrangendo gerenciadores de senhas pessoais, cofres orientados a máquinas e armazenamento de parâmetros em nuvem.
Bitwarden Password Manager é separado do provedor existente Bitwarden Secrets Manager. O novo bw:// provedor usa a CLI oficial bw para ler e escrever itens regulares de cofre: logins, notas seguras, cartões, identidades e chaves SSH. Ele pode se referir a organizações e coleções por nome ou ID, restringir um provedor a um tipo de item ou campo específico, descobrir declarações e apontar ref segredos para itens existentes. Um guard ?server= verifica que a CLI está conectada à instância autosservida esperada em vez de ler silenciosamente o cofre errado.
Keeper Secrets Manager usa a SDK oficial Rust do Keeper, então não precisa de uma CLI separada. Um keeper://FOLDER_UID provedor lê, escreve, faz lotes e deleta registros convencionais compartilhados com um aplicativo KSM; refs podem selecionar um registro existente e campo. Sua configuração de cliente pode vir do KSM_CONFIG, um arquivo de configuração protegido ou credenciais de provedor SecretSpec.
AWS Systems Manager Parameter Store armazena cada valor como uma KMS-encrypted SecureString. O awsps:// provedor usa as cadeias padrão de credenciais e regiões AWS e suporta perfis compartilhados-config, prefixos hierárquicos, modelos completos {project} / {profile} / {key}, chaves KMS gerenciadas pelo cliente e níveis de parâmetro. Refs podem selecionar um parâmetro existente por nome, versão, rótulo ou ARN; refs não versionadas são escritáveis enquanto revisões fixas permanecem somente leitura. Sua descoberta hierárquica limitada usa GetParametersByPath sem descriptografar valores.
Dashlane lê segredos, notas seguras e logins através da CLI dcli. É intencionalmente somente leitura porque dcli não pode criar ou editar itens de cofre. Uma ref pode se referir a um item existente por título ou identificador e selecionar um de seus campos. CI pode fornecer diretamente DASHLANE_SERVICE_DEVICE_KEYS ou originar o mesmo service_device_keys entrada de outro provedor SecretSpec.
Um projeto pode roteirizar diferentes segredos através de qualquer combinação deles:
team_vault = "bw://Acme%20Inc@dev-secrets"
keeper_ci = "keeper://SHARED_FOLDER_UID"
parameters = "awsps://production@us-east-1?prefix=/platform"
dashlane_notes = "dashlane://note"
A escolha do provedor continua fora do código da aplicação. A CLI e cada SDK resolvem a mesma declaração independentemente de qual desses alias forneça um valor.
O novo SDK Swift traz o resolutor compartilhado SecretSpec para macOS 12 ou posterior em Intel e Apple silicon. Adicione o repositório como um pacote Swift:
url: "https://github.com/cachix/secretspec",
Em seguida, use o mesmo vocabulário de construção dos outros SDKs:
let resolved =try SecretSpec.builder()
.withProfile("production")
.withReason("boot web app")
defer { try? resolved.close() }
print(resolved.secrets["DATABASE_URL"]?.get()??"")
try resolved.setAsEnvironment()
O SDK expõe resolução fluente e em um único disparo, falhas tipadas, relatórios
pré-voo sem valor, escopos, origem, exportação de ambiente e entrada JSON para
desenvolvimento Swift gerado. Chamando close() remove deterministicamente
arquivos temporários criados para segredos as_path.
A versão do SwiftPM contém um XCFramework com soma de verificação que inclui o desresolutor Rust, então uma aplicação não precisa nem de uma ferramentachain Rust nem de uma biblioteca SecretSpec instalada separadamente.
Vault e OpenBao não sempre usam o nome padrão
de montagem approle e jwt. Os URIs dos provedores podem agora escolher
um monte relativo a /v1/auth:
vault://vault.example.com:8200/secret?auth=approle&auth_mount=platform-approle
openbao://bao.example.com:8200/secret?auth=jwt&auth_mount=ci-jwt&role=deploy
A autenticação AppRole pode omitir secret_id quando o papel do servidor é
configurado com bind_secret_id=false. A autenticação JWT também pode omitir seu
papel quando a montagem selecionada tiver um papel de servidor configurado como
default_role. Entradas explícitas de URI, ambiente ou credenciais do provedor
continuam tendo precedência.
A versão 0.18 também faz dois fluxos de trabalho locais menos dependentes da configuração específica da máquina:
- caminhos personalizados dotenv aceitam um prefixo
~, resolvido para o diretório home do usuário atual; - construções Linux keyring usam a transportação Secret Service nativa Rust da keyring 4, então binários SecretSpec não precisam mais de
libdbus.
Manifiestos e provedores existentes continuam funcionando sem alterações. Os novos comandos, provedores e SDKs são opt-in.
Consulte o changelog completo para todas as mudanças e correções nesta versão.
Tem perguntas ou feedback? Participe conosco no Discord.