Plan de código abierto de SingLinkVPN

El código abierto es el comienzo de la confianza a largo plazo.

SingLinkVPN ha puesto en marcha formalmente su programa de código abierto e investigación técnica y ha creado en GitHub el repositorio oficial SingLinkVPN Open Source and Technical Research (código abierto e investigación técnica de SingLinkVPN).

No se trata de una publicación puntual ni de una página de documentación pensada solo para hojearla. Es un esfuerzo de ingeniería a largo plazo que se actualizará de forma continua y se ampliará con el tiempo.

El material disponible hoy es la primera fase de un programa más amplio.

La primera fase incluye documentación técnica pública, modelos de seguridad y privacidad, métodos reproducibles de pruebas de rendimiento, formatos de datos legibles por máquina, un marco para conjuntos de datos públicos, directorios de informes, herramientas de investigación, un proceso de divulgación de seguridad y normas para la publicación de evidencias.

En fases posteriores, SingLinkVPN tiene previsto publicar por etapas más material técnico, informes de investigación y código fuente del producto, sujeto a revisiones de seguridad, privacidad, licencias y estabilidad del producto. Entre las áreas previstas están el protocolo VPN, los clientes VPN y otras tecnologías VPN principales que, tras la revisión, sean adecuadas para su publicación.

Por tanto, la publicación actual no es el final del programa, sino el primer paso de un proceso de código abierto continuo.

El repositorio oficial contiene ya los directorios docs, data, reports, tools, tests y de automatización de GitHub, que sirven para mantener la documentación pública, los datos de investigación, el material de seguridad, las pruebas de rendimiento y las herramientas de validación abiertas. El repositorio se describe explícitamente como un proyecto mantenido de forma activa.

Repositorio oficial: SingLinkLabs / singlink-vpn-open-source Estado actual: La primera fase es pública. El material técnico adicional, los informes de investigación y el código fuente del producto se publicarán por etapas.

¿Por qué SingLinkVPN pone en marcha un programa de código abierto?

Una VPN está estrechamente ligada al transporte de red, la seguridad, la privacidad y el tratamiento de datos.

La mayor parte de un servicio VPN funciona dentro de sistemas que los usuarios no pueden observar directamente. Los usuarios pueden ver la interfaz de la aplicación, la lista de servidores, la velocidad de conexión y la descripción del producto, pero no pueden confirmar fácilmente:

• cómo se midieron los resultados de velocidad publicados;
• qué versión del software y qué entorno de red se usaron;
• si las pruebas fallidas se registraron de forma completa;
• si una afirmación de seguridad es un compromiso de política, una prueba interna o una evaluación independiente;
• si un informe incluye fechas, versiones, métodos e historial de correcciones;
• si otro investigador puede reproducir el resultado;
• si los cambios técnicos y de seguridad se pueden seguir de una versión a otra.

Las declaraciones de la marca por sí solas no pueden responder del todo a estas preguntas.

El programa pretende convertir la información técnica, de seguridad, de privacidad y de rendimiento de SingLinkVPN, que hasta ahora eran afirmaciones del producto, en material público que otros puedan inspeccionar, citar, verificar, reproducir y seguir examinando.

Para ello hace falta un sistema de publicación continuo, no simplemente subir archivos a Internet:

1. el material técnico importante debe tener una versión definida;
2. las afirmaciones medibles deben indicar la fecha y el entorno de la prueba;
3. los resultados de rendimiento deben estar respaldados por los datos correspondientes;
4. las pruebas internas y las evaluaciones de terceros deben distinguirse con claridad;
5. las correcciones importantes deben dejar un registro público;
6. el código fuente del producto debe publicarse por fases tras una revisión de seguridad;
7. la comunidad debe poder comprobar la estructura y la integridad de los datos con herramientas públicas.

El repositorio exige que cada afirmación medible incluya la fecha de la prueba, la versión del software, el entorno, el método, el tamaño de la muestra, los datos originales o agregados y las limitaciones conocidas. Los superlativos no verificables, como «la más rápida», «la más segura» o las afirmaciones de privacidad absoluta, no se consideran evidencia.

¿Qué está disponible en la primera fase?

La primera fase establece ocho líneas de trabajo públicas:

1. la arquitectura de desarrollo VPN y la documentación técnica pública;
2. los registros de producto y de versiones de SingLinkVPN;
3. un modelo de seguridad y privacidad;
4. métodos reproducibles de pruebas de rendimiento;
5. formatos de datos de prueba y un marco de conjuntos de datos públicos;
6. directorios de informes de seguridad, rendimiento y transparencia;
7. herramientas abiertas de validación de datos y de investigación;
8. la notificación de vulnerabilidades y la divulgación responsable.

En conjunto, sientan la base necesaria para la futura publicación del código fuente, los datos públicos y la investigación independiente.

1. Arquitectura de desarrollo VPN pública y documentación técnica

La primera fase incluye una arquitectura de cliente VPN multiplataforma.

No está ligada a un lenguaje de programación ni a un sistema operativo concretos. Describe los módulos principales que necesita un cliente VPN multiplataforma, como la interfaz, el ciclo de vida de la conexión, la gestión del túnel, el enrutamiento, el DNS, la configuración, las pruebas de seguridad y el diagnóstico local.

1. Capa de interfaz

La capa de interfaz muestra el estado de la cuenta, la selección de servidor, el estado de la conexión, los errores, los resultados del diagnóstico y las funciones de accesibilidad.

El estado de conexión que muestra la interfaz debe derivarse de la máquina de estados real de la conexión, y no simplemente de si el usuario ha pulsado el botón de conectar.

2. Capa de orquestación de sesiones

Esta capa se encarga de:

• la conexión;
• la desconexión;
• los reintentos automáticos;
• los cambios de red;
• la suspensión y reactivación del dispositivo;
• el reinicio de la aplicación;
• la recuperación tras una interrupción anómala.

Debe impedir que resultados de conexión obsoletos sobrescriban el trabajo más reciente y garantizar que las acciones repetidas no creen conflictos.

3. Capa de adaptación del túnel

Esta capa se integra con las API de VPN nativas de los distintos sistemas operativos, lo que incluye:

• la entrada y salida de paquetes;
• el ciclo de vida del túnel;
• la configuración de la MTU;
• los permisos del sistema operativo;
• las restricciones de ejecución en segundo plano;
• las notificaciones de interrupción del túnel.

4. Capa de enrutamiento y DNS

Esta capa gestiona:

• las rutas predeterminadas;
• el túnel dividido (split tunneling);
• las rutas excluidas;
• la selección de DNS;
• la política de IPv4 e IPv6;
• el acceso a la red local;
• la protección contra fugas de DNS y de rutas.

Las pruebas de fugas no pueden limitarse a la conexión inicial. También deben cubrir la reconexión, los cambios de red, la suspensión y reactivación y el cierre anómalo de la aplicación.

5. Capa de transporte

La capa de transporte se encarga de las sesiones autenticadas, el comportamiento del transporte, la gestión de la congestión, la política de keepalive y la migración entre redes.

6. Capa de configuración

La capa de configuración procesa una configuración remota versionada, firmada y minimizada, y rechaza las configuraciones no válidas, caducadas o degradadas a versiones anteriores.

7. Capa de observabilidad

Respetando las protecciones de privacidad, esta capa ofrece:

• el estado de salud local;
• diagnósticos de conexión;
• clasificación de errores;
• resultados de pruebas reproducibles;
• datos de estado técnico que no contienen la actividad de red del usuario.

La publicación actual abarca la arquitectura de alto nivel y los principios de desarrollo seguro. Los módulos más específicos y el código fuente solo se añadirán cuando se completen las revisiones correspondientes.

2. Un registro público y versionado del producto

SingLinkVPN también ha creado un registro público del producto que separa los distintos tipos de información.

Hechos del producto

Incluyen:

• las plataformas compatibles;
• las versiones públicas;
• las fechas de lanzamiento;
• las fuentes de descarga oficiales;
• las sumas de verificación disponibles;
• los cambios importantes de funciones y compatibilidad.

Descripciones de la arquitectura

Ofrecen diseños de alto nivel sin exponer sistemas sensibles, credenciales ni entornos de producción.

Resultados de medición

Los resultados técnicos y de rendimiento deben incluir su fecha, método, entorno, muestra y datos de respaldo.

Declaraciones de política

Abarcan los compromisos de funcionamiento del producto, de seguridad y de privacidad. Una declaración de política no se presenta como una verificación independiente.

