Le plan open source de SingLinkVPN

L’open source est le point de départ d’une confiance durable.

SingLinkVPN a officiellement lancé son programme open source et de recherche technique, et créé sur GitHub le dépôt officiel SingLinkVPN Open Source and Technical Research.

Il ne s’agit pas d’une publication ponctuelle ni d’une page de documentation destinée à être simplement parcourue. C’est un travail d’ingénierie de long terme, qui sera mis à jour en continu et étendu au fil du temps.

Les éléments disponibles aujourd’hui constituent la première phase d’un programme plus large.

La première phase couvre la documentation technique publique, les modèles de sécurité et de confidentialité, des méthodes de test de performances reproductibles, des formats de données lisibles par machine, un cadre pour des jeux de données publics, des répertoires de rapports, des outils de recherche, une procédure de divulgation des failles de sécurité et des normes de publication des preuves.

Dans les phases suivantes, SingLinkVPN prévoit de publier par étapes d’autres documents techniques, des rapports de recherche et le code source du produit, sous réserve d’examens de sécurité, de confidentialité, de licence et de stabilité du produit. Les domaines prévus comprennent le protocole VPN, les clients VPN et d’autres technologies VPN essentielles qui s’avèrent publiables après examen.

La publication actuelle n’est donc pas l’aboutissement du programme. C’est la première étape d’une démarche open source continue.

Le dépôt officiel contient désormais les répertoires docs, data, reports, tools, tests et d’automatisation GitHub, qui servent à tenir à jour la documentation publique, les données de recherche, les documents de sécurité, les tests de performances et des outils de validation ouverts. Le dépôt est explicitement présenté comme un projet activement maintenu.

Dépôt officiel : SingLinkLabs / singlink-vpn-open-source État actuel : la première phase est publique. D’autres documents techniques, des rapports de recherche et le code source du produit seront publiés par étapes.

Pourquoi SingLinkVPN lance-t-il un programme open source ?

Un VPN est étroitement lié au transport réseau, à la sécurité, à la confidentialité et au traitement des données.

L’essentiel d’un service VPN fonctionne dans des systèmes que les utilisateurs ne peuvent pas observer directement. Ils voient l’interface de l’application, la liste des serveurs, la vitesse de connexion et la description du produit, mais ne peuvent pas facilement vérifier :

• comment les résultats de vitesse publiés ont été mesurés ;
• quelle version du logiciel et quel environnement réseau ont été utilisés ;
• si les tests échoués ont été intégralement consignés ;
• si une déclaration de sécurité relève d’un engagement de principe, d’un test interne ou d’une évaluation indépendante ;
• si un rapport indique les dates, les versions, les méthodes et l’historique des corrections ;
• si un autre chercheur peut reproduire le résultat ;
• si les évolutions techniques et de sécurité peuvent être suivies d’une version à l’autre.

Les déclarations d’une marque ne suffisent pas, à elles seules, à répondre pleinement à ces questions.

Le programme vise à transformer les informations techniques, de sécurité, de confidentialité et de performances de SingLinkVPN, aujourd’hui simples affirmations commerciales, en documents publics que d’autres peuvent examiner, citer, vérifier, reproduire et continuer à scruter.

Cela exige un système de publication continu, et pas seulement la mise en ligne de fichiers :

1. les documents techniques importants doivent porter une version définie ;
2. les affirmations mesurables doivent indiquer la date et l’environnement du test ;
3. les résultats de performances doivent s’appuyer sur les données correspondantes ;
4. les tests internes et les évaluations tierces doivent être clairement distingués ;
5. les corrections importantes doivent laisser une trace publique ;
6. le code source du produit doit être publié par phases, après examen de sécurité ;
7. la communauté doit pouvoir vérifier la structure et l’exhaustivité des données à l’aide d’outils publics.

Le dépôt exige que chaque affirmation mesurable indique la date du test, la version du logiciel, l’environnement, la méthode, la taille de l’échantillon, les données brutes ou agrégées et les limites connues. Les superlatifs invérifiables comme « le plus rapide », « le plus sûr » ou les promesses de confidentialité absolue ne sont pas considérés comme des preuves.

Que contient la première phase ?

La première phase met en place huit chantiers publics :

