curl 8.23.0 lançado: verificar a instalação utilizada e as dependências de SMB

O curl 8.23.0 foi lançado em 14.10.2026. Ter o curl atualizado no terminal não demonstra que a biblioteca libcurl de uma aplicação empresarial também foi atualizada. Pequenas equipas de TI com scripts, contentores e aplicações de fornecedores precisam de identificar a cópia utilizada, o seu fornecedor e os critérios de aceitação funcional. Há ainda uma questão concreta: alguma tarefa depende de SMB?

O que está confirmado em 14 de outubro

A tabela de versões apresenta 8.23.0 com a data 14.10.2026, e a página de transferências disponibiliza os arquivos do código-fonte. [1][2] A indicação anterior de lançamento previsto está ultrapassada; 8.23.0-rc3 não é a versão regular. Código-fonte disponível não prova disponibilidade no canal de pacotes nem atualização de bibliotecas incorporadas. O número de versão também não basta para avaliar correções retroportadas numa distribuição. O registo de alterações indica a remoção do suporte a SMB. [3] Tarefas com smb:// ou smbs:// exigem inventário e validação funcional antes da mudança. Isto diz respeito ao curl, não automaticamente ao SMB do sistema operativo.

Pré-requisitos e limites

São necessários acesso de leitura ao inventário e às tarefas agendadas, um responsável pela aplicação e um ambiente de testes separado com dados não confidenciais. O inventário não exige instalações administrativas nem substituição de ficheiros do sistema. As atualizações posteriores devem seguir o canal suportado. Uma libcurl incluída numa aplicação não é necessariamente a biblioteca usada pela ferramenta de linha de comandos. [4] Não copie binários ou DLLs de outras origens para as pastas das aplicações.

Cinco passos para uma preparação fiável

  1. Inventarie a utilização, não apenas a versão. Registe aplicação, contexto de execução, caminho, origem do pacote, responsável e finalidade de cada tarefa importante. Separe serviços, tarefas agendadas, executores de CI e contentores. O caminho encontrado no terminal pessoal não demonstra o que um serviço executa. Para software de terceiros, peça a lista de componentes ou confirmação do fornecedor; um nome de ficheiro não basta.
  2. Identifique o executável realmente utilizado. No Windows, Get-Command curl.exe -All é uma consulta de leitura do PowerShell que ajuda a localizar executáveis; em Linux/macOS, command -v curl mostra a resolução da shell atual. Execute o binário aprovado e fidedigno pelo caminho completo com --version. curl --version apresenta informações sobre bibliotecas, protocolos e funcionalidades. [5] Registe também o backend TLS e a arquitetura. Isto não inventaria outros processos nem bibliotecas incorporadas separadamente. O resultado de command -v também pode ser uma função da shell ou um alias. Antes de consultar a versão, confirme que o caminho registado identifica o executável aprovado.
  3. Defina o canal de atualização de cada instalação. Pacotes do sistema, imagens-base de contentores, ferramentas autónomas e aplicações de fornecedores precisam de responsáveis próprios. Os distribuidores podem aplicar correções a versões anteriores; o número upstream não constitui, sozinho, prova definitiva de atualização. No dia do lançamento, compare o aviso do fornecedor, a revisão do pacote e a disponibilidade efetiva. Não substitua a libcurl de uma aplicação por iniciativa própria. Registe aprovações pendentes com responsável e data de revisão. [7]
  4. Prepare uma pequena matriz de testes funcionais. Escolha uma transferência autorizada, um caso necessário de proxy/autenticação e uma resposta de erro controlada no ambiente de testes. Defina previamente estado HTTP, conteúdo esperado e código de saída: um processo bem-sucedido não prova que os dados estejam corretos. Teste apenas os protocolos necessários, sem consultar destinos de produção arbitrários. Não coloque segredos em linhas de comandos ou registos partilhados. Compare resultados anteriores e posteriores com a mesma configuração. Novidade em 8.23.0: procure smb:// e smbs:// em scripts e configurações autorizados, sem copiar credenciais. Uma ocorrência é uma possível dependência, não prova de utilização ativa. Registe a tarefa, a cópia efetiva de curl e o responsável. Se SMB desaparecer da lista de protocolos após a mudança, trata-se de uma alteração documentada, não de um erro TLS. Acorde com o responsável pela aplicação um cliente SMB suportado ou outra via de transferência funcionalmente adequada; não troque protocolos às cegas. Para aceitar a mudança, o mesmo caso de teste autorizado deve produzir os dados e o tratamento de erros esperados pela nova via. [3]
  5. Planeie a mudança apenas após aprovação. Prepare um pacote estável suportado, cópia da configuração, janela de manutenção e procedimento de reversão verificado. Reserve versões preliminares a testes opcionais de compatibilidade isolados. Altere primeiro uma tarefa representativa; confirme caminho, biblioteca e resultado no contexto real do serviço ou contentor. Só depois da validação alargue a outros sistemas. Um contentor antigo ou processo de longa duração pode continuar a usar a versão anterior; planeie o reinício necessário.

Diagnosticar sem desativar a verificação TLS

Se a verificação de certificados falhar após a mudança, compare relógio, nome do servidor, cadeia de certificados, backend TLS e repositório de confiança. Compilações diferentes podem usar repositórios CA diferentes. Não silencie a verificação com --insecure ou -k: o curl verifica certificados por predefinição. [6] Obtenha certificados CA internos apenas por um canal empresarial autorizado. Perante autenticação ou redirecionamento inesperado, interrompa, guarde o erro sem dados sensíveis e contacte o responsável.

Validação e reversão

A mudança termina quando a tarefa em produção usa comprovadamente a instalação aprovada, passa a matriz e mantém monitorização e tratamento de erros funcionais. Registe revisão do pacote, momento da execução e aprovação. Em caso de regressão, use a reversão documentada do pacote/aplicação, sem trocar bibliotecas isoladas. Regressar a uma versão vulnerável não é solução permanente: suspenda o fluxo se necessário e acorde uma medida temporária com o responsável de segurança. Se houver alterações de dados, inclua a sua recuperação consistente no plano. Modelo de registo, não um teste realizado: «tarefa; conta de serviço/contentor; caminho completo; revisão do pacote/fornecedor; dependência de protocolo; conteúdo/código de saída esperados; resultado; aprovação; reversão». Sem opções adequadas, uma resposta de erro HTTP não gera automaticamente um código de erro do curl; verifique estado, conteúdo e código de saída separadamente. [5]

Data e fontes

Estado em 16.10.2026. Guia editorial baseado em fontes, sem teste próprio de compatibilidade ou segurança do curl. Não se afirma um aumento específico de pesquisas sobre curl 8.23.0 ou SMB; sem ligações de afiliados. Verifique separadamente o lançamento e a disponibilidade local do pacote; canais suportados e aprovação continuam necessários.