Migrando ferramentas para o Python 3.13 no Kali

Quem utiliza distribuições rolling-release como o Kali Linux ou atualizou o ambiente para o Python 3.13 certamente já se deparou com scripts antigos quebrando em cascata. O ecossistema Linux avança rápido: novas políticas de segurança criptográfica no sistema operacional e mudanças estruturais profundas no interpretador do Python costumam inviabilizar ferramentas que dependem de versões antigas e métodos de compilação ultrapassados.

Neste artigo, vamos acompanhar a resolução prática de uma sequência real de falhas ao instalar uma ferramenta de auditoria: desde problemas no handshake TLS ao clonar repositórios Git, passando pelo bloqueio de ambientes gerenciados (PEP 668), até erros na C-API interna do Python 3.13 e a remoção de módulos clássicos da biblioteca padrão.

1. Falha de certificados TLS ao clonar repositórios com Git#

Ao tentar clonar um repositório pelo Git, o processo foi interrompido antes de iniciar a transferência:

fatal: unable to access 'https://github.com/mxrch/GitFive/': Problem with the SSL CA cert (path? access rights?)

O que acontece por baixo dos panos#

O comando git clone invoca o binário auxiliar git-remote-https, linkado à biblioteca libcurl.so, que por sua vez utiliza o OpenSSL ou GnuTLS para validar certificados.

Esse erro não indica queda de conexão ou falha de DNS, mas sim a incapacidade do subsistema TLS de localizar ou ler o pacote de certificados raiz confiáveis (CA bundle) do sistema.

Rastreando chamadas de sistema com strace#

Para descobrir se o problema era um arquivo inexistente (ENOENT) ou permissão negada (EACCES), inspecionamos as chamadas de abertura de arquivos:

GIT_CURL_VERBOSE=1 strace -f -e trace=open,openat git clone https://github.com/mxrch/GitFive 2>&1 | grep -E "cert|ca-"

Se o retorno mostrar -1 ENOENT, o caminho para o arquivo .crt está quebrado. Para reconstruir o armazenamento de certificados confiáveis da distribuição:

sudo apt-get install --reinstall ca-certificates -y
sudo update-ca-certificates --fresh

A flag --fresh remove links simbólicos corrompidos em /etc/ssl/certs/ e recria o índice de hashes criptográficos a partir do zero.

2. Quebra de escopo no build do pillow no Python 3.13#

Após corrigir o Git, o instalador de dependências falhou ao tentar compilar versões antigas da biblioteca de imagens Pillow:

  File ".../setuptools/build_meta.py", line 317, in run_setup
    exec(code, locals())
  File "<string>", line 26, in get_version
KeyError: '__version__'
ERROR: Failed to build 'Pillow' when getting requirements to build wheel

A mudança interna no Python 3.13#

Versões antigas do Pillow abriam o arquivo src/PIL/_version.py e chamavam exec(code, locals()) para extrair o número de versão dinamicamente.

No Python 3.13, o isolamento de escopo em funções e blocos compilados foi reforçado para ganhos de desempenho. Variáveis geradas dentro do exec() deixaram de vazar automaticamente para o dicionário do escopo chamador no build_meta. Como a chave __version__ não foi encontrada, o script falha.

Como resolver#

A solução definitiva é utilizar versões modernas do Pillow (10.0 ou superior), que usam declaração estática de metadados via pyproject.toml:

pip install "Pillow>=10.0.0"

3. Isolamento de pacotes do sistema operacional com PEP 668#

Ao tentar instalar pacotes diretamente pelo terminal, o instalador ativou uma trava de proteção:

error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install python3-xyz...
hint: See PEP 668 for the detailed specification.

O propósito do PEP 668#

Distribuições baseadas em Debian instalam o arquivo /usr/lib/python3.13/EXTERNALLY-MANAGED. O objetivo é impedir que o pip sobrescreva pacotes críticos em /usr/lib/python3/dist-packages/, o que quebraria utilitários essenciais do próprio sistema operacional mantidos pelo apt.

Três maneiras de lidar com a restrição#

Ambiente virtual (recomendado):

   python3 -m venv .venv
   source .venv/bin/activate
   pip install -r requirements.txt

Pacotes nativos da distribuição:

   sudo apt install python3-pil python3-requests

Instalação forçada (somente para testes ou containers descartáveis):

   pip install -r requirements.txt --break-system-packages