1. l’architecture de développement VPN et la documentation technique publique ;
2. les fiches produit et l’historique des versions de SingLinkVPN ;
3. un modèle de sécurité et de confidentialité ;
4. des méthodes de test de performances reproductibles ;
5. des formats de données de test et un cadre de jeux de données publics ;
6. des répertoires de rapports sur la sécurité, les performances et la transparence ;
7. des outils ouverts de validation des données et de recherche ;
8. le signalement des vulnérabilités et la divulgation responsable.

Ensemble, ils posent les fondations nécessaires à la publication ultérieure du code source, à l’ouverture des données et à la recherche indépendante.

1. Une architecture de développement VPN et une documentation technique publiques

La première phase comprend une architecture de client VPN multiplateforme.

Elle n’est liée à aucun langage de programmation ni système d’exploitation particulier. Elle décrit plutôt les principaux modules dont un client VPN multiplateforme a besoin : interface, cycle de vie de la connexion, gestion du tunnel, routage, DNS, configuration, tests de sécurité et diagnostic local.

1. La couche interface

La couche interface présente l’état du compte, le choix du serveur, l’état de la connexion, les erreurs, les résultats de diagnostic et les fonctions d’accessibilité.

L’état de connexion affiché dans l’interface doit découler de la machine à états réelle de la connexion, et non du simple fait que l’utilisateur a appuyé sur le bouton de connexion.

2. La couche d’orchestration des sessions

Cette couche gère :

• la connexion ;
• la déconnexion ;
• les nouvelles tentatives automatiques ;
• les changements de réseau ;
• la mise en veille et le réveil de l’appareil ;
• le redémarrage de l’application ;
• la reprise après une interruption anormale.

Elle doit empêcher qu’un résultat de connexion périmé n’écrase une opération plus récente et faire en sorte que des actions répétées ne créent pas de conflits.

3. La couche d’adaptation du tunnel

Cette couche s’intègre aux API VPN natives des différents systèmes d’exploitation, notamment pour :

• l’entrée et la sortie des paquets ;
• le cycle de vie du tunnel ;
• la configuration du MTU ;
• les autorisations du système d’exploitation ;
• les restrictions d’exécution en arrière-plan ;
• les rappels en cas d’interruption du tunnel.

4. La couche routage et DNS

Cette couche gère :

• les routes par défaut ;
• le split tunneling (tunnel fractionné) ;
• les routes exclues ;
• le choix du DNS ;
• la politique IPv4 et IPv6 ;
• l’accès au réseau local ;
• la protection contre les fuites DNS et de routes.

Les tests de fuite ne peuvent pas se limiter à la connexion initiale. Ils doivent aussi couvrir la reconnexion, les changements de réseau, la mise en veille et le réveil, ainsi que l’arrêt anormal de l’application.

5. La couche transport

La couche transport est responsable des sessions authentifiées, du comportement du transport, de la gestion de la congestion, de la politique de keepalive et de la migration entre réseaux.

6. La couche configuration

La couche configuration traite une configuration distante versionnée, signée et réduite au minimum, et rejette toute configuration invalide, expirée ou rétrogradée.

7. La couche observabilité

Dans le respect des protections de la vie privée, cette couche fournit :

• l’état de santé local ;
• les diagnostics de connexion ;
• la classification des erreurs ;
• des résultats de test reproductibles ;
• des données d’état technique qui ne contiennent pas l’activité réseau de l’utilisateur.

La publication actuelle couvre l’architecture générale et les principes de développement sécurisé. Des modules plus précis et le code source ne seront ajoutés qu’une fois les examens correspondants terminés.

2. Un historique public et versionné du produit

SingLinkVPN a également mis en place un historique public du produit qui sépare les différents types d’informations.

Les faits sur le produit

Ils comprennent :

• les plateformes prises en charge ;
• les versions publiques ;
• les dates de sortie ;
• les sources de téléchargement officielles ;
• les sommes de contrôle disponibles ;
• les changements importants de fonctions et de compatibilité.

Les descriptions d’architecture

Elles présentent la conception générale sans exposer de systèmes sensibles, d’identifiants ni d’environnements de production.

Les résultats de mesure

Les performances et constats techniques doivent indiquer leur date, leur méthode, leur environnement, leur échantillon et les données qui les étayent.

Les déclarations de principe

Elles portent sur le fonctionnement du produit, la sécurité et les engagements de confidentialité. Une déclaration de principe n’est pas présentée comme une vérification indépendante.

