Plano de código aberto do SingLinkVPN

Contents
O código aberto é o começo da confiança de longo prazo.
O SingLinkVPN lançou oficialmente o seu programa de código aberto e pesquisa técnica e criou no GitHub o repositório oficial SingLinkVPN Open Source and Technical Research (código aberto e pesquisa técnica do SingLinkVPN).
Não se trata de uma publicação pontual nem de uma página de documentos feita só para leitura. É um esforço de engenharia de longo prazo, que será atualizado continuamente e ampliado com o tempo.
O material disponível hoje é a primeira fase de um programa mais amplo.
A primeira fase abrange documentação técnica pública, modelos de segurança e privacidade, métodos reproduzíveis de teste de desempenho, formatos de dados legíveis por máquina, uma estrutura para conjuntos de dados públicos, diretórios de relatórios, ferramentas de pesquisa, um processo de divulgação de segurança e padrões de publicação de evidências.
Nas fases seguintes, o SingLinkVPN pretende publicar em etapas mais material técnico, relatórios de pesquisa e o código-fonte dos produtos, sempre após revisão de segurança, privacidade, licenciamento e estabilidade do produto. As áreas previstas incluem o protocolo VPN, os clientes VPN e outras tecnologias centrais de VPN que, após revisão, possam ser publicadas.
A publicação atual, portanto, não é o fim do programa. É o primeiro passo de um processo contínuo de abertura do código.
O repositório oficial já contém os diretórios docs, data, reports, tools, tests e de automação do GitHub, usados para manter a documentação pública, os dados de pesquisa, o material de segurança, os testes de desempenho e as ferramentas abertas de validação. O repositório é descrito explicitamente como um projeto mantido ativamente.
Repositório oficial: SingLinkLabs / singlink-vpn-open-source Situação atual: a primeira fase é pública. Mais material técnico, relatórios de pesquisa e o código-fonte dos produtos serão publicados em etapas.
Por que o SingLinkVPN está lançando um programa de código aberto?
Uma VPN está intimamente ligada a transporte de rede, segurança, privacidade e processamento de dados.
A maior parte de um serviço de VPN funciona dentro de sistemas que o usuário não consegue observar diretamente. O usuário vê a interface do app, a lista de servidores, a velocidade de conexão e a descrição do produto, mas não consegue confirmar com facilidade:
- como os resultados de velocidade publicados foram medidos;
- qual versão do software e qual ambiente de rede foram usados;
- se os testes que falharam foram registrados por completo;
- se uma declaração de segurança é um compromisso de política, um teste interno ou uma avaliação independente;
- se um relatório inclui datas, versões, métodos e histórico de correções;
- se outro pesquisador consegue reproduzir o resultado;
- se as mudanças técnicas e de segurança podem ser acompanhadas de uma versão para outra.
Declarações de marca, sozinhas, não respondem totalmente a essas perguntas.
O programa pretende transformar as informações técnicas, de segurança, de privacidade e de desempenho do SingLinkVPN, hoje afirmações de produto, em material público que outras pessoas possam inspecionar, citar, verificar, reproduzir e continuar examinando.
Isso exige um sistema de publicação contínuo, e não apenas colocar arquivos na internet:
- materiais técnicos importantes precisam ter uma versão definida;
- afirmações mensuráveis precisam indicar a data e o ambiente do teste;
- resultados de desempenho precisam ser sustentados pelos dados correspondentes;
- testes internos e avaliações de terceiros precisam ser claramente diferenciados;
- correções relevantes precisam deixar um registro público;
- o código-fonte dos produtos precisa ser publicado em fases, após revisão de segurança;
- a comunidade precisa conseguir verificar a estrutura e a integridade dos dados com ferramentas públicas.
O repositório exige que cada afirmação mensurável inclua a data do teste, a versão do software, o ambiente, o método, o tamanho da amostra, os dados brutos ou agregados e as limitações conhecidas. Superlativos impossíveis de verificar, como “o mais rápido”, “o mais seguro” ou promessas de privacidade absoluta, não são tratados como evidência.
O que está disponível na primeira fase?
A primeira fase estabelece oito frentes de trabalho públicas:
- a arquitetura de desenvolvimento da VPN e a documentação técnica pública;
- os registros de produtos e versões do SingLinkVPN;
- um modelo de segurança e privacidade;
- métodos reproduzíveis de teste de desempenho;
- formatos de dados de teste e uma estrutura para conjuntos de dados públicos;
- diretórios de relatórios de segurança, desempenho e transparência;
- ferramentas abertas de validação de dados e de pesquisa;
- relato de vulnerabilidades e divulgação responsável.
Juntas, elas formam a base necessária para a publicação futura do código-fonte, de dados públicos e de pesquisas independentes.
1. Arquitetura pública de desenvolvimento da VPN e documentação técnica
A primeira fase inclui uma arquitetura de cliente VPN multiplataforma.
Ela não está presa a uma linguagem de programação ou a um sistema operacional. Em vez disso, descreve os principais módulos de que um cliente VPN multiplataforma precisa, incluindo a interface, o ciclo de vida da conexão, o gerenciamento do túnel, o roteamento, o DNS, a configuração, os testes de segurança e o diagnóstico local.
1. Camada de interface
A camada de interface apresenta o status da conta, a escolha de servidor, o estado da conexão, os erros, os resultados de diagnóstico e os recursos de acessibilidade.
O estado da conexão exibido na interface precisa vir da máquina de estados real da conexão, e não apenas do fato de o usuário ter apertado o botão de conectar.
2. Camada de orquestração de sessões
Esta camada cuida de:
- conexão;
- desconexão;
- novas tentativas automáticas;
- mudanças de rede;
- suspensão e retomada do dispositivo;
- reinício do aplicativo;
- recuperação após uma interrupção anormal.
Ela precisa impedir que resultados de conexões antigas sobrescrevam operações mais recentes e garantir que ações repetidas não gerem conflitos.
3. Camada de adaptação do túnel
Esta camada se integra às APIs nativas de VPN dos diferentes sistemas operacionais, incluindo:
- entrada e saída de pacotes;
- o ciclo de vida do túnel;
- a configuração de MTU;
- as permissões do sistema operacional;
- as restrições de execução em segundo plano;
- os callbacks de interrupção do túnel.
4. Camada de roteamento e DNS
Esta camada gerencia:
- rotas padrão;
- split tunneling (tunelamento dividido);
- rotas excluídas;
- escolha de DNS;
- política para IPv4 e IPv6;
- acesso à rede local;
- proteção contra vazamentos de DNS e de rotas.
Os testes de vazamento não podem se limitar à conexão inicial. Eles também precisam cobrir a reconexão, as mudanças de rede, a suspensão e a retomada e o encerramento anormal do aplicativo.
5. Camada de transporte
A camada de transporte responde pelas sessões autenticadas, pelo comportamento do transporte, pelo tratamento de congestionamento, pela política de keepalive e pela migração entre redes.
6. Camada de configuração
A camada de configuração processa configurações remotas versionadas, assinadas e reduzidas ao mínimo, e rejeita configurações inválidas, expiradas ou rebaixadas para versões anteriores.
7. Camada de observabilidade
Respeitando as proteções de privacidade, esta camada oferece:
- o estado de saúde local;
- diagnósticos de conexão;
- classificação de erros;
- saídas de teste reproduzíveis;
- dados de status técnico que não contêm a atividade de rede do usuário.
A publicação atual cobre a arquitetura de alto nível e os princípios de desenvolvimento seguro. Módulos mais específicos e o código-fonte só serão acrescentados depois que as revisões correspondentes forem concluídas.
2. Um registro público e versionado do produto
O SingLinkVPN também criou um registro público do produto que separa os diferentes tipos de informação.
Fatos do produto
Incluem:
- as plataformas suportadas;
- as versões públicas;
- as datas de lançamento;
- as fontes oficiais de download;
- os checksums disponíveis;
- mudanças relevantes de recursos e de compatibilidade.
Descrições de arquitetura
Apresentam projetos de alto nível sem expor sistemas sensíveis, credenciais ou ambientes de produção.
Resultados de medições
Os resultados de desempenho e as conclusões técnicas precisam incluir data, método, ambiente, amostra e dados de suporte.
Declarações de política
Cobrem as operações do produto e os compromissos de segurança e privacidade. Uma declaração de política não é apresentada como verificação independente.
Essa separação ajuda a evitar que política, testes internos, detalhes de implementação e pesquisa independente sejam confundidos. Os registros formais de lançamento passarão a incluir, aos poucos, plataforma, versão, data, fonte, checksums disponíveis, mudanças relevantes de segurança e compatibilidade, limitações conhecidas e tags Git imutáveis ou links de Release.
3. Um modelo público de segurança e privacidade
A segurança não pode ser descrita apenas com palavras como “seguro” ou “criptografado”.
Por isso, a primeira fase publica um modelo de segurança e privacidade que define os riscos que os testes, relatórios e avaliações independentes futuros devem examinar.
O escopo atual de ameaças inclui:
- observação do tráfego na rede local;
- vazamentos de DNS;
- vazamentos de IPv6;
- vazamentos de WebRTC;
- interrupção das rotas durante a reconexão;
- proteção do tráfego ao alternar entre Wi-Fi e rede móvel;
- alterações maliciosas na configuração remota;
- rebaixamento (downgrade) da configuração;
- exposição de credenciais armazenadas no dispositivo;
- riscos de dependências de terceiros;
- riscos na cadeia de suprimentos de build e de publicação;
- abuso de contas;
- sessões não autorizadas;
- coleta excessiva de dados de diagnóstico ou de suporte.
Todo teste de segurança público precisa identificar:
- a versão do cliente afetada;
- o sistema operacional;
- a data do teste;
- as condições de rede;
- o método;
- o comportamento esperado;
- o comportamento observado;
- as limitações conhecidas.
O modelo também separa política, documentação de arquitetura, testes internos e avaliação de terceiros.
Só um relatório de um avaliador ou pesquisador independente identificado, apoiado em um relatório verificável, pode ser rotulado como avaliação de terceiros. Isso cria um padrão consistente e auditável para os relatórios de segurança futuros.
4. Um método reproduzível de teste de desempenho de VPN
O desempenho de uma VPN é afetado por muitos fatores externos:
- o país ou a região de quem testa;
- o provedor de banda larga ou de rede móvel;
- a qualidade da rede local;
- o trânsito internacional;
- o horário do dia;
- o desempenho do dispositivo;
- a versão do cliente;
- o protocolo;
- a carga do servidor;
- o servidor de teste;
- a região de destino.
Por isso, uma única velocidade de pico não representa a experiência de todos os usuários.
O método publicado exige que cada registro inclua:
- o horário do teste em UTC;
- um identificador único do teste;
- a versão do cliente;
- o sistema operacional;
- o tipo de dispositivo;
- o rótulo do protocolo;
- a versão da metodologia;
- o país ou a região do teste;
- o tipo de rede;
- a quantidade de amostras;
- o nível de evidência.
As principais métricas são:
Latência mediana de conexão
A latência mediana, em milissegundos, de várias amostras, e não um único melhor resultado.
Jitter no percentil 95
O nível mais alto de variação de latência observado na maioria das amostras.
Taxa de perda de pacotes
A proporção de pacotes perdidos durante o teste.
Velocidade mediana de download
A taxa de download mediana, em Mbps, de várias amostras.
Velocidade mediana de upload
A taxa de upload mediana, em Mbps, de várias amostras.
Taxa de sucesso de conexão
A porcentagem de tentativas bem-sucedidas em testes de conexão repetidos.
Tempo mediano de reconexão
O tempo mediano necessário para se recuperar após uma mudança de rede ou uma interrupção.
O fluxo de trabalho formal é:
- registrar a rede de referência sem a VPN;
- manter constantes o dispositivo, a rede, o destino e a janela de amostragem;
- fazer um aquecimento que não entra na contagem;
- repetir os testes de conexão e de transferência;
- manter as amostras que falharam, em vez de apagá-las silenciosamente;
- publicar os resultados agregados e os dados legíveis por máquina;
- divulgar as limitações conhecidas, as interrupções e as amostras excluídas.
Testes comparativos precisam usar condições comparáveis. Qualquer mudança de provedor, rota, dispositivo, servidor de teste ou janela de amostragem precisa ser informada. Conjuntos de dados datados, versionados e disponíveis para download serão acrescentados a este método conforme os testes avançarem.
5. Um formato público de dados de teste legível por máquina
Além dos relatórios legíveis por pessoas, o SingLinkVPN publica um formato de dados de desempenho legível por máquina.
O JSON Schema exige que cada registro de desempenho inclua:
- test_id: identificador do teste;
- tested_at_utc: horário do teste em UTC;
- client_version: versão do cliente;
- platform: plataforma do teste;
- protocol_label: rótulo do protocolo;
- country: país ou região do teste;
- network_type: tipo de rede;
- sample_count: quantidade de amostras;
- latency_ms_median: latência mediana;
- jitter_ms_p95: jitter no percentil 95;
- packet_loss_pct: taxa de perda de pacotes;
- download_mbps_median: velocidade mediana de download;
- upload_mbps_median: velocidade mediana de upload;
- connection_success_pct: taxa de sucesso de conexão;
- reconnect_ms_median: tempo mediano de reconexão;
- methodology_version: versão do método;
- evidence_level: nível de evidência.
Atualmente, a evidência pode ser marcada como:
- teste interno;
- reprodução independente;
- avaliação de terceiros.
O formato permite que desenvolvedores e pesquisadores inspecionem diretamente os campos obrigatórios e os intervalos de valores e usem a mesma estrutura para reproduzir e comparar resultados, em vez de depender apenas de gráficos ou de conclusões descritivas.
6. Relatórios de segurança, desempenho e transparência
O repositório tem um diretório de relatórios dedicado à publicação contínua de:
- relatórios de segurança;
- relatórios de desempenho;
- pesquisas de privacidade;
- relatórios de transparência;
- avaliações de terceiros;
- resultados reproduzidos de forma independente;
- avisos sobre correções de segurança relevantes.
Antes da publicação, cada relatório formal precisa informar:
- a data de publicação;
- o autor ou responsável pela manutenção;
- a versão do produto afetada;
- o método;
- a fonte dos dados;
- o nível de evidência;
- as limitações conhecidas;
- o histórico de correções.
Testes internos e avaliações independentes recebem rótulos diferentes. A primeira fase estabelece a estrutura dos relatórios, as regras de evidência e o sistema de versionamento; os relatórios serão acrescentados à medida que os dados e a revisão ficarem prontos, em vez de serem publicados uma vez e abandonados.
7. Ferramentas abertas de validação e pesquisa
A primeira fase também publica várias ferramentas de pesquisa e validação em Python.
publication_guard.py
Verifica documentos, dados e ferramentas antes da publicação em busca de:
- credenciais;
- formatos de chaves;
- caminhos privados;
- arquivos compactados;
- arquivos binários;
- tipos de código-fonte não aprovados para publicação;
- arquivos grandes demais;
- formatos comuns de segredos ativos;
- conteúdo que possa descrever sistemas sensíveis.
validate_benchmark.py
Valida os arquivos CSV dos testes de desempenho, incluindo:
- nomes das colunas;
- campos obrigatórios;
- intervalos numéricos;
- rótulos de evidência;
- estrutura dos dados de teste.
check_relative_links.py
Verifica os links relativos em Markdown e confirma que os arquivos públicos referenciados existem.
check_multilingual_seo.py
Verifica os documentos multilíngues e a estrutura relacionada a buscadores, ajudando a manter alinhados os materiais em inglês, chinês simplificado e chinês tradicional.
Essas ferramentas não são o núcleo de conexão da VPN. São infraestrutura de publicação, criadas para reduzir erros de formatação, links quebrados, exposição acidental de informações sensíveis e inconsistências de versão. Colaboradores externos podem usar as mesmas ferramentas nas suas contribuições.
8. Um padrão público de evidências em cinco níveis
Nível um: declaração de política
Um compromisso de produto, segurança, operação ou privacidade publicado pelo mantenedor. É um compromisso público, não uma prova de implementação nem uma auditoria independente.
Nível dois: documentação de implementação
Uma descrição técnica de alto nível e versionada, que não contém endereços de servidor, credenciais, APIs privadas nem outras informações sensíveis.
Nível três: teste interno
Um teste realizado pela SingLinkLabs com um método público, com data, versão, ambiente e dados.
Nível quatro: resultado reproduzido
Um resultado independente obtido por outro desenvolvedor ou pesquisador usando o mesmo método e os dados públicos.
Nível cinco: avaliação de terceiros
Uma avaliação feita por um pesquisador ou uma organização independente identificada, com um relatório formal verificável.
Esses níveis não são intercambiáveis. Testes internos não podem ser rotulados como avaliação de terceiros; uma política não pode ser tratada como verificação independente; e publicar um método não significa que um resultado já tenha sido reproduzido.
Cada relatório deve responder: quem chegou à conclusão, quando, com qual versão e por qual método?
Correções relevantes exigem um novo commit no Git e uma entrada no changelog. Dados publicados não podem ser substituídos silenciosamente, e os dados substituídos devem continuar identificáveis.
9. Relato de vulnerabilidades e divulgação responsável
A publicação aberta e a divulgação segura precisam funcionar juntas.
Vulnerabilidades sem correção, credenciais ativas, endpoints privados, endereços de servidor e dados de usuários não podem ser publicados em uma Issue pública.
Os relatos de vulnerabilidades devem ser enviados de forma privada pelo endereço de e-mail de segurança ou pelos GitHub Security Advisories e identificados claramente como divulgações de segurança. Se nenhum e-mail de segurança tiver sido publicado, consulte o `SECURITY.md` do repositório e não tente adivinhar um endereço.
Um relato deve incluir:
- a versão afetada;
- a plataforma afetada;
- as condições para reproduzir o problema;
- o impacto na segurança;
- uma forma segura de entrar em contato com quem relatou;
- material de reprodução sem nenhum dado real de usuários.
Os relatos de segurança passam por:
- triagem e confirmação;
- avaliação de impacto;
- correção;
- publicação de uma versão corrigida;
- um prazo razoável para atualização;
- publicação de um aviso de segurança.
Os avisos públicos diferenciam o impacto confirmado do risco hipotético e identificam as versões afetadas e as corrigidas.
10. Dados públicos não significam dados de usuários públicos
A transparência técnica não pode custar a privacidade dos usuários.
O repositório proíbe que Issues, pull requests, conjuntos de dados ou documentos de pesquisa contenham:
- dados pessoais;
- identificadores de conta;
- dados de pagamento;
- conversas de suporte;
- endereços IP privados;
- tokens de acesso;
- credenciais de produção;
- logs de produção;
- tráfego bruto de produção;
- dados de teste capazes de identificar um usuário individual.
Os dados de desempenho precisam ser agregados ou desidentificados. Antes da publicação, os revisores precisam confirmar que o conjunto de dados não contém dados no nível do usuário, credenciais nem material capaz de identificar um usuário real.
O programa torna transparentes a tecnologia, os métodos, os relatórios e o código-fonte revisado. Ele não publica informações de usuários, dados de servidores sensíveis para a segurança nem credenciais de produção.
11. Como a comunidade pode participar?
Desenvolvedores, pesquisadores de segurança e membros da comunidade podem:
- melhorar a documentação técnica;
- corrigir erros na documentação;
- melhorar as traduções em chinês tradicional, chinês simplificado e inglês;
- melhorar a reprodutibilidade do método de teste;
- melhorar a qualidade dos dados públicos;
- melhorar a acessibilidade;
- acrescentar ferramentas de pesquisa;
- aprimorar a validação de formatos;
- encontrar links quebrados;
- propor novos métodos de pesquisa pública;
- sugerir melhorias no desenho dos testes;
- reproduzir testes públicos dentro das regras de segurança.
As contribuições não podem conter:
- código-fonte de produto não aprovado;
- informações de infraestrutura privada;
- credenciais ou chaves;
- dados de usuários;
- endpoints privados;
- logs de produção;
- instruções completas de exploração de uma vulnerabilidade sem correção.
Toda contribuição mensurável também precisa identificar a fonte, o método, a data e as limitações.
Isso significa que o SingLinkVPN agora é totalmente de código aberto?
Não. Esta é a primeira fase, não a fase final.
A primeira fase prioriza:
- a documentação técnica;
- a arquitetura de desenvolvimento;
- os modelos de segurança e privacidade;
- os métodos de teste de desempenho;
- os formatos de dados legíveis por máquina;
- as ferramentas de validação;
- a política de evidências e de publicação;
- a divulgação responsável;
- uma estrutura para relatórios e publicações de código-fonte futuras.
Não fazem parte da primeira fase:
- o código-fonte completo do cliente VPN;
- o código-fonte do lado do servidor;
- o código-fonte do sistema de pagamentos;
- a configuração dos servidores de produção;
- APIs privadas;
- credenciais de autenticação;
- detalhes sensíveis de implementação antibloqueio ou de confronto com redes hostis;
- o código-fonte completo do protocolo central.
Isso não quer dizer que eles estejam excluídos do programa como um todo. Cada módulo do produto precisa de revisões próprias de segurança, privacidade, dependências e licenciamento.
Concluída a revisão, as publicações seguintes incluirão:
- um diretório de código aberto claramente definido;
- a licença correspondente;
- o histórico de versões;
- os limites de segurança;
- um changelog;
- a data de publicação;
- uma tag Git ou uma Release verificável.
Construir primeiro os padrões de publicação, as estruturas de dados, as regras de segurança e as ferramentas de pesquisa cria uma base mais segura e reduz o risco de expor credenciais, infraestrutura, dados de usuários ou código de terceiros que não pode ser redistribuído legalmente.
As licenças serão definidas conforme novos materiais forem publicados
O repositório atual pode ser consultado publicamente, mas as licenças completas de reutilização do código e do conteúdo ainda estão sendo organizadas por tipo de material e de código-fonte.
Até que uma licença explícita seja publicada, ninguém deve presumir que recebeu:
- o direito de copiar;
- o direito de modificar;
- o direito de redistribuir;
- o direito de uso comercial;
- o direito de relicenciar.
Um licenciamento claro é parte essencial de um código aberto formal. Cada publicação futura de código-fonte, documentação, dados ou ferramentas incluirá termos adequados às suas dependências, às licenças upstream e ao uso pretendido.
Isso evita aplicar por engano a licença de um módulo a outro e protege os colaboradores, os projetos upstream e os usuários downstream.
A direção de longo prazo do programa
A direção é clara: aumentar continuamente a quantidade de material técnico público, verificável e reproduzível.
1. Continuar ampliando a documentação técnica pública
Isso inclui ciclos de vida de conexão, roteamento, DNS, mudanças de rede, configuração segura e testes em diferentes plataformas.
2. Continuar publicando registros de produto versionados
Os registros passarão a incluir plataformas, versões, datas, checksums, mudanças relevantes, limitações conhecidas e links estáveis para citação.
3. Continuar acrescentando conjuntos de dados reais de desempenho
Dados datados, versionados, específicos de cada ambiente e legíveis por máquina serão publicados de acordo com o método público.
4. Continuar publicando relatórios de segurança, desempenho e transparência
Os relatórios vão diferenciar política, teste interno, reprodução independente e avaliação de terceiros.
5. Incentivar a reprodução independente
Os pesquisadores podem usar os mesmos métodos e formatos para comparar redes, dispositivos e regiões diferentes.
6. Continuar aprimorando as ferramentas de publicação e de dados
A automação será ampliada em torno da formatação, da segurança, da documentação e do fluxo de testes.
7. Publicar o código-fonte dos produtos VPN em etapas
Depois das revisões de segurança, privacidade, dependências e licenciamento, o protocolo, os clientes e outras tecnologias centrais previstas serão publicados aos poucos.
8. Construir um registro mais completo de divulgações e correções
Os problemas de segurança relevantes, as versões afetadas, as versões corrigidas e as atualizações posteriores terão um histórico claro.
O repositório contém metadados de citação. Os pesquisadores devem citar as Releases com tag, os commits imutáveis e o relatório ou conjunto de dados datado que realmente usaram, e não materiais promocionais sem data.
De declarações públicas a uma verificação sustentável
O código aberto não deve ser apenas um evento de lançamento.
Um código aberto de longo prazo exige manutenção, participação externa, licenciamento claro, gestão de versões, correções de segurança e material técnico que outras pessoas possam verificar e reproduzir.
Começar pela documentação, pelos métodos de pesquisa, pelos formatos de dados, pelos padrões de evidência, pelas estruturas de relatórios e pelas ferramentas de validação cria a base para uma publicação mais ampla do código-fonte.
Primeiro, criar um ponto de entrada público
Os materiais técnicos, de segurança, de privacidade e de desempenho, antes dispersos, passam a ficar reunidos em um repositório do GitHub com manutenção ativa.
Segundo, estabelecer padrões de publicação
O programa define o que pode ser publicado, quais campos os testes precisam conter, como as evidências são classificadas e como as correções são registradas.
Terceiro, criar a base para a abertura futura do código
Os processos de segurança, privacidade, licenciamento e gestão de versões são preparados para relatórios, conjuntos de dados, protocolos, clientes e outros módulos.
Por isso, a primeira fase não apresenta uma publicação inicial limitada como se fosse o resultado completo. Ela inicia um processo pensado para crescer.
Perguntas frequentes (FAQ)
O SingLinkVPN lançou oficialmente o seu programa de código aberto?
Sim. O repositório oficial de código aberto e pesquisa técnica do SingLinkVPN está no ar, e a documentação, os métodos de pesquisa, os formatos de dados e as ferramentas de validação da primeira fase são públicos.
Todo o código-fonte da VPN já é público?
Não. O código-fonte do protocolo, dos clientes e de outros produtos do SingLinkVPN será publicado módulo por módulo, após as revisões de segurança, privacidade, dependências e licenciamento.
Por que não publicar tudo de uma vez?
Um produto de VPN pode conter informações de servidores de produção, credenciais, APIs privadas, mecanismos de defesa sensíveis, dependências de terceiros e código sob licenças diferentes.
A revisão em etapas reduz o risco de expor dados de usuários, detalhes de infraestrutura, credenciais ativas ou código de terceiros que não pode ser redistribuído.
Dados reais de desempenho serão publicados?
Sim. O método e o formato legível por máquina são o primeiro passo. Em seguida virão dados e relatórios datados e versionados, com ambiente, tamanho da amostra e limitações.
Os relatórios de segurança e de transparência serão públicos?
Sim. O repositório tem um diretório de relatórios dedicado e regras de publicação. Os relatórios serão acrescentados quando as evidências, os métodos, as versões e as limitações estiverem prontos.
Publicar um modelo de segurança significa que uma auditoria de terceiros foi concluída?
Não. O modelo de segurança é uma base pública para testes e avaliações futuros.
Uma avaliação de terceiros vai identificar o avaliador e trazer o link para um relatório verificável. Ela não será apresentada como teste interno.
Com o que os desenvolvedores podem contribuir?
Os desenvolvedores podem contribuir com documentação, tradução, métodos de pesquisa, qualidade dos dados, acessibilidade, ferramentas de validação e reprodução de testes.
As vulnerabilidades de segurança devem ser relatadas de forma privada, e não publicadas em uma Issue pública.
Os dados públicos vão conter dados de usuários?
Não. Os dados públicos precisam ser agregados ou desidentificados e não podem conter dados de conta, dados de pagamento, endereços IP privados, tokens de acesso, logs de produção nem tráfego bruto de produção.
Conclusão: o código aberto é o começo da confiança de longo prazo
O programa de código aberto do SingLinkVPN já está em andamento.
A primeira fase estabelece a documentação técnica, os métodos de pesquisa, os padrões de evidência, os formatos de dados, as regras de divulgação, as estruturas de relatórios e as ferramentas de validação.
Mais relatórios de segurança, desempenho e transparência virão. Mais dados públicos serão acrescentados em um formato consistente. Mais material técnico e código-fonte dos produtos serão publicados em etapas, após as revisões de segurança, privacidade e licenciamento.
Este não é um anúncio de marca pontual nem o passo final. É um esforço de engenharia contínuo.
O nosso objetivo é transformar as informações técnicas, de segurança, de privacidade e de desempenho do SingLinkVPN, hoje descritas apenas pela marca, em evidências públicas que a comunidade possa inspecionar, citar, verificar, reproduzir e continuar examinando.
Damos as boas-vindas a desenvolvedores, pesquisadores de segurança, mídia técnica e usuários da comunidade que queiram melhorar a documentação, reproduzir pesquisas, validar dados e participar das discussões técnicas.
O código aberto é o começo da confiança de longo prazo.
E este é só o primeiro passo.


