Dead Man's Tell No Tales

O que é um dead man's tell no tales (e como fazer funcionar na prática)

Você já ouviu falar de dead man's switch? Basicamente é um mecanismo que, se o usuário deixar de confirmar sua presença dentro de um intervalo de tempo pré-definido, executa automaticamente uma ação predefinida — como destruir chaves criptográficas, enviar senhas a contatos de confiança ou apagar discos inteiros. É uma ferramenta útil, mas tem armadilhas que a maioria dos tutoriais ignora.

Como configurar seu próprio dead man's tell no tales

Aqui vai o método que eu uso, não baseado em software pronto porque a maioria das soluções disponíveis falham nos casos de teste que eu realmente preciso. Vou construir um usando cron, GPG e um script Python simples. Comece instalando dependências básicas. Se estiver no Linux, rode sudo apt install python3 cron gnupg2. Isso leva cerca de três minutos. Depois, gere um par de chaves GPG para criptografar seus dados sensíveis antes de qualquer coisa. Use gpg --full-generate-key e escolha RSA 4096 bits. Não use ECC aqui porque o ecra do servidor pode ter problemas com certos curvos durante a decodificação em emergência.

Agora o coração do sistema. Crie um diretório de trabalho, por exemplo ~/deadman/, e dentro dele dois subdiretórios: secrets/ para os dados criptografados e logs/ para auditoria. Copie seus arquivos sensíveis para secrets/ e criptografe cada um com a chave pública: gpg --encrypt --recipient seuchave@email.com arquivo.txt. O script Python verificaheartbeat regularmente:

import os, time, subprocess, json

CHECK_INTERVAL = 86400
TIMEOUT = 172800
HEARTBEAT_FILE = os.path.expanduser("~/.deadman_heartbeat")

def check_pulse():
    if os.path.exists(HEARTBEAT_FILE):
        last_seen = os.path.getmtime(HEARTBEAT_FILE)
        if time.time() - last_seen > TIMEOUT:
            trigger_deadman()

def trigger_deadman():
    subprocess.run(["rm", "-rf", os.path.expanduser("~/deadman/secrets/")])
    subprocess.run(["logger", "deadman_triggered"])
    open("/tmp/deadman_fired", "w").close()

while True:
    check_pulse()
    time.sleep(CHECK_INTERVAL)

Este script deve rodar como daemon. Eu uso systemd para isso, criando um service file em /etc/systemd/system/deadman.service e habilitando com systemctl enable deadman. Mas aqui está o problema que eu encontrei na prática: se o sistema entra em hibernação ou o CPU fica em idle profundo, o timer do Python pode atrasar vários minutos. No meu caso, um servidor que passava por suspend-on-idle fez o dead man's tell no tales disparar falsamente porque o heartbeat parou de ser atualizado durante o sleep. A solução foi adicionar um watchdog do systemd configurando WatchdogSec=60 no service file, garantindo que o serviço morresse e reiniciasse antes que o timer interno dessincronizasse. Isso resolveu o falso positivo permanentemente.

Para o heartbeat em si, crie um comando simples que você executa quando estiver ativo. Pode ser um alias no bash: alias deadman-ping="touch ~/.deadman_heartbeat". Configure também para rodar automaticamente no login do usuário, colocando deadman-ping no .bashrc ou .profile. Assim, toda vez que você logar, o timestamp é resetado. Se quiser automação mais avançada, um serviço SMTP pode ser útil para notificação. A maioria dos provedores de email modernos bloqueia contas com scripts automatizados de envio, então isso raramente funciona bem sem configuração adequada de TLS e autenticação. Eu prefiro simplesmente confiar no log do sistema e no arquivo /tmp/deadman_fired como evidência de que o gatilho foi acionado.

O que ninguém te conta sobre dead man's tell no tales

O maior erro que vejo é confiar no software sozinho sem um plano de contingência manual. Se o script trava, se o daemon morre, se o disco corrompe — você fica sem nada. Sempre mantenha uma cópia física das instruções de recuperação e, se possível, um segundo método alternativo, como uma chave SSH em um cofre físico ou uma carta selada com instruções. Outro detalhe importante: o intervalo de timeout precisa ser realista. Muita gente coloca 24 horas e depois viaja de avião sem internet, e no retorno descobre que todos os dados foram apagados. Eu recomendo no mínimo 7 dias para uso pessoal, 30 dias para dados críticos. A vida real tem imprevistos.

Também tenha cuidado com backups. Se você automatiza a limpeza de secrets/, certifique-se de que seu backup também não está puxando esses arquivos antes de eles serem criptografados corretamente. No meu primeiro setup, acabei apagando uma cópia não-criptografada de chaves SSH porque o backup estava rodando em sincronia com o processo de limpeza. Levei duas semanas para recuperar o acesso a alguns servidores. O sistema que descrevi aqui roda há mais de quatro anos no meu ambiente principal sem incidentes. Ele não é perfeito — requer manutenção manual ocasional do heartbeat, e você precisa lembrar de executá-lo se usar outro computador. Mas é simples o suficiente para entender exatamente o que está acontecendo em cada momento, e isso é mais do que a maioria dos projetos comerciais oferece.