Cette séparation évite de confondre principes, tests internes, détails d’implémentation et recherche indépendante. Les historiques de version officiels incluront progressivement la plateforme, la version, la date, la source, les sommes de contrôle disponibles, les changements importants de sécurité et de compatibilité, les limites connues et des tags Git immuables ou des liens vers les Releases.

3. Un modèle public de sécurité et de confidentialité

La sécurité ne peut pas se décrire uniquement avec des mots comme « sûr » ou « chiffré ».

La première phase publie donc un modèle de sécurité et de confidentialité qui définit les risques que les tests, rapports et évaluations indépendantes à venir devront examiner.

Le périmètre de menaces actuel comprend :

• l’observation du trafic sur le réseau local ;
• les fuites DNS ;
• les fuites IPv6 ;
• les fuites WebRTC ;
• l’interruption des routes pendant la reconnexion ;
• la protection du trafic lors du passage du Wi-Fi au réseau mobile ;
• les modifications malveillantes de la configuration distante ;
• la rétrogradation de la configuration ;
• l’exposition des identifiants stockés sur un appareil ;
• les risques liés aux dépendances tierces ;
• les risques de la chaîne d’approvisionnement lors de la compilation et de la publication ;
• l’usage abusif des comptes ;
• les sessions non autorisées ;
• la collecte excessive de données de diagnostic ou d’assistance.

Chaque test de sécurité public doit indiquer :

• la version du client concernée ;
• le système d’exploitation ;
• la date du test ;
• les conditions réseau ;
• la méthode ;
• le comportement attendu ;
• le comportement observé ;
• les limites connues.

Le modèle sépare aussi les principes, la documentation d’architecture, les tests internes et l’évaluation par des tiers.

Seul un rapport rédigé par un évaluateur ou un chercheur indépendant nommément identifié, et étayé par un rapport vérifiable, peut être qualifié d’évaluation tierce. Cela établit une norme cohérente et vérifiable pour les futurs rapports de sécurité.

4. Une méthode reproductible de test des performances VPN

Les performances d’un VPN dépendent de nombreux facteurs externes :

• le pays ou la région du testeur ;
• le fournisseur d’accès fixe ou mobile ;
• la qualité du réseau local ;
• le transit international ;
• l’heure de la journée ;
• les performances de l’appareil ;
• la version du client ;
• le protocole ;
• la charge du serveur ;
• le serveur de test ;
• la région de destination.

Une vitesse de pointe isolée ne représente donc pas l’expérience de chaque utilisateur.

La méthode publiée exige que chaque enregistrement indique :

• l’heure du test en UTC ;
• un identifiant de test unique ;
• la version du client ;
• le système d’exploitation ;
• le type d’appareil ;
• le libellé du protocole ;
• la version de la méthode ;
• le pays ou la région du test ;
• le type de réseau ;
• le nombre d’échantillons ;
• le niveau de preuve.

Les principaux indicateurs sont les suivants :

Latence de connexion médiane

La latence médiane en millisecondes sur plusieurs échantillons, plutôt qu’un seul meilleur résultat.

Gigue au 95e centile

Le niveau élevé de variation de la latence observé sur la plupart des échantillons.

Taux de perte de paquets

La proportion de paquets perdus pendant le test.

Vitesse de téléchargement médiane

Le débit descendant médian en Mbit/s sur plusieurs échantillons.

Vitesse d’envoi médiane

Le débit montant médian en Mbit/s sur plusieurs échantillons.

Taux de réussite de la connexion

Le pourcentage de tentatives réussies lors de tests de connexion répétés.

Temps de reconnexion médian

Le temps médian nécessaire pour rétablir la connexion après un changement de réseau ou une interruption.

La procédure formelle est la suivante :

1. mesurer le réseau de référence sans le VPN ;
2. garder constants l’appareil, le réseau, la destination et la fenêtre d’échantillonnage ;
3. effectuer un échauffement non comptabilisé ;
4. répéter les tests de connexion et de transfert ;
5. conserver les échantillons en échec au lieu de les supprimer discrètement ;
6. publier les résultats agrégés et des données lisibles par machine ;
7. indiquer les limites connues, les pannes et les échantillons exclus.

Les tests comparatifs doivent se faire dans des conditions comparables. Tout changement de fournisseur, de route, d’appareil, de serveur de test ou de fenêtre d’échantillonnage doit être signalé. Des jeux de données datés, versionnés et téléchargeables seront ajoutés selon cette méthode à mesure que les tests se poursuivent.

5. Un format public de données de test lisible par machine

