A 2026.9.0 chega a todos os produtos de uma só vez: sgcWebSockets, sgcWebSockets .NET, sgcSign, sgcIndy e sgcOpenAPI. É o maior lançamento do ano. Dois pacotes inteiramente novos se juntam ao sgcWebSockets, os mecanismos de servidor foram reformulados em torno de um problema que vinha perdendo requisições havia muito tempo, e a biblioteca de assinaturas aprendeu a verificar uma assinatura contra algo que não seja ela mesma.
Este post percorre o que importa em cada produto, com o código Delphi onde isso ajuda. Tudo está no changelog, e as partes que alteram o comportamento existente estão reunidas perto do final, para que você possa lê-las antes de atualizar.
Todo o lançamento em menos de quatro minutos. Também no YouTube.
| Produto | Novidades | Correções | Incompatíveis |
|---|---|---|---|
| sgcWebSockets | 25 | 56 | 22 |
| sgcSign | 25 | 70 | 21 |
| sgcOpenAPI | 9 | 25 | 5 |
| sgcWebSockets .NET | 5 | 24 | 10 |
| sgcIndy | 0 | 5 | 0 |
sgcWebSockets 2026.9.0
sgcWebRTC, um mecanismo de mídia WebRTC nativo
O novo pacote sgcWebRTC transforma TsgcRTCPeerConnection em um endpoint WebRTC completo. Chamadas de áudio e vídeo, compartilhamento de tela e canais de dados SCTP, tudo isso em Pascal, sem navegador, sem controle WebView e sem biblioteca de mídia externa. Funciona em Windows, Linux, macOS, iOS e Android, e o par do outro lado pode ser um navegador, porque o SDP que ele produz e consome é o real.
A troca de offer e answer segue o formato do W3C, então CreateOffer, CreateAnswer, SetLocalDescription, SetRemoteDescription e AddIceCandidate fazem o que os nomes dizem. Você transporta o SDP pelo canal de sinalização que já tiver, que pode ser um servidor WebSocket construído com a mesma biblioteca.
uses
sgcP2P;
var
oRTC: TsgcRTCPeerConnection;
begin
oRTC := TsgcRTCPeerConnection.Create(nil);
oRTC.RTCOptions.ICEServers.AddURL('stun:stun.l.google.com:19302');
oRTC.OnLocalDescription := OnLocalDescriptionHandler;
oRTC.OnICECandidate := OnICECandidateHandler;
oRTC.OnConnectionStateChange := OnConnectionStateChangeHandler;
oRTC.OnDataChannel := OnDataChannelHandler;
oRTC.CreateDataChannel('chat'); // forces RTCOptions.DTLS on
oRTC.CreateOffer; // gathers ICE candidates, builds the SDP offer
end;
procedure TForm1.OnLocalDescriptionHandler(Sender: TObject;
const aType, aSDP: string);
begin
// send aType + aSDP to the remote peer over your own signalling channel
end;
A mídia funciona da mesma forma. AddTrack anexa uma trilha de áudio Opus ou G.711, ou uma trilha de vídeo VP8, H.264 ou Motion JPEG, SendPCM e SendVideoFrame injetam a mídia capturada, e OnAudio e OnVideoFrame entregam a você a trilha remota decodificada.
Os antigos fallbacks da era do navegador seguiram o caminho contrário. O suporte ao protocolo AppRTC e à API RTCMultiConnection foi removido, assim como o fallback em Flash, que chegou ao fim da vida útil em 2020. Veja as notas de atualização no final.
sgcCrypto, criptografia sem OpenSSL
O segundo pacote novo é o sgcCrypto, uma implementação em Pascal puro das primitivas que a maioria das aplicações realmente utiliza. Criptografia autenticada AES e ChaCha20/XChaCha20-Poly1305, SHA-2 e SHA-3, Argon2, scrypt e HKDF para senhas e derivação de chaves, Ed25519, Ed448, X25519, X448 e secp256k1, geração de chaves RSA, geração de certificados X.509 e de CSR, e os algoritmos pós-quânticos ML-KEM, ML-DSA e SLH-DSA.
Cada primitiva é uma função simples. Não há objeto de contexto para criar, configurar e liberar, nem DLL para distribuir ao lado do executável.
uses
sgcCrypto_Random, sgcCrypto_AES, sgcCrypto_Keccak, sgcCrypto_Ed25519,
sgcCrypto_MLKEM;
var
vKey, vIV, vPlain, vAAD, vTag, vCipher: TBytes;
vDigest, vSeed, vSignature, vMessage: TBytes;
vPublicKey, vPrivateKey, vSharedSecret, vCiphertext: TBytes;
begin
// AES-256-GCM: authenticated encryption in one call
vKey := sgcRandomBytes(32);
vIV := sgcRandomBytes(12);
vPlain := TEncoding.UTF8.GetBytes('confidential payload');
vCipher := sgcAES_GCM_Encrypt(vKey, vIV, vPlain, vAAD, vTag);
// SHA-3-256, one call, no context object to manage
vDigest := sgcSHA3_256(vPlain);
// Ed25519: sign, then verify
vSeed := sgcRandomBytes(32);
vMessage := TEncoding.UTF8.GetBytes('sign me');
vSignature := sgcEd25519_Sign(vSeed, vMessage);
// ML-KEM-768: post-quantum key encapsulation (FIPS 203)
sgcMLKEM_GenerateKeyPair(mlkem768, vPublicKey, vPrivateKey);
sgcMLKEM_Encapsulate(mlkem768, vPublicKey, vCiphertext, vSharedSecret);
end;
Cinco aplicações sgcHTML completas
O sgcHTML ganha quatro componentes e cinco demos. Os componentes são CameraScanner, um painel de câmera ao vivo que lê códigos de barras e QR codes com o leitor embutido no navegador e sempre oferece uma alternativa de entrada manual, além de NumPad, CommandPalette e EmptyState.
As cinco demos não são trechos de código. Cada uma é uma aplicação inteira, com login, banco de dados e relatórios imprimíveis, e todas ficam em Demos\60.HTML\01.RunTime: gestão de armazém, ponto de venda, um portal de relatórios, um painel de controle SaaS multi-inquilino e despacho de serviços em campo.
Há também um novo tópico na ajuda, Runtime vs Design-Time, com demos que mostram como construir a mesma página arrastando componentes para um formulário VCL em vez de compô-la em código.
O endereço real do cliente atrás de um proxy reverso
Um servidor atrás do nginx, do Apache ou de um balanceador de carga na nuvem vê o endereço do proxy em toda conexão, o que significa que a lista negra, a lista branca, o GeoIP e suas próprias regras estavam todos olhando para o cliente errado. As novas configurações ForwardedHeaders em TsgcWebSocketFirewall recuperam o endereço encaminhado pelo proxy.
O desenho é deliberadamente desconfiado. O endereço em X-Forwarded-For ou X-Real-IP só é aceito quando a própria conexão chega de um endereço listado em TrustedProxies, de modo que um cliente não pode inventar um, e a cadeia é lida da direita, além do número de proxies indicado em TrustedHops, porque a entrada mais à esquerda é a que o cliente forneceu. A resolução é executada em cada requisição, já que um proxy reutiliza uma conexão para requisições de chamadores diferentes.
uses
sgcWebSocket;
begin
oFirewall.ForwardedHeaders.Enabled := True;
oFirewall.ForwardedHeaders.TrustedProxies.Add('10.0.0.0/8');
oFirewall.ForwardedHeaders.TrustedProxies.Add('::1');
oFirewall.ForwardedHeaders.TrustedHops := 1;
oServer.Firewall := oFirewall;
end;
procedure TForm1.OnServerConnectHandler(Connection: TsgcWSConnection);
begin
// Connection.IP is now the end client
// Connection.PeerIP is still the proxy that opened the socket
end;
Uma vez resolvido, esse endereço é o que cada entrada da lista negra, cada regra personalizada, cada evento e o seu próprio código de tratamento enxergam. As configurações se comportam da mesma maneira no servidor http.sys e no servidor Indy, e o mesmo recurso chega ao sgcSign Server como server.firewall.forwarded_headers.
Backpressure que você pode medir
Escrever para um cliente lento mais rápido do que ele lê faz a fila de saída crescer até que algo ceda. Não havia como perceber isso de dentro da aplicação, então os relays acabavam fazendo uma troca do tipo para e espera pela rede apenas para ficarem seguros.
Duas novidades substituem isso. PendingCount em TsgcWSConnection informa quantas mensagens ainda estão na fila daquela conexão nos três níveis de prioridade, e lê-lo não aloca nada, portanto pode ser consultado com frequência. OnQueueDrained dispara quando a fila de uma conexão passa de ter mensagens para estar vazia, na thread da conexão, logo após o esvaziamento e antes da próxima leitura, de modo que um crédito pode ser concedido sem nenhum atraso.
procedure TForm1.OnQueueDrainedHandler(Connection: TsgcWSConnection);
begin
// raised on the connection thread: do not touch the user interface here
SendNextBatch(Connection);
end;
procedure TForm1.SendIfRoom(Connection: TsgcWSConnection; const aText: string);
begin
if Connection.PendingCount < 100 then
Connection.WriteData(aText);
end;
Ambos atravessam a fronteira da DLL, então o wrapper .NET e qualquer outro host que consuma sgcWebSockets.dll também os recebem. As novas exportações foram acrescentadas ao final, portanto a ordem de exportação existente permanece inalterada.
Os mecanismos EPOLL e IOCP
Os mecanismos de alto desempenho tinham uma classe de defeitos com uma única causa: assumiam que uma requisição chega em uma única leitura do socket. Isso é verdade em um teste de loopback e falso em qualquer limite de MTU, sobre uma VPN, ou sempre que um corpo grande é dividido em vários pacotes.
Uma requisição que não chegava por inteiro era descartada, com a conexão fechada e sem resposta, e um registro TLS dividido em dois segmentos TCP fechava a conexão de imediato. Ambos foram corrigidos, e a nova opção PartialRequestTimeout limita quanto tempo o servidor espera pelo restante, em um pool de threads separado, para que um cliente lento não atrase os demais. No mecanismo EPOLL, as conexões do servidor também nunca eram liberadas depois que o cliente fechava, então OnDisconnect nunca disparava e cada broadcast continuava escrevendo em uma conexão morta.
É também por isso que WorkOpThreads mudou de significado. Ele não fixa mais uma conexão a uma thread, porque uma conexão à espera do restante de uma requisição atrasava todas as outras conexões daquela thread. Agora define o número mínimo de workers mantidos prontos, e o pool cresce a partir daí.
QUIC e HTTP/3
O cliente e o servidor QUIC e HTTP/3 agora falam IPv6. Um endereço com dois-pontos é tratado como IPv6, uma URL pode trazê-lo entre colchetes, e um nome de host é resolvido nas duas famílias, onde antes só o IPv4 era tentado. O listener HTTP/3 sem host definido atende as duas famílias por um único socket, e uma nova propriedade Host em HTTP3Options o fixa em uma única interface quando você precisa disso.
A mudança maior é que as requisições HTTP/3 agora seguem o mesmo caminho das requisições HTTP/1.1. Os servidores de API OpenAPI, MCP e REST, o encaminhamento de requisições, o CORS, o multi-inquilino e as métricas nunca respondiam por HTTP/3, porque aquele transporte tinha um caminho próprio. Agora todos funcionam.
A verificação de certificados em HTTP/3 é o item para ler duas vezes. TLSOptions.VerifyCertificate era True por padrão em TsgcHTTP3Client, a checagem era realizada e o resultado era depois descartado, de modo que todo cliente HTTP/3 aceitava qualquer certificado, de qualquer autoridade, emitido para qualquer host. Agora a checagem é aplicada, o que significa que um cliente HTTP/3 falando com um endpoint autoassinado deixa de conectar até que o repositório de confiança ou o certificado sejam corrigidos.
Os clientes de API das exchanges
Os clientes de exchange prontos tinham um problema de reconexão que se manifestava como um problema bem mais estranho. As assinaturas privadas, os feeds de ordens, de saldo e de execuções, nunca eram reenviadas após uma reconexão em Bitstamp, Coinbase, Deribit, Huobi, Kraken spot e futuros, Kucoin, MEXC e ThreeCommas. O componente relatava a reconexão como bem-sucedida enquanto esses feeds sumiam em silêncio. Em BitMEX, Bitfinex, Crypto.com, Deribit e Kraken futuros o reenvio ocorria antes da autenticação, o que também não pode funcionar. Os frames que carregam uma credencial de vida curta agora são reconstruídos com uma credencial nova no momento do reenvio, em vez de serem reenviados como estavam.
Os valores monetários estavam sendo arredondados antes de serem assinados. Uma máscara fixa de oito casas decimais transformava um tamanho como 0.000000004 em zero, e os valores podiam sair em notação científica ou com vírgula como separador, dependendo do locale do sistema. Agora os valores são escritos sem perda, em decimal simples, com ponto, em Binance, Bybit, Cex, Cryptohopper, Kucoin, MEXC e ThreeCommas.
Novidades na mesma área: um componente Kraken WebSocket v2 ao lado do v1, um cliente Huobi que abre uma segunda conexão internamente para que uma única instância atenda dados públicos e privados ao mesmo tempo, UseServerTimeOffset na Binance para uma máquina cujo relógio ficou fora de sincronia, e duas opções de throttle, PaceBatch e AsyncResubscribe, que evitam que uma assinatura grande esbarre no limite de taxa da exchange e movem o reenvio da reconexão para um worker em segundo plano.
sgcWebSockets .NET 2026.9.0
A biblioteca .NET acompanha a Delphi. OnQueueDrained e PendingCount chegam com o mesmo significado, junto com Throttle.AsyncResubscribe, AllowUnsignedWebhooks no cliente Cryptohopper, e um novo evento OnBinanceUserStreamSubscribed, para que a prontidão do fluxo de dados do usuário não precise mais ser descoberta consultando uma propriedade repetidamente.
Todas as correções de reconexão e de assinatura das exchanges listadas acima também se aplicam aqui, assim como as remoções. O protocolo AppRTC, a API RTCMultiConnection e as classes de fallback em Flash foram removidos, o que renumera TwsTransport. O código que persistia ou transmitia o valor numérico do transporte precisa ser revisto.
Dois vazamentos que merecem menção: um componente de API WebSocket liberado enquanto seu cliente ainda estava conectado nunca se removia da lista que o manipulador de mensagens percorre, e duas threads de timer de heartbeat vazavam a cada componente destruído, e é por isso que um encerramento limpo às vezes falhava.
sgcSign 2026.9.0
A maior parte deste lançamento nasceu de pedidos de clientes, e ela se concentra em três áreas: saber com qual certificado você está prestes a assinar, construir uma assinatura que um validador ainda aceitará daqui a dez anos, e verificar uma assinatura contra algo que não seja ela mesma.
Listas de certificados em que dá para escolher
A enumeração de certificados costumava devolver nomes de exibição, o que basta para preencher uma caixa de seleção e não basta para tomar uma decisão. Dois cartões da mesma autoridade, emitidos para a mesma pessoa, parecem idênticos nessa lista. A enumeração agora traz a impressão digital SHA-1, o identificador fiscal, o número de série, o emissor e as datas de validade, da mesma forma para o repositório de certificados do Windows, um token PKCS#11 e um arquivo PFX.
uses
sgcSign_KeyProvider_WinCertStore, sgcSign_X509, sgcSign_Types;
var
oProvider: TsgcWindowsCertStoreProvider;
oList: TsgcX509CertificateList;
i: Integer;
begin
oProvider := TsgcWindowsCertStoreProvider.Create(nil);
Try
// only certificates that are still valid and hold a private key
oList := oProvider.EnumerateCertificateList([cfNotExpired, cfPrivateKey]);
Try
for i := 0 to oList.Count - 1 do
Memo1.Lines.Add(Format('%s | %s | %s .. %s | %s',
[oList[i].Subject, oList[i].SerialNumber,
DateToStr(oList[i].NotBefore), DateToStr(oList[i].NotAfter),
oList[i].Thumbprint]));
// and sign with exactly the one that was chosen
oProvider.SelectCertificateByThumbprint(oList[0].Thumbprint);
Finally
oList.Free;
End;
Finally
oProvider.Free;
End;
end;
Um cartão PKCS#11 de múltiplos slots, comum nos cartões poloneses de assinatura qualificada que colocam certificados distintos atrás de PINs distintos, agora pode ser inventariado sem nenhum PIN. EnumerateCertificateListAllSlots lê todos os slots, e cada entrada registra de onde veio, e TokenSlotCount informa quantos slots realmente contêm um token.
Os próprios certificados também informam tudo o que carregam, em vez dos sete atributos que o parser reconhecia, com o endereço postal decodificado em linhas legíveis, e qualquer atributo acessível pelo seu OID.
Assinaturas que continuam verificáveis
PAdES ganha dois perfis. spPAdESBasicT assina com um carimbo de tempo embutido e sem dados de revogação, e spPAdESDocumentArchive acrescenta um carimbo de tempo de arquivamento sobre o perfil de longo prazo, cobrindo o documento inteiro, inclusive seus dados de revogação, de modo que o arquivo continua verificável depois que a janela de validade do primeiro carimbo tiver passado.
Encontrar o certificado emissor costumava ser problema seu, porque a maioria dos cartões de assinatura qualificada carrega apenas o seu próprio certificado. As novas chamadas GetIssuerCertificate e GetCertificateChain encontram o certificado que emitiu aquele com o qual você está assinando, e todo o caminho acima dele, comparando criptograficamente em vez de por nome, de modo que uma autoridade que trocou sua chave de assinatura não é confundida com sua antecessora. IssuerLookup decide onde procurar: no repositório de certificados do Windows por padrão, em arquivos PEM ou DER que você distribui, ou no endereço dentro do certificado, que vem desativado por padrão.
As requisições de carimbo de tempo agora podem ser assinadas, o que algumas autoridades qualificadas exigem, as polonesas em particular. Defina RequestFormat como trfCMS, atribua um provedor de chaves, e OnBeforeSendRequest e OnAfterReceiveResponse entregam a você exatamente os bytes enviados e recebidos.
Verificação com âncoras de confiança
Esta é a mudança para ler com atenção. Até agora o verificador retirava o certificado de assinatura do próprio documento que estava checando e confirmava que aquela chave havia assinado aquele documento, o que prova apenas que quem escreveu o documento também escreveu a assinatura nele.
As novas propriedades TrustedCertificates e TrustedCertificateStore dizem em quais raízes você confia, e RequireTrustedChain, CheckKeyUsage e RequireCompleteRevocationCheck decidem quão rigoroso é o resultado. Uma âncora é identificada pela impressão digital SHA-256 ou pela verificação sob a própria chave dela, nunca pelo nome. Um verificador sem âncora devolve o mesmo veredito de antes, mas o relatório ETSI TS 119 102-2 já não diz total-passed para uma assinatura que nunca foi encadeada até uma âncora, portanto os relatórios armazenados que foram produzidos sem âncora precisam ser gerados de novo.
A assinatura Authenticode agora pode embutir certificados extras, o mesmo que signtool /ac faz, de forma que a assinatura de um driver em modo kernel possa encadear até a Microsoft Code Verification Root através do seu certificado cruzado.
Um único transporte HTTP, com proxies
Toda requisição que a biblioteca faz agora passa por um único transporte com uma propriedade HTTPOptions compartilhada: o cliente de carimbo de tempo, os clientes de OCSP e de listas de revogação, o download da lista de confiança da UE e os provedores de chaves em nuvem. Ele carrega o proxy, que pode ser o do sistema, nenhum, um endereço explícito ou aquele que a máquina resolve por endereço, as credenciais para um proxy que as solicite, o certificado de cliente, a versão mínima de TLS aceita e o user agent. Cada configuração tem como padrão o que aquelas requisições faziam antes, e um novo evento OnHTTPRequest substitui o transporte por completo, para um gateway que essas configurações não conseguem descrever.
O servidor de assinatura
As chaves de API e os usuários que as criam agora estão isolados por projeto, então um administrador de projeto gerencia as chaves do seu próprio projeto sem ver as dos outros. As chaves podem ser ativadas e desativadas, em vez de apenas revogadas de forma definitiva, seu limite de taxa e sua cota diária podem ser editados depois da criação, e o log de auditoria finalmente pode ser filtrado por endereço do cliente, tanto no console quanto na exportação CSV.
Uma assinatura Authenticode agora pode levar mais de duas assinaturas aninhadas, com um certificado diferente para cada uma, que é o que se precisa para distribuir um único arquivo assinado por um certificado prestes a expirar e por seu substituto. Arquivos de catálogo do Windows podem ser assinados, e um novo endpoint /api/v1/sign/raw assina um digest que você já calculou e devolve apenas o valor da assinatura, que é exatamente o que signtool pede através do seu callback /dlib. Como ele assina qualquer digest que lhe for entregue, vem desativado por padrão e é habilitado um provedor de cada vez.
Vários padrões do servidor mudaram por boas razões. A configuração server.listen agora realmente vincula o endereço que você indicou, as ações de administração exigem um envio de formulário com um token de uso único, e as entregas de webhook por HTTPS verificam o certificado do endereço para o qual são enviadas. As três estão nas notas de atualização.
sgcIndy 2026.9.0
Um lançamento pequeno, e cada item dele é uma correção que vale a pena ter.
O nome de protocolo acordado por ALPN era escrito com quatro bytes no único byte que o OpenSSL reserva para o comprimento dele, então todo handshake que negociava um protocolo sobrescrevia a memória ao lado. Um servidor TLS nos mecanismos IOCP ou EPOLL consumia toda a CPU de uma thread quando o outro lado pedia renegociação, repetindo a escrita sem parar em vez de enviar o que o OpenSSL já havia preparado. No Linux, uma aplicação TLS era encerrada pelo sistema operacional quando o outro lado reiniciava a conexão durante uma escrita, porque o OpenSSL escreve de um modo que não permite pedir ao sistema que suprima o sinal de broken pipe. O mesmo problema sob FPC e Lazarus também foi corrigido, inclusive nas conexões aceitas pelo servidor no macOS, que ainda estavam expostas.
No instalador Community, os binários pré-compilados do Delphi 13 eram produzidos a partir dos projetos do Delphi 12, então traziam os nomes 290 em vez dos nomes 370 que o instalador do Delphi 13 espera, e o Windows ARM64EC não era compilado. Agora o Delphi 13 compila seus próprios projetos para todas as plataformas suportadas.
sgcOpenAPI 2026.9.0
O parser deixou de falhar em silêncio. Todo documento agora volta com uma lista Warnings que registra um membro openapi ou info ausente, um membro com o tipo JSON errado, uma operação que não pôde ser gerada, uma referência de path item não resolvida e qualquer palavra-chave do JSON Schema que seja lida mas ainda não respeitada.
uses
sgcOpenAPI_Classes, sgcOpenAPI_Parser_Client_Pascal;
var
oParser: TsgcOpenAPI_Parser_Client_Pascal;
i: Integer;
begin
oParser := TsgcOpenAPI_Parser_Client_Pascal.Create;
Try
oParser.OpenAPIClassName := 'TPetStoreClient';
oParser.OutputFileName := 'PetStoreClient.pas';
oParser.ReadFromFile('petstore.json');
for i := 0 to oParser.Warnings.Count - 1 do
Memo1.Lines.Add('warning: ' + oParser.Warnings[i]);
oParser.SaveToFile('PetStoreClient.pas');
Finally
oParser.Free;
End;
end;
Ele também sabe qual versão da especificação está lendo, então um documento 3.0 e um documento 3.1 já não são tratados como a mesma coisa, sendo exclusiveMinimum e exclusiveMaximum o caso mais evidente. Os webhooks do OpenAPI 3.1, jsonSchemaDialect, components.pathItems, o identificador de licença, o esquema de segurança mutualTLS, um tipo declarado como array, tal como ["string","null"], e um schema declarado como booleano são todos suportados, assim como a operação query do OpenAPI 3.2 e o mapa additionalOperations.
A geração melhorou justamente onde costumava desistir. Um schema de objeto inline agora gera sua própria classe em vez de degradar para uma string, items é lido como um schema completo, e o cliente gerado suporta parâmetros de cookie e todas as regras de serialização de parâmetros: matrix, label, simple, form, spaceDelimited, pipeDelimited e deepObject, com explode e allowReserved.
A linha de comando finalmente é utilizável em um script de build. Ela define um código de saída, 0 em caso de sucesso e de 1 a 7 para as diferentes falhas, e os erros vão sempre para a saída de erro padrão. Um novo parâmetro -r converte um documento YAML ou Swagger 2.0 através do conversor público, desativado por padrão.
As mesmas melhorias de OpenAPI vão dentro do sgcWebSockets, onde o validador do lado do servidor agora também verifica parâmetros de cabeçalho e de cookie, com ValidateHeaderParams, ValidateCookieParams e EnforceRequired.
Antes de atualizar
Todos os produtos têm mudanças incompatíveis desta vez. Estas são as que têm maior chance de afetar você.
- Removidos do sgcWebSockets e do .NET. AppRTC, RTCMultiConnection e o fallback em Flash foram removidos. Retire as linhas
FallBack.Flashde qualquer.dfmque as contenha, caso contrário o formulário gera um erro de propriedade inexistente, e observe que o ordinal de todo membro deTwsTransportposterior atrpFlashmudou em uma unidade. WorkOpRoundRobinfoi removido eWorkOpThreadsnão fixa mais uma conexão a uma thread. Nada que seja mantido por thread, como uma conexão de banco de dados ou um cache local da thread, pode continuar sendo tratado como se acompanhasse uma conexão.- A verificação de certificados agora é aplicada onde não era. No backend OpenSSL,
TLSOptions.VerifyCertificatevincula o certificado ao host, como SChannel e Apple já faziam. Em HTTP/3 o resultado da checagem não é mais descartado.DTLSOptions.VerifyCertificateagora aplica o seu resultado, eDTLSOptions.RootCertFileé o repositório de confiança, e não o certificado do próprio endpoint, que pertence aCertFile. WriteTimeoutnos clientes passa a ter 60 segundos como padrão em vez de nenhum limite, e agora também vale em Linux, macOS, iOS e Android, onde antes só tinha efeito no Windows. Defina um valor negativo para nunca expirar.- As retentativas são mais restritas. Por padrão, apenas GET, HEAD e OPTIONS são repetidos, porque um POST que o servidor já tinha executado podia ser enviado duas vezes e criar uma segunda ordem. Adicione POST a
RetryOptions.Methodsse você dependia do comportamento anterior. - O sgcSign tem uma única
TsgcX509Certificate. A biblioteca declarava três classes com esse nome. O código que lista certificados precisa desgcSign_X509na sua cláusula uses, e do.hppcorrespondente no C++ Builder. - Os contêineres ASiC-E CAdES criados por versões anteriores não têm vínculo criptográfico com os documentos que estão dentro deles, porque cada digest do manifesto era escrito como um elemento vazio. Os contêineres já emitidos devem ser emitidos de novo, e quem produz ASiC-E precisa migrar para a nova sobrecarga de
BuildCAdESque recebe um callback de assinatura. - As credenciais digitadas no Object Inspector não são mais gravadas no
.dfm. Quatorze propriedades em onze units do sgcSign, entre elas a chave secreta da AWS, o JSON da conta de serviço do Google Cloud e o PIN do PKCS#11, agora estão marcadas como não armazenadas. Elas continuam atribuíveis por código, e um.dfmexistente ainda é carregado, mas o valor desaparecerá na próxima vez que o formulário for salvo. - O sgcSign Server agora vincula
server.listende verdade. Uma implantação configurada para 127.0.0.1 que na prática estava acessível a toda a rede passa a ficar inacessível, que é o que a configuração pedia. - Os clientes OpenAPI gerados verificam o certificado do servidor. Defina
TLSOptions.VerifyCertificatecomo False para um endpoint autoassinado. O corpo da requisição agora é UTF-8, uma string vazia é serializada como"field": "", e uma resposta não libera mais umResponseStreamfornecido pelo chamador.
A lista completa, com o motivo de cada item, está no changelog de cada produto.
Como obter
O lançamento 2026.9.0 já está disponível, com código-fonte completo e um ano de atualizações, para Delphi 7 até Delphi 13 Florence, as versões correspondentes do C++ Builder, e .NET.
sgcWebSockets · sgcWebRTC · sgcCrypto · sgcHTML · sgcSign · sgcIndy · sgcOpenAPI
Baixar a versão de avaliação · Changelog
Dúvidas ou comentários? Entre em contato, você receberá uma resposta das pessoas que escreveram o código.