4. Rejeição de assinaturas SHA-1 antigas no APT pelo sequoia PGP#

Ao tentar instalar bibliotecas nativas via apt update, o gerenciador de pacotes travou com um erro de validação de repositório PPA de terceiros:

Erro: https://ppa.launchpadcontent.net/... InRelease
  Sub-process /usr/bin/sqv returned an error code (1):
  Signing key on ... is not bound: SHA1 is not considered secure since 2026-02-01

A descontinuação do SHA-1#

O utilitário sqv (Sequoia OpenPGP Verifier) adotado pelas distribuições modernas recusa assinaturas digitais baseadas em SHA-1 devido a riscos comprovados de colisão criptográfica. Quando um repositório externo utiliza chaves obsoletas, o apt update bloqueia a sincronização de pacotes para proteger o sistema.

Como remover a origem causadora#

Identifique o arquivo responsável pela lista de pacotes obsoleta:

grep -r "kelebek333" /etc/apt/sources.list*

Remova a configuração conflitante e limpe os metadados em cache:

sudo rm /etc/apt/sources.list.d/kelebek333-*.list
sudo apt-get clean
sudo apt-get update

5. Incompatibilidade de código c++ na c-API do Python 3.13#

Durante a instalação de extensões compiladas como levenshtein==0.20.5, o compilador g++ abortou com erros de campos ausentes em estruturas de dados internas:

error: ‘PyThreadState’ has no member named ‘curexc_type’
error: ‘PyLongObject’ has no member named ‘ob_digit’

O que mudou na c-API#

Como parte do trabalho para suporte a múltiplos interpretadores e remoção do GIL (Global Interpreter Lock), o Python 3.13 tornou opacas ou eliminou diversas estruturas internas que ficavam expostas em versões anteriores:

PyThreadState: membros como curexc_type e curexc_value foram privatizados para encapsular o tratamento de exceções.
PyLongObject: o array interno ob_digit foi reestruturado para permitir maior compactação e eficiência de inteiros pequenos na memória.

Códigos C++ gerados por versões antigas do Cython que tentam acessar esses campos diretamente não compilam no Python 3.13.

Como contornar#

Em vez de compilar a biblioteca antiga via pip, instale o pacote já corrigido e homologado pelo repositório da sua distribuição:

sudo apt install python3-levenshtein -y

E remova a trava rígida de versão no seu arquivo de dependências:

sed -i '/levenshtein==0.20.5/d' requirements.txt

6. A remoção do módulo cgi e a modernização do httpx#

Ao rodar o script principal, um erro imediato de importação interrompeu o programa:

  File ".../httpx/_models.py", line 1, in <module>
    import cgi
ModuleNotFoundError: No module named 'cgi'

O impacto do PEP 594#

O PEP 594 removeu módulos antigos e sem manutenção da biblioteca padrão do Python (conhecidos historicamente como "baterias mortas"). Entre eles estavam cgi, telnetlib e chunk.

Versões antigas do httpx (como a 0.23.0) usavam cgi.parse_header() para processar cabeçalhos como Content-Disposition. No Python 3.13, esse módulo não existe mais.

Atualizando a pilha de rede#

Ajuste os arquivos de dependências para utilizar versões que não dependam mais do módulo legado:

sed -i 's/httpx==0.23.0/httpx>=0.27.0/g' requirements.txt
sed -i 's/anyio==3.6.1/anyio>=4.0.0/g' requirements.txt
pip install -r requirements.txt --break-system-packages

7. Introspecção de propriedades no pathlib quebrando o trio#

Na última etapa de execução, o motor de concorrência assíncrona Trio falhou ao inspecionar atributos do sistema de arquivos:

  File ".../trio/_path.py", line 102, in generate_forwards
    raise TypeError(attr_name, type(attr))
TypeError: ('parser', <class 'property'>)

O que causou a falha#

O Trio inspeciona dinamicamente a classe pathlib.Path para gerar proxies assíncronos de métodos de arquivo. No Python 3.13, o pathlib ganhou uma propriedade interna chamada parser. Versões antigas do Trio esperavam encontrar apenas métodos invocáveis e não tratavam propriedades puras nesse loop de introspecção.

Atualizar a biblioteca para versões compatíveis resolve o conflito:

sed -i 's/trio==0.21.0/trio>=0.27.0/g' requirements.txt
pip install -r requirements.txt --break-system-packages