En plus des rapports lisibles par un humain, SingLinkVPN publie un format de données de performances lisible par machine.

Le JSON Schema exige que chaque enregistrement de performances comprenne :

• test_id : identifiant du test ;
• tested_at_utc : heure du test en UTC ;
• client_version : version du client ;
• platform : plateforme de test ;
• protocol_label : libellé du protocole ;
• country : pays ou région du test ;
• network_type : type de réseau ;
• sample_count : nombre d’échantillons ;
• latency_ms_median : latence médiane ;
• jitter_ms_p95 : gigue au 95e centile ;
• packet_loss_pct : taux de perte de paquets ;
• download_mbps_median : vitesse de téléchargement médiane ;
• upload_mbps_median : vitesse d’envoi médiane ;
• connection_success_pct : taux de réussite de la connexion ;
• reconnect_ms_median : temps de reconnexion médian ;
• methodology_version : version de la méthode ;
• evidence_level : niveau de preuve.

Les preuves peuvent actuellement être classées comme :

• test interne ;
• reproduction indépendante ;
• évaluation tierce.

Ce format permet aux développeurs et aux chercheurs d’examiner directement les champs obligatoires et les plages de valeurs, et d’utiliser la même structure pour reproduire et comparer les résultats, au lieu de s’en remettre uniquement à des graphiques ou à des conclusions rédigées.

6. Rapports de sécurité, de performances et de transparence

Le dépôt contient un répertoire de rapports dédié à la publication continue de :

• rapports de sécurité ;
• rapports de performances ;
• travaux de recherche sur la confidentialité ;
• rapports de transparence ;
• évaluations tierces ;
• résultats reproduits de manière indépendante ;
• avis de correctifs de sécurité importants.

Avant publication, chaque rapport formel doit indiquer :

• la date de publication ;
• l’auteur ou le mainteneur ;
• la version du produit concernée ;
• la méthode ;
• la source des données ;
• le niveau de preuve ;
• les limites connues ;
• l’historique des corrections.

Les tests internes et les évaluations indépendantes portent des libellés différents. La première phase met en place la structure des rapports, les règles de preuve et le cadre de versionnage ; les rapports seront ajoutés à mesure que leurs données et leur examen seront prêts, au lieu d’être publiés une fois puis abandonnés.

7. Des outils ouverts de validation et de recherche

La première phase publie aussi plusieurs outils de recherche et de validation en Python.

publication_guard.py

Cet outil vérifie les documents, les données et les outils avant publication afin de détecter :

• des identifiants ;
• des formats de clés ;
• des chemins privés ;
• des archives ;
• des fichiers binaires ;
• des types de code source dont la publication n’est pas approuvée ;
• des fichiers trop volumineux ;
• des formats courants de secrets en production ;
• des contenus susceptibles de décrire des systèmes sensibles.

validate_benchmark.py

Cet outil valide les fichiers CSV de tests de performances, notamment :

• les noms de colonnes ;
• les champs obligatoires ;
• les plages numériques ;
• les libellés de preuve ;
• la structure des données de test.

check_relative_links.py

Cet outil vérifie les liens relatifs dans les fichiers Markdown et confirme que les fichiers publics référencés existent.

check_multilingual_seo.py

Cet outil vérifie les documents multilingues et leur structure liée au référencement, afin de maintenir l’alignement des contenus en anglais, en chinois simplifié et en chinois traditionnel.

Ces outils ne font pas partie du cœur de connexion VPN. Ils constituent une infrastructure de publication destinée à réduire les erreurs de format, les liens cassés, l’exposition accidentelle d’informations sensibles et les incohérences de version. Les contributeurs externes peuvent utiliser les mêmes outils sur leurs propositions.

8. Une norme publique de preuve à cinq niveaux

Niveau un : déclaration de principe

Un engagement relatif au produit, à la sécurité, au fonctionnement ou à la confidentialité, publié par le mainteneur. C’est un engagement public, et non une preuve de mise en œuvre ni un audit indépendant.

Niveau deux : documentation d’implémentation

Une description technique générale et versionnée, qui ne contient ni adresses de serveurs, ni identifiants, ni API privées, ni autres informations sensibles.

Niveau trois : test interne

Un test mené par SingLinkLabs selon une méthode publique, avec date, version, environnement et données.

Niveau quatre : résultat reproduit

Un résultat indépendant obtenu par un autre développeur ou chercheur avec la même méthode et les données publiques.

Niveau cinq : évaluation tierce