Esta separación ayuda a no confundir la política, las pruebas internas, los detalles de implementación y la investigación independiente. Los registros formales de cada versión irán incluyendo la plataforma, la versión, la fecha, la fuente, las sumas de verificación disponibles, los cambios importantes de seguridad y compatibilidad, las limitaciones conocidas y etiquetas de Git inmutables o enlaces a Releases.

3. Un modelo público de seguridad y privacidad

La seguridad no se puede describir solo con palabras como «seguro» o «cifrado».

Por eso, la primera fase publica un modelo de seguridad y privacidad que define los riesgos que deberán examinar las pruebas, los informes y las evaluaciones independientes posteriores.

El alcance actual de amenazas incluye:

• la observación del tráfico en la red local;
• las fugas de DNS;
• las fugas de IPv6;
• las fugas de WebRTC;
• la interrupción de rutas durante la reconexión;
• la protección del tráfico al pasar entre Wi-Fi y redes móviles;
• los cambios maliciosos en la configuración remota;
• la degradación de la configuración;
• la exposición de credenciales guardadas en un dispositivo;
• el riesgo de las dependencias de terceros;
• el riesgo en la cadena de suministro de compilación y publicación;
• el abuso de cuentas;
• las sesiones no autorizadas;
• la recogida excesiva de datos de diagnóstico o de soporte.

Cada prueba de seguridad pública debe indicar:

• la versión del cliente afectada;
• el sistema operativo;
• la fecha de la prueba;
• las condiciones de red;
• el método;
• el comportamiento esperado;
• el comportamiento observado;
• las limitaciones conocidas.

El modelo también separa la política, la documentación de arquitectura, las pruebas internas y las evaluaciones de terceros.

Solo un informe de un evaluador o investigador independiente identificado, respaldado por un documento verificable, puede etiquetarse como evaluación de terceros. Así se crea una norma coherente y auditable para los futuros informes de seguridad.

4. Un método reproducible de pruebas de rendimiento VPN

El rendimiento de una VPN depende de muchos factores externos:

• el país o la región de quien hace la prueba;
• el proveedor de banda ancha o de red móvil;
• la calidad de la red local;
• el tránsito internacional;
• la hora del día;
• el rendimiento del dispositivo;
• la versión del cliente;
• el protocolo;
• la carga del servidor;
• el servidor de prueba;
• la región de destino.

Por eso, una única velocidad máxima no representa la experiencia de todos los usuarios.

El método publicado exige que cada registro incluya:

• la hora de la prueba en UTC;
• un identificador único de la prueba;
• la versión del cliente;
• el sistema operativo;
• el tipo de dispositivo;
• la etiqueta del protocolo;
• la versión de la metodología;
• el país o la región de la prueba;
• el tipo de red;
• el número de muestras;
• el nivel de evidencia.

Los indicadores principales son:

Mediana de la latencia de conexión

La mediana de la latencia en milisegundos a lo largo de varias muestras, en lugar de un único mejor resultado.

Jitter en el percentil 95

El nivel alto de variación de la latencia observado en la mayoría de las muestras.

Tasa de pérdida de paquetes

La proporción de paquetes perdidos durante la prueba.

Mediana de la velocidad de descarga

La mediana del rendimiento de descarga en Mbps a lo largo de varias muestras.

Mediana de la velocidad de subida

La mediana del rendimiento de subida en Mbps a lo largo de varias muestras.

Tasa de conexiones correctas

El porcentaje de intentos correctos en pruebas de conexión repetidas.

Mediana del tiempo de reconexión

La mediana del tiempo necesario para recuperarse tras un cambio de red o una interrupción.

El flujo de trabajo formal es:

1. registrar la red de referencia sin la VPN;
2. mantener constantes el dispositivo, la red, el destino y la ventana de muestreo;
3. hacer un calentamiento que no se contabiliza;
4. repetir las pruebas de conexión y de transferencia;
5. conservar las muestras fallidas en lugar de borrarlas en silencio;
6. publicar los resultados agregados y los datos legibles por máquina;
7. divulgar las limitaciones conocidas, las interrupciones y las muestras excluidas.

Las pruebas comparativas deben hacerse en condiciones equiparables. Cualquier cambio de proveedor, ruta, dispositivo, servidor de prueba o ventana de muestreo debe divulgarse. A medida que avancen las pruebas, se irán añadiendo con este método conjuntos de datos fechados, versionados y descargables.