Playbook consolidado para sanitizar o ambiente#

Para aplicar todas as correções de uma só vez em uma estação de trabalho:

#!/usr/bin/env bash
set -euo pipefail

echo "[*] 1. Atualizando certificados e corrigindo repositórios do sistema..."
sudo apt-get clean
sudo apt-get update
sudo apt-get install --reinstall ca-certificates -y
sudo update-ca-certificates --fresh

echo "[*] 2. Instalando pacotes pré-compilados para Python 3.13..."
sudo apt-get install python3-pil python3-levenshtein python3-dev build-essential -y

echo "[*] 3. Atualizando travas de versões antigas no requirements.txt..."
sed -i '/Pillow==/d' requirements.txt
sed -i '/levenshtein==/d' requirements.txt
sed -i 's/httpx==0.23.0/httpx>=0.27.0/g' requirements.txt
sed -i 's/anyio==3.6.1/anyio>=4.0.0/g' requirements.txt
sed -i 's/trio==0.21.0/trio>=0.27.0/g' requirements.txt

echo "[*] 4. Instalando dependências restantes no ambiente..."
pip install -r requirements.txt --break-system-packages

echo "[*] 5. Validando a importação dos módulos atualizados..."
python3 -c "import trio, httpx, PIL; print('[✔] Ambiente Python 3.13 configurado com sucesso!')"

Boas práticas para manter ferramentas antigas funcionando no Python 3.13#

Evite travas de versão excessivamente estritas: fixar dependências com == em vez de >= é a principal causa de quebra ao migrar de versão do Python. Versões antigas de bibliotecas compiladas raramente suportam mudanças de C-API do interpretador.
Dê preferência a pacotes da distribuição: bibliotecas que exigem compilação C/C++ (como Pillow, Cryptography e Levenshtein) costumam funcionar muito melhor quando instaladas via apt, pois os mantenedores da distribuição já aplicam os patches necessários para o compilador e para o Python local.
Use ambientes virtuais para isolar projetos: adotar o venv reduz drasticamente os conflitos com o PEP 668 e preserva as bibliotecas do sistema operacional intactas.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.

Migrando ferramentas para o Python 3.13 no Kali Linux: do handshake TLS às mudanças na c-API

1. Falha de certificados TLS ao clonar repositórios com Git#

O que acontece por baixo dos panos#

Rastreando chamadas de sistema com strace#

2. Quebra de escopo no build do pillow no Python 3.13#

A mudança interna no Python 3.13#

Como resolver#

3. Isolamento de pacotes do sistema operacional com PEP 668#

O propósito do PEP 668#

Três maneiras de lidar com a restrição#

4. Rejeição de assinaturas SHA-1 antigas no APT pelo sequoia PGP#

A descontinuação do SHA-1#

Como remover a origem causadora#

5. Incompatibilidade de código c++ na c-API do Python 3.13#

O que mudou na c-API#

Como contornar#

6. A remoção do módulo cgi e a modernização do httpx#

O impacto do PEP 594#

Atualizando a pilha de rede#

7. Introspecção de propriedades no pathlib quebrando o trio#

O que causou a falha#

Playbook consolidado para sanitizar o ambiente#

Boas práticas para manter ferramentas antigas funcionando no Python 3.13#

Este artigo foi útil?

Comentários

1. Falha de certificados TLS ao clonar repositórios com Git#

O que acontece por baixo dos panos#

Rastreando chamadas de sistema com strace#

2. Quebra de escopo no build do pillow no Python 3.13#

A mudança interna no Python 3.13#

Como resolver#

3. Isolamento de pacotes do sistema operacional com PEP 668#

O propósito do PEP 668#

Três maneiras de lidar com a restrição#

4. Rejeição de assinaturas SHA-1 antigas no APT pelo sequoia PGP#

A descontinuação do SHA-1#

Como remover a origem causadora#

5. Incompatibilidade de código c++ na c-API do Python 3.13#

O que mudou na c-API#

Como contornar#

6. A remoção do módulo cgi e a modernização do httpx#

O impacto do PEP 594#

Atualizando a pilha de rede#

7. Introspecção de propriedades no pathlib quebrando o trio#

O que causou a falha#

Playbook consolidado para sanitizar o ambiente#

Boas práticas para manter ferramentas antigas funcionando no Python 3.13#

Este artigo foi útil?

Veja também

Comentários