Une évaluation réalisée par un chercheur ou un organisme indépendant nommément identifié, avec un rapport formel vérifiable.

Ces niveaux ne sont pas interchangeables. Un test interne ne peut pas être présenté comme une évaluation tierce ; un principe ne peut pas tenir lieu de vérification indépendante ; et la publication d’une méthode ne signifie pas qu’un résultat a déjà été reproduit.

Chaque rapport doit répondre à ces questions : qui est parvenu à la conclusion, quand, avec quelle version et selon quelle méthode ?

Toute correction importante exige un nouveau commit Git et une entrée dans le journal des modifications. Les données publiées ne doivent pas être remplacées discrètement, et les données remplacées doivent rester identifiables.

9. Signalement des vulnérabilités et divulgation responsable

Publication ouverte et divulgation sécurisée doivent aller de pair.

Les vulnérabilités non corrigées, les identifiants actifs, les points d’accès privés, les adresses de serveurs et les données des utilisateurs ne doivent jamais être publiés dans une Issue publique.

Les signalements de vulnérabilités doivent être envoyés en privé, via l’adresse e-mail de sécurité ou GitHub Security Advisories, et clairement identifiés comme des divulgations de sécurité. Si aucune adresse e-mail de sécurité n’est publiée, consultez le fichier `SECURITY.md` du dépôt et n’essayez pas de deviner une adresse.

Un signalement doit comprendre :

• la version concernée ;
• la plateforme concernée ;
• les conditions de reproduction ;
• l’impact sur la sécurité ;
• un moyen sûr de contacter la personne qui signale ;
• des éléments de reproduction ne contenant aucune donnée réelle d’utilisateur.

Les signalements de sécurité passent par les étapes suivantes :

1. tri et confirmation ;
2. évaluation de l’impact ;
3. correction ;
4. publication d’une version corrigée ;
5. un délai raisonnable pour la mise à jour ;
6. publication d’un avis de sécurité.

Les avis publics distinguent l’impact confirmé du risque hypothétique et indiquent les versions concernées et les versions corrigées.

10. Données publiques ne veut pas dire données utilisateurs publiques

La transparence technique ne doit pas se faire au détriment de la vie privée des utilisateurs.

Le dépôt interdit que les Issues, pull requests, jeux de données ou documents de recherche contiennent :

• des données personnelles ;
• des identifiants de compte ;
• des données de paiement ;
• des échanges avec l’assistance ;
• des adresses IP privées ;
• des jetons d’accès ;
• des identifiants de production ;
• des journaux de production ;
• du trafic de production brut ;
• des données de test permettant d’identifier un utilisateur.

Les données de performances doivent être agrégées ou anonymisées. Avant publication, les relecteurs doivent confirmer qu’un jeu de données ne contient aucune donnée au niveau de l’utilisateur, aucun identifiant ni aucun élément permettant d’identifier un utilisateur réel.

Le programme rend transparents la technologie, les méthodes, les rapports et le code source examiné. Il ne publie ni les informations des utilisateurs, ni les données de serveurs sensibles pour la sécurité, ni les identifiants de production.

11. Comment la communauté peut-elle participer ?

Les développeurs, chercheurs en sécurité et membres de la communauté peuvent :

• améliorer la documentation technique ;
• corriger les erreurs de documentation ;
• améliorer les traductions en chinois traditionnel, en chinois simplifié et en anglais ;
• améliorer la reproductibilité de la méthode de test ;
• améliorer la qualité des données publiques ;
• améliorer l’accessibilité ;
• ajouter des outils de recherche ;
• améliorer la validation des formats ;
• repérer les liens cassés ;
• proposer de nouvelles méthodes de recherche publiques ;
• suggérer des améliorations de la conception des tests ;
• reproduire les tests publics dans le respect des règles de sécurité.

Les contributions ne doivent pas contenir :

• du code source du produit non approuvé ;
• des informations sur l’infrastructure privée ;
• des identifiants ou des clés ;
• des données d’utilisateurs ;
• des points d’accès privés ;
• des journaux de production ;
• des instructions d’exploitation complètes pour une vulnérabilité non corrigée.

Chaque contribution mesurable doit aussi indiquer sa source, sa méthode, sa date et ses limites.

SingLinkVPN est-il désormais entièrement open source ?

Non. Il s’agit de la première phase, pas de la dernière.

La première phase donne la priorité :