5. Un formato público de datos de prueba legible por máquina

Junto con los informes legibles para personas, SingLinkVPN publica un formato de datos de rendimiento legible por máquina.

El JSON Schema exige que cada registro de rendimiento incluya:

• test_id: identificador de la prueba;
• tested_at_utc: hora de la prueba en UTC;
• client_version: versión del cliente;
• platform: plataforma de la prueba;
• protocol_label: etiqueta del protocolo;
• country: país o región de la prueba;
• network_type: tipo de red;
• sample_count: número de muestras;
• latency_ms_median: mediana de la latencia;
• jitter_ms_p95: jitter en el percentil 95;
• packet_loss_pct: tasa de pérdida de paquetes;
• download_mbps_median: mediana de la velocidad de descarga;
• upload_mbps_median: mediana de la velocidad de subida;
• connection_success_pct: tasa de conexiones correctas;
• reconnect_ms_median: mediana del tiempo de reconexión;
• methodology_version: versión del método;
• evidence_level: nivel de evidencia.

Actualmente, la evidencia puede marcarse como:

• prueba interna;
• reproducción independiente;
• evaluación de terceros.

El formato permite a desarrolladores e investigadores revisar directamente los campos obligatorios y los rangos de valores, y usar la misma estructura para reproducir y comparar resultados en lugar de depender solo de gráficos o conclusiones narrativas.

6. Informes de seguridad, rendimiento y transparencia

El repositorio contiene un directorio de informes dedicado a la publicación continua de:

• informes de seguridad;
• informes de rendimiento;
• investigaciones sobre privacidad;
• informes de transparencia;
• evaluaciones de terceros;
• resultados reproducidos de forma independiente;
• avisos sobre correcciones de seguridad importantes.

Antes de publicarse, cada informe formal debe indicar:

• la fecha de publicación;
• el autor o responsable del mantenimiento;
• la versión del producto afectada;
• el método;
• la fuente de los datos;
• el nivel de evidencia;
• las limitaciones conocidas;
• el historial de correcciones.

Las pruebas internas y las evaluaciones independientes llevan etiquetas distintas. La primera fase establece la estructura de los informes, las reglas de evidencia y el marco de versiones; los informes se añadirán cuando sus datos y su revisión estén listos, en lugar de publicarse una vez y abandonarse.

7. Herramientas abiertas de validación e investigación

La primera fase también publica varias herramientas de investigación y validación en Python.

publication_guard.py

Revisa documentos, datos y herramientas antes de su publicación en busca de:

• credenciales;
• formatos de claves;
• rutas privadas;
• archivos comprimidos;
• archivos binarios;
• tipos de código fuente no aprobados para su publicación;
• archivos demasiado grandes;
• formatos habituales de secretos en uso;
• contenido que pueda describir sistemas sensibles.

validate_benchmark.py

Valida los archivos CSV de las pruebas de rendimiento, incluidos:

• los nombres de las columnas;
• los campos obligatorios;
• los rangos numéricos;
• las etiquetas de evidencia;
• la estructura de los datos de prueba.

check_relative_links.py

Revisa los enlaces relativos en Markdown y confirma que existen los archivos públicos a los que se hace referencia.

check_multilingual_seo.py

Revisa los documentos multilingües y la estructura relacionada con las búsquedas para mantener alineado el material en inglés, chino simplificado y chino tradicional.

Estas herramientas no forman parte del núcleo de conexión VPN. Son infraestructura de publicación pensada para reducir los errores de formato, los enlaces rotos, la exposición accidental de información sensible y las incoherencias entre versiones. Los colaboradores externos pueden usar las mismas herramientas con sus aportaciones.

8. Una norma pública de evidencia en cinco niveles

Nivel 1: declaración de política

Un compromiso de producto, seguridad, funcionamiento o privacidad publicado por el responsable del mantenimiento. Es un compromiso público, no una prueba de implementación ni una auditoría independiente.

Nivel 2: documentación de implementación

Una descripción técnica de alto nivel y versionada que no contiene direcciones de servidores, credenciales, API privadas ni otra información sensible.

Nivel 3: prueba interna

Una prueba realizada por SingLinkLabs con un método público, con fecha, versión, entorno y datos.

