# implant self-update

Atualiza o Implant para a versao mais recente. O download e arch-aware (detecta automaticamente a arquitetura do sistema) e protegido por TLS pinning.

# Uso

implant self-update [OPTIONS]

# Flags

# Variaveis de ambiente

# Exemplos

# Atualizar para ultima versao estavel

implant self-update

# Forcar reinstalacao

implant self-update --force

# Saida JSON para automacao

implant self-update --json

Retorna um objeto JSON com o resultado da atualizacao, util para integrar em scripts e pipelines. Com -o json ou --json, o stdout contem apenas o JSON (logs vao para o stderr).

# Atualizar sem o passo pos-atualizacao

implant self-update --no-post-update
IMPLANT_NO_POST_UPDATE=1 implant self-update

# Verificar a atualizacao sem instalar

implant self-update --dry-run

Executa as verificacoes ate a validacao da versao e para antes do backup/substituicao. Em JSON, reporta status=dry_run, backup_created=false e post_update.status=planned.

# Trocar entre estavel e release candidate

implant self-update --url https://implant.ccs.systems/$(uname -m)/rc/implant

A versao baixada e comparada com a instalada pela string inteira: a atualizacao so e pulada (status=skipped) quando as duas sao exatamente iguais. Assim, ir de X.Y.Z-rc.N para X.Y.Z (ou o contrario) funciona sem --force. Ate a 2.54.0, a comparacao era por substring e esse caso exigia --force.

# Processo

1. Detecta a arquitetura do sistema (x86_64 ou aarch64)
2. Verifica versao atual
3. Verifica certificado TLS via pinning (SPKI) antes do download
4. Baixa binario da URL correspondente a arquitetura
5. Verifica a assinatura minisign (.minisig) do binario
6. Valida o binario baixado (--version)
7. Cria backup do binario atual
8. Copia novo binario para o destino
9. Define permissoes 755
10. Remove backup
11. Executa o passo pos-atualizacao com o binario novo (v2.59.0+, ver abaixo)

# Passo pos-atualizacao (v2.59.0+)

Quando o binario foi de fato trocado, o self-update executa o binario novo (o caminho instalado, como processo filho) com:

implant firewall-restore ensure -o json --config <a mesma config>

O `firewall-restore ensure` so roda o rate-limit reconcile quando ele instalaria a unit de restore no boot (rate-limit gerenciado e ativo, unit faltando, antiga ou desabilitada). Em qualquer outro caso nao faz nada: o rate-limit nao e reaplicado a cada atualizacao. Assim, os servidores que ainda nao tinham a unit implant-firewall-restore passam a te-la na proxima atualizacao, com a mesma guarda do reconcile.

• Quando roda: so com o binario trocado. Nao roda em "ja esta na versao", em falha nem em --dry-run (que so mostra que rodaria, status: planned).
• Teto de 300 s: depois disso o processo filho e encerrado.
• Nunca derruba o update: falha nesse passo vira aviso na saida human e o campo post_update do JSON; o self-update continua bem-sucedido.
• Opt-out: --no-post-update ou IMPLANT_NO_POST_UPDATE=1 (status: disabled).

Com --json (ou -o json), o resultado traz post_update quando o status do update e completed ou dry_run:

"post_update": {
  "status": "ok",                      // ok | failed | planned (dry-run) | disabled (opt-out)
  "command": "/usr/local/bin/implant firewall-restore ensure",
  "boot_unit_action": "already_ok",    // o do ensure; null sem execucao
  "reconciled": false,                 // o ensure rodou o rate-limit reconcile
  "error": null,
  "duration_ms": 412
}

Quem roda o passo e o binario que faz o update. O passo existe a partir da v2.59.0, entao a atualizacao para a 2.59.0 (feita por um binario 2.58.0 ou anterior) nao o executa. O servidor so o ganha na atualizacao seguinte. Para nao esperar, rode-o a mao depois de atualizar:

sudo implant firewall-restore ensure

# URLs de Download

A arquitetura e detectada automaticamente via std::env::consts::ARCH.

Onde {arch} e x86_64 ou aarch64, detectado automaticamente.

A base de download pode ser trocada sem recompilar, na secao [endpoints] do config.toml:

[endpoints]
cdn_base = "https://downloads.example.com"

# Seguranca

• TLS Pinning: o certificado do servidor e verificado via hash SPKI embutido no binario antes de iniciar o download
• Arch-aware: o binario correto e baixado automaticamente para a arquitetura do servidor
• Assinatura minisign: nos dominios oficiais (com pin embutido) a verificacao e graciosa — .minisig ausente gera apenas aviso. Para qualquer outro host (--url ou cdn_base alternativos), uma .minisig valida e obrigatoria; sem ela a atualizacao e recusada
• Hosts sem pin: usam validacao TLS padrao (WebPKI); pins SPKI adicionais podem ser declarados em [[tls_pins]] no config.toml
• Validacao: o binario baixado e testado com --version antes de substituir o atual