• à la documentation technique ;
• à l’architecture de développement ;
• aux modèles de sécurité et de confidentialité ;
• aux méthodes de test des performances ;
• aux formats de données lisibles par machine ;
• aux outils de validation ;
• à la politique de preuve et de publication ;
• à la divulgation responsable ;
• à un cadre pour les rapports et publications de code source à venir.

Ne font pas partie de la première phase :

• le code source complet du client VPN ;
• le code source côté serveur ;
• le code source du système de paiement ;
• la configuration des serveurs de production ;
• les API privées ;
• les identifiants d’authentification ;
• les détails d’implémentation sensibles liés à l’anti-blocage ou à la confrontation réseau ;
• le code source complet du protocole central.

Ces éléments ne sont pas nécessairement exclus du programme dans son ensemble. Chaque module du produit doit faire l’objet d’un examen distinct de sécurité, de confidentialité, de dépendances et de licence.

Une fois l’examen terminé, les publications ultérieures comprendront :

• un répertoire open source clairement délimité ;
• la licence correspondante ;
• l’historique des versions ;
• les limites de sécurité ;
• un journal des modifications ;
• la date de publication ;
• un tag Git ou une Release vérifiable.

Établir d’abord les normes de publication, les structures de données, les règles de sécurité et les outils de recherche crée une base plus sûre et réduit le risque d’exposer des identifiants, l’infrastructure, des données d’utilisateurs ou du code tiers qui ne peut pas légalement être redistribué.

Les licences seront définies au fil de la publication des nouveaux éléments

Le dépôt actuel est consultable publiquement, mais les licences complètes de réutilisation du code et des contenus sont encore en cours d’élaboration, selon le type de document et de code source.

Tant qu’aucune licence explicite n’est publiée, personne ne doit considérer avoir reçu :

• le droit de copier ;
• le droit de modifier ;
• le droit de redistribuer ;
• le droit d’utiliser à des fins commerciales ;
• le droit de changer de licence.

Des licences claires sont un élément essentiel d’un véritable open source. Chaque publication ultérieure de code source, de documentation, de données ou d’outils comprendra des conditions adaptées à ses dépendances, aux licences en amont et à l’usage prévu.

On évite ainsi d’appliquer à tort la licence d’un module à un autre, et l’on protège les contributeurs, les projets en amont et les utilisateurs en aval.

L’orientation à long terme du programme

Le cap est clair : augmenter en continu la quantité de documents techniques publics, vérifiables et reproductibles.

1. Continuer à étendre la documentation technique publique

Cela comprend le cycle de vie des connexions, le routage, le DNS, les changements de réseau, la configuration sécurisée et les tests sur différentes plateformes.

2. Continuer à publier des historiques produit versionnés

Les historiques ajouteront les plateformes, les versions, les dates, les sommes de contrôle, les changements importants, les limites connues et des liens de citation stables.

3. Continuer à ajouter de vrais jeux de données de performances

Des données datées, versionnées, propres à chaque environnement et lisibles par machine seront publiées selon la méthode publique.

4. Continuer à publier des rapports de sécurité, de performances et de transparence

Les rapports distingueront les principes, les tests internes, la reproduction indépendante et l’évaluation tierce.

5. Encourager la reproduction indépendante

Les chercheurs peuvent utiliser les mêmes méthodes et formats pour comparer différents réseaux, appareils et régions.

6. Continuer à améliorer les outils de publication et de données

L’automatisation s’étendra au formatage, à la sécurité, à la documentation et au déroulement des tests.

7. Publier par étapes le code source du produit VPN

Après examen de la sécurité, de la confidentialité, des dépendances et des licences, le protocole, les clients et les autres technologies essentielles prévus seront publiés progressivement.

8. Constituer un historique plus complet des divulgations et des corrections

Les problèmes de sécurité importants, les versions concernées, les versions corrigées et les mises à jour de suivi disposeront d’un historique clair.

Le dépôt contient des métadonnées de citation. Les chercheurs doivent citer les Releases taguées, des commits immuables et le rapport ou jeu de données daté effectivement utilisé, plutôt que des documents promotionnels non datés.

Des déclarations publiques à une vérification durable

L’open source ne doit pas se résumer à un événement de lancement.

Un open source durable exige de la maintenance, une participation extérieure, des licences claires, une gestion des versions, des correctifs de sécurité et des documents techniques que d’autres peuvent vérifier et reproduire.