Nivel 4: resultado reproducido

Un resultado independiente obtenido por otro desarrollador o investigador con el mismo método y los datos públicos.

Nivel 5: evaluación de terceros

Una evaluación realizada por un investigador u organización independiente identificado, con un informe formal verificable.

Estos niveles no son intercambiables. Las pruebas internas no pueden etiquetarse como evaluación de terceros; una política no puede tratarse como verificación independiente; y publicar un método no significa que un resultado ya se haya reproducido.

Cada informe debería responder a estas preguntas: ¿quién llegó a la conclusión, cuándo, con qué versión y con qué método?

Las correcciones importantes requieren un nuevo commit de Git y una entrada en el registro de cambios. Los datos publicados no deben sustituirse en silencio, y los datos superados deben seguir siendo identificables.

9. Notificación de vulnerabilidades y divulgación responsable

La publicación abierta y la divulgación segura deben ir de la mano.

Las vulnerabilidades sin corregir, las credenciales en uso, los endpoints privados, las direcciones de servidores y los datos de usuarios no deben publicarse en una Issue pública.

Las vulnerabilidades deben comunicarse de forma privada a través del correo de seguridad o de GitHub Security Advisories, identificándolas claramente como divulgaciones de seguridad. Si no hay un correo de seguridad publicado, consulta el archivo `SECURITY.md` del repositorio y no intentes adivinar una dirección.

Un informe debería incluir:

• la versión afectada;
• la plataforma afectada;
• las condiciones de reproducción;
• el impacto en la seguridad;
• una forma segura de contactar con quien informa;
• material de reproducción que no contenga datos reales de usuarios.

Los informes de seguridad pasan por:

1. clasificación y confirmación;
2. evaluación del impacto;
3. corrección;
4. publicación de una versión corregida;
5. un plazo razonable para actualizar;
6. publicación de un aviso de seguridad.

Los avisos públicos distinguen el impacto confirmado del riesgo hipotético e indican las versiones afectadas y las corregidas.

10. Datos públicos no significa datos de usuarios públicos

La transparencia técnica no debe lograrse a costa de la privacidad de los usuarios.

El repositorio prohíbe que las Issues, las pull requests, los conjuntos de datos o los documentos de investigación contengan:

• datos personales;
• identificadores de cuenta;
• datos de pago;
• conversaciones con soporte;
• direcciones IP privadas;
• tokens de acceso;
• credenciales de producción;
• registros de producción;
• tráfico de producción en bruto;
• datos de prueba que permitan identificar a un usuario concreto.

Los datos de rendimiento deben estar agregados o anonimizados. Antes de la publicación, los revisores deben confirmar que un conjunto de datos no contiene datos a nivel de usuario, credenciales ni material que permita identificar a un usuario real.

El programa hace transparentes la tecnología, los métodos, los informes y el código fuente revisado. No publica información de usuarios, datos de servidores sensibles para la seguridad ni credenciales de producción.

11. ¿Cómo puede participar la comunidad?

Los desarrolladores, los investigadores de seguridad y los miembros de la comunidad pueden:

• mejorar la documentación técnica;
• corregir errores de la documentación;
• mejorar las traducciones al chino tradicional, al chino simplificado y al inglés;
• mejorar la reproducibilidad del método de prueba;
• mejorar la calidad de los datos públicos;
• mejorar la accesibilidad;
• añadir herramientas de investigación;
• mejorar la validación de formatos;
• encontrar enlaces rotos;
• proponer nuevos métodos de investigación públicos;
• sugerir mejoras en el diseño de las pruebas;
• reproducir las pruebas públicas respetando las reglas de seguridad.

Las aportaciones no deben contener:

• código fuente del producto no aprobado;
• información de infraestructura privada;
• credenciales o claves;
• datos de usuarios;
• endpoints privados;
• registros de producción;
• instrucciones completas para explotar una vulnerabilidad sin corregir.

Toda aportación medible debe indicar además su fuente, método, fecha y limitaciones.

¿Significa esto que SingLinkVPN ya es totalmente de código abierto?

No. Esta es la primera fase, no la última.

La primera fase da prioridad a:

