O problema das extensões de IDE

06.05.20264 min de leituraEquipa Atalaia

Equipas que analisam todas as dependências de um lockfile muitas vezes deixam os programadores instalar qualquer extensão de editor que queiram. No entanto, uma extensão está mais perto das joias da coroa do que a maioria dos pacotes: corre no portátil que guarda o código-fonte, as chaves SSH e as credenciais de cloud, todos os dias de trabalho.

Este artigo explica como as extensões funcionam realmente, a que conseguem chegar e uma forma prática de ter um inventário e uma allowlist sem começar uma guerra.

Como correm as extensões de editor

Na maioria dos editores populares, as extensões são pacotes de JavaScript, por vezes com binários nativos, que o editor carrega num processo extension host. Esse processo corre como o utilizador com sessão iniciada. Normalmente não há um pedido de permissão por extensão como o que uma aplicação de telemóvel mostraria.

Na prática, uma extensão pode:

• Ler e escrever qualquer ficheiro a que o utilizador tenha acesso, não só os ficheiros do workspace aberto.
• Lançar processos, incluindo shells, compiladores e gestores de pacotes.
• Fazer pedidos de rede de saída para qualquer host.
• Ler variáveis de ambiente, que muitas vezes incluem tokens exportados num perfil de shell.
• Aceder a segredos e definições guardados no editor, e ligar-se a terminais e ao controlo de versões.

Alguns editores oferecem um modo restrito para workspaces não fiáveis, que limita o que corre quando abre uma pasta desconhecida. É útil, mas protege contra repositórios hostis, não contra uma extensão que já instalou e em que confia.

O caminho de atualização é o verdadeiro risco

Uma extensão que reviu no ano passado não é a extensão que corre hoje. Os marketplaces enviam atualizações automaticamente por omissão, e as contas dos publishers podem mudar de mãos ou ser comprometidas. O padrão espelha os ataques a package registries.

1. ConfiançaUma extensão útil ganha uma grande base de instalações ao longo do tempo.
2. MudançaA conta do publisher é vendida, sofre phishing ou passa para um novo maintainer.
3. AtualizaçãoSai uma nova versão com código extra. Os editores instalam-na em silêncio.
4. CorrerNo arranque seguinte executa com as permissões do programador em todas as máquinas que o têm.
5. AlcançarLê tokens, chaves ou código e envia-os para fora.

Os nomes parecidos são a outra via: uma extensão com um ícone familiar e um nome a um carácter de distância de outra popular. Ambos são razões para "veio do marketplace" não ser uma revisão.

Inventariar extensões numa equipa

Não pode fazer allowlist do que não viu. Comece por recolher o que está instalado hoje. A maioria dos editores da família VS Code expõe uma CLI para isto:

# List installed extensions with versions
code --list-extensions --show-versions

# Extensions also live on disk, one folder per extension@version
ls ~/.vscode/extensions

Os IDEs da JetBrains guardam os plugins numa pasta por versão, dentro do diretório de configuração ou de suporte de aplicações do utilizador, e outros editores seguem padrões semelhantes. Escreva um pequeno script que recolha a lista e o hostname e peça às pessoas que o corram, ou distribua-o pela sua ferramenta de gestão de dispositivos, se tiver uma.

#!/usr/bin/env sh
# collect-extensions.sh: print host, editor and extension@version as CSV
host=$(hostname)
for cli in code codium cursor; do
  command -v "$cli" >/dev/null 2>&1 || continue
  "$cli" --list-extensions --show-versions 2>/dev/null \
    | sed "s/^/$host,$cli,/"
done

Junte os resultados numa folha e ordene por ID de extensão. Normalmente verá uma cauda longa: um conjunto base que a maioria partilha, e muitas instalações únicas.

Construir uma allowlist que as pessoas aceitem

Uma allowlist que bloqueia metade da equipa no primeiro dia vai ser contornada. Construa-a a partir do inventário.

Em cada revisão, verifique o publisher, o repositório de origem se existir, o número de instalações e a idade, em que eventos declara ativar-se e se inclui binários nativos. Registe a extensão pelo ID completo, não pelo nome de apresentação, para que as imitações não passem.

Vários editores suportam definições de política que restringem as instalações a extensões aprovadas ou desligam a atualização automática. Use-as quando a lista estiver estável e considere fasear as atualizações das extensões principais em vez de aceitar cada release no momento em que sai.

O que fazer na segunda-feira

1. Corra code --list-extensions --show-versions na sua máquina e leia a lista. Há algo que não reconhece?
2. Partilhe o script de recolha com a equipa e reúna os resultados num só sítio.
3. Separe pelas quatro categorias acima. Aprove primeiro o conjunto base; cobre a maioria das instalações.
4. Escreva um processo de um parágrafo para pedir uma nova extensão, com um revisor nomeado e um prazo de resposta curto.
5. Repita o inventário todos os meses. O que importa vigiar é o desvio, não a primeira fotografia.

As extensões são ferramentas da linha como quaisquer outras. Saber quais estão em cada bancada, e quem as aprovou, é o trabalho todo.

Onde isto fica na linha

Na torre (em desenvolvimento):