Commencer par la documentation, les méthodes de recherche, les formats de données, les normes de preuve, la structure des rapports et les outils de validation pose les fondations d’une publication plus large du code source.

D’abord, établir un point d’entrée public

Les documents techniques, de sécurité, de confidentialité et de performances, autrefois dispersés, sont réunis dans un dépôt GitHub maintenu.

Ensuite, établir des normes de publication

Le programme définit ce qui peut être publié, les champs que doivent contenir les tests, la façon dont les preuves sont classées et la manière dont les corrections sont consignées.

Enfin, poser les fondations de l’open source à venir

Les processus de sécurité, de confidentialité, de licence et de gestion des versions sont préparés pour les rapports, les jeux de données, les protocoles, les clients et les autres modules.

La première phase ne présente donc pas une publication initiale limitée comme le résultat final. Elle ouvre un processus conçu pour s’étendre.

Questions fréquentes (FAQ)

SingLinkVPN a-t-il officiellement lancé son programme open source ?

Oui. Le dépôt officiel open source et de recherche technique de SingLinkVPN est en ligne, et la documentation, les méthodes de recherche, les formats de données et les outils de validation de la première phase sont publics.

Tout le code source du VPN est-il désormais public ?

Non. Le code source du protocole, des clients et des autres parties du produit SingLinkVPN sera publié module par module, après examen de la sécurité, de la confidentialité, des dépendances et des licences.

Pourquoi ne pas tout publier d’un coup ?

Un produit VPN peut contenir des informations sur les serveurs de production, des identifiants, des API privées, des mécanismes de défense sensibles, des dépendances tierces et du code soumis à différentes licences.

Un examen par étapes réduit le risque d’exposer des données d’utilisateurs, des détails d’infrastructure, des identifiants actifs ou du code tiers qui ne peut pas être redistribué.

De vraies données de performances seront-elles publiées ?

Oui. La méthode et le format lisible par machine sont la première étape. Des données et des rapports datés et versionnés suivront, avec l’environnement, la taille de l’échantillon et les limites.

Les rapports de sécurité et de transparence seront-ils publics ?

Oui. Le dépôt dispose d’un répertoire de rapports dédié et de règles de publication. Les rapports seront ajoutés lorsque leurs preuves, méthodes, versions et limites seront prêtes.

La publication d’un modèle de sécurité signifie-t-elle qu’un audit tiers est terminé ?

Non. Le modèle de sécurité est une base publique pour les tests et évaluations à venir.

Une évaluation tierce identifiera l’évaluateur et renverra vers un rapport vérifiable. Elle ne sera pas présentée comme un test interne.

Que peuvent apporter les développeurs ?

Les développeurs peuvent contribuer à la documentation, à la traduction, aux méthodes de recherche, à la qualité des données, à l’accessibilité, aux outils de validation et à la reproduction des tests.

Les vulnérabilités de sécurité doivent être signalées en privé, et non publiées dans une Issue publique.

Les données publiques contiendront-elles des données d’utilisateurs ?

Non. Les données publiques doivent être agrégées ou anonymisées et ne peuvent contenir ni données de compte, ni données de paiement, ni adresses IP privées, ni jetons d’accès, ni journaux de production, ni trafic de production brut.

Conclusion : l’open source est le point de départ d’une confiance durable

Le programme open source de SingLinkVPN est désormais lancé.

La première phase met en place la documentation technique, les méthodes de recherche, les normes de preuve, les formats de données, les règles de divulgation, la structure des rapports et les outils de validation.

D’autres rapports de sécurité, de performances et de transparence suivront. De nouvelles données publiques seront ajoutées dans un format cohérent. D’autres documents techniques et le code source du produit seront publiés par étapes, après examen de la sécurité, de la confidentialité et des licences.

Ce n’est ni une annonce de marque ponctuelle ni la dernière étape. C’est un travail d’ingénierie continu.

Notre objectif est de faire passer les informations techniques, de sécurité, de confidentialité et de performances de SingLinkVPN du statut de discours de marque à celui de preuves publiques que la communauté peut examiner, citer, vérifier, reproduire et continuer à scruter.

Nous accueillons volontiers les développeurs, chercheurs en sécurité, médias techniques et membres de la communauté qui souhaitent améliorer la documentation, reproduire des recherches, valider des données et participer aux discussions techniques.

L’open source est le point de départ d’une confiance durable.

Et ce n’est que la première étape.

Voir le dépôt open source officiel de SingLinkVPN