• la documentación técnica;
• la arquitectura de desarrollo;
• los modelos de seguridad y privacidad;
• los métodos de pruebas de rendimiento;
• los formatos de datos legibles por máquina;
• las herramientas de validación;
• la política de evidencias y publicación;
• la divulgación responsable;
• un marco para futuros informes y publicaciones de código fuente.

La primera fase no incluye:

• el código fuente completo del cliente VPN;
• el código fuente del servidor;
• el código fuente del sistema de pagos;
• la configuración de los servidores de producción;
• las API privadas;
• las credenciales de autenticación;
• los detalles de implementación sensibles contra bloqueos o frente a redes adversas;
• el código fuente completo del protocolo principal.

Esto no significa necesariamente que queden excluidos del programa en su conjunto. Cada módulo del producto necesita su propia revisión de seguridad, privacidad, dependencias y licencias.

Una vez completada la revisión, las publicaciones posteriores incluirán:

• un directorio de código abierto claramente definido;
• la licencia correspondiente;
• el historial de versiones;
• los límites de seguridad;
• un registro de cambios;
• la fecha de publicación;
• una etiqueta de Git o una Release verificables.

Crear primero las normas de publicación, las estructuras de datos, las reglas de seguridad y las herramientas de investigación establece una base más segura y reduce el riesgo de exponer credenciales, infraestructura, datos de usuarios o código de terceros que no se puede redistribuir legalmente.

Las licencias se definirán a medida que se publique más material

El repositorio actual puede consultarse públicamente, pero las licencias completas de reutilización del código y del contenido aún se están organizando según el tipo de material y de código fuente.

Hasta que se publique una licencia explícita, los usuarios no deben suponer que han recibido:

• el derecho a copiar;
• el derecho a modificar;
• el derecho a redistribuir;
• el derecho a un uso comercial;
• el derecho a cambiar la licencia.

Unas licencias claras son una parte esencial del código abierto formal. Cada publicación posterior de código fuente, documentación, datos o herramientas incluirá condiciones adecuadas a sus dependencias, a las licencias de origen y al uso previsto.

Así se evita aplicar por error la licencia de un módulo a otro y se protege a los colaboradores, a los proyectos de origen y a los usuarios posteriores.

Orientación a largo plazo del programa

La orientación es clara: aumentar de forma continua la cantidad de material técnico público, verificable y reproducible.

1. Seguir ampliando la documentación técnica pública

Esto incluye los ciclos de vida de las conexiones, el enrutamiento, el DNS, los cambios de red, la configuración segura y las pruebas en distintas plataformas.

2. Seguir publicando registros de producto versionados

Los registros añadirán plataformas, versiones, fechas, sumas de verificación, cambios importantes, limitaciones conocidas y enlaces estables para citar.

3. Seguir añadiendo conjuntos de datos de rendimiento reales

Se publicarán datos fechados, versionados, específicos de cada entorno y legibles por máquina, según el método público.

4. Seguir publicando informes de seguridad, rendimiento y transparencia

Los informes distinguirán entre política, pruebas internas, reproducción independiente y evaluación de terceros.

5. Fomentar la reproducción independiente

Los investigadores pueden usar los mismos métodos y formatos para comparar distintas redes, dispositivos y regiones.

6. Seguir mejorando las herramientas de publicación y de datos

La automatización se ampliará en torno al formato, la seguridad, la documentación y el flujo de pruebas.

7. Publicar por etapas el código fuente del producto VPN

Tras la revisión de seguridad, privacidad, dependencias y licencias, se irán publicando el protocolo, el cliente y otras tecnologías principales previstas.

8. Crear un registro más completo de divulgaciones y correcciones

Los problemas de seguridad importantes, las versiones afectadas, las versiones corregidas y las actualizaciones posteriores tendrán un historial claro.

El repositorio contiene metadatos de citación. Los investigadores deberían citar las Releases etiquetadas, los commits inmutables y el informe o conjunto de datos fechado que hayan usado realmente, y no material promocional sin fecha.

De las declaraciones públicas a la verificación sostenible

El código abierto no debería ser solo un evento de lanzamiento.

El código abierto a largo plazo requiere mantenimiento, participación externa, licencias claras, gestión de versiones, correcciones de seguridad y material técnico que otros puedan verificar y reproducir.

Empezar por la documentación, los métodos de investigación, los formatos de datos, las normas de evidencia, las estructuras de los informes y las herramientas de validación sienta la base para una publicación más amplia del código fuente.

Primero, crear un punto de acceso público

El material técnico, de seguridad, de privacidad y de rendimiento que antes estaba disperso se reúne en un repositorio de GitHub mantenido.

Segundo, establecer normas de publicación

El programa define qué se puede publicar, qué campos deben contener las pruebas, cómo se clasifica la evidencia y cómo se registran las correcciones.

Tercero, sentar las bases del código abierto posterior

Se preparan los procesos de seguridad, privacidad, licencias y gestión de versiones para los informes, los conjuntos de datos, los protocolos, los clientes y otros módulos.

Por tanto, la primera fase no presenta una publicación inicial limitada como si fuera el resultado completo. Abre un proceso pensado para crecer.

Preguntas frecuentes (FAQ)

¿Ha puesto en marcha SingLinkVPN formalmente su programa de código abierto?

Sí. El repositorio oficial de código abierto e investigación técnica ya está activo, y la documentación, los métodos de investigación, los formatos de datos y las herramientas de validación de la primera fase son públicos.

¿Es público ya todo el código fuente de la VPN?

No. El código fuente del protocolo, del cliente y de otras partes del producto se publicará módulo a módulo tras la revisión de seguridad, privacidad, dependencias y licencias.

¿Por qué no publicarlo todo de una vez?

Un producto VPN puede contener información de servidores de producción, credenciales, API privadas, mecanismos defensivos sensibles, dependencias de terceros y código sujeto a distintas licencias.

La revisión por etapas reduce el riesgo de exponer datos de usuarios, detalles de infraestructura, credenciales en uso o código de terceros que no se puede redistribuir.

¿Se publicarán datos de rendimiento reales?

Sí. El método y el formato legible por máquina son el primer paso. Después llegarán datos e informes fechados y versionados, con el entorno, el tamaño de la muestra y las limitaciones.

¿Serán públicos los informes de seguridad y transparencia?

Sí. El repositorio tiene un directorio de informes dedicado y reglas de publicación. Los informes se añadirán cuando estén listos su evidencia, sus métodos, sus versiones y sus limitaciones.

¿Publicar un modelo de seguridad significa que se ha completado una auditoría de terceros?

No. El modelo de seguridad es una base pública para las pruebas y evaluaciones posteriores.

Una evaluación de terceros identificará al evaluador y enlazará a un informe verificable. No se presentará como prueba interna.

¿Qué pueden aportar los desarrolladores?

Los desarrolladores pueden contribuir a la documentación, las traducciones, los métodos de investigación, la calidad de los datos, la accesibilidad, las herramientas de validación y la reproducción de pruebas.

Las vulnerabilidades de seguridad deben comunicarse de forma privada, no publicarse en una Issue pública.

¿Los datos públicos contendrán datos de usuarios?

No. Los datos públicos deben estar agregados o anonimizados y no pueden contener datos de cuentas, datos de pago, direcciones IP privadas, tokens de acceso, registros de producción ni tráfico de producción en bruto.

Conclusión: el código abierto es el comienzo de la confianza a largo plazo

El programa de código abierto de SingLinkVPN ya está en marcha.

La primera fase establece la documentación técnica, los métodos de investigación, las normas de evidencia, los formatos de datos, las reglas de divulgación, las estructuras de los informes y las herramientas de validación.

Llegarán más informes de seguridad, rendimiento y transparencia. Se añadirán más datos públicos con un formato coherente. Y se publicará por etapas más material técnico y código fuente del producto tras la revisión de seguridad, privacidad y licencias.

No es un anuncio de marca puntual ni el paso final. Es un esfuerzo de ingeniería continuo.

Nuestro objetivo es que la información técnica, de seguridad, de privacidad y de rendimiento de SingLinkVPN deje de ser material descrito solo por la marca y se convierta en evidencia pública que la comunidad pueda inspeccionar, citar, verificar, reproducir y seguir examinando.

Damos la bienvenida a desarrolladores, investigadores de seguridad, medios técnicos y usuarios de la comunidad que quieran mejorar la documentación, reproducir investigaciones, validar datos y participar en el debate técnico.

El código abierto es el comienzo de la confianza a largo plazo.

Y esto es solo el primer paso.

Ver el repositorio oficial de código abierto de SingLinkVPN