Controle de telegrama (removido)

A ponte Telegram enviada em v0.1.27 e foi removido em v0.2.0.

Uma análise de segurança revelou três coisas que eu não estava disposto a deixar em execução:

• O allow_exec portão não fez nada. /send e /say - sempre ligado, mesmo com o executivo desligado - passou tmux send-keys com interpretação de nome-chave, para que qualquer bate-papo emparelhado possa enviar C-c e digite um comando shell.
• Alertas desapareceram silenciosamente para projetos com nomes com mais de 23 caracteres. Os botões Aprovar/Negar colocaram o nome da sessão duas vezes no campo de retorno de chamada de 64 bytes do Telegram, o Telegram rejeitou a mensagem inteira e a ponte a registrou e continuou. Você simplesmente nunca recebeu a notificação.
• Comandos enfileirados reproduzidos na reinicialização. Qualquer coisa enviada enquanto o daemon estava inativo foi executada quando voltou — incluindo um /kill confirmação de horas antes.

Puxar foi mais rápido do que consertar sob pressão, então foi isso que fiz.

Se você tivesse configurado: ccmux telegram se foi, e o [telegram] bloco sai de config.toml na próxima vez que a configuração for salva - incluindo bot_token. Nada mais em sua configuração é tocado.

O que usar em vez disso

Moshi faz o mesmo trabalho em um telefone: um push quando um agente precisa de você e, em seguida, um toque para anexar. A configuração é ccmux moshi-setup — consulte Primeiros passos.

Construindo sua própria superfície de controle? ccmuxd expõe um HTTP API na sua tailnet.

Vai voltar?

Talvez. O código está a uma reversão de distância e todos os três problemas têm soluções conhecidas – modo literal send-keys, IDs de retorno de chamada curtos e drenagem do backlog na inicialização. Ele volta quando chega o tempo de revisão que deveria ter acontecido na primeira vez.

Detectou um erro ou algo desatualizado? Edite esta página em GitHub.