Failles de sécurité

Nous prenons les failles de sécurité au sérieux. Si vous en avez trouvé une, la meilleure façon de la signaler est de créer un ticket confidentiel sur notre bug tracker. Assurez-vous de sélectionner « This issue is confidential and should only be visible to team members with at least Reporter access » (Ce problème est confidentiel et ne devrait être visible que par les membres de l’équipe ayant au moins un accès Reporter) lorsque vous créez le problème. Ensuite, nous nous mettrons au travail sur le problème signalé. Il se peut que nous vous contactions par l’intermédiaire du ticket si des informations supplémentaires sont nécessaires. Et nous déterminerons la divulgation.

Comment gérer un correctif de sécurité

Pour les membres du développement d’UBports, il s’agit des étapes recommandées pour résoudre le problème sans le divulguer au public avant que le correctif ne soit prêt :

  1. Étant donné un repo principal, s’assurer que le repo <projet>.secfix existe. Si ce n’est pas le cas, il faut faire un fork depuis le projet principal vers le même espace de noms, mais en mettant la visibilité à private.

Note

Le suffixe .secfix empêchera CI de toucher ce repo, évitant ainsi les fuites.

  1. S’il n’existe pas encore de problème, créez un problème confidentiel sur le projet principal.

  2. Sur le problème, utilisez « Créer une demande de fusion confidentielle ». Définissez le nom de la branche et la branche source de manière appropriée. Ensuite, poussez vers cette branche à partir de votre arbre Git local.

Note

Ce MR ciblera le repo .secfix, PAS le repo principal [1]. Cela permet de réviser le correctif en privé.

  1. Un autre développeur révise alors la demande de fusion et la fusionne. Si un rétro-portage est nécessaire, il doit aussi se faire dans la fourche .secfix.

Note

Comme nous ne disposons pas encore d’un système d’IC confidentiel, il incombe au développeur et au réviseur de s’assurer que le code se compile, passe les tests et est testé localement.

  1. Environ un jour avant la date de publication d’une version candidate, un développeur (généralement le responsable de la publication) fusionne toutes les branches du repo .secfix avec le repo principal. Après cela, le problème confidentiel est marqué comme non confidentiel. Cela rend le problème public pour la première fois.

Note

À ce stade, il incombe au développeur de s’assurer que le résultat de la fusion est effectivement accepté par l’IC et qu’au moins la fonctionnalité de base de ce composant n’est pas interrompue.

  1. Le responsable de la publication s’assurera que le correctif se trouve effectivement dans l’image quotidienne avant de choisir cette image comme RC.

  2. Avant la date de publication, le développeur du correctif préparera l’avis de sécurité, contenant (la liste est inspirée des avis de Curl [2]) :

  • Nom

  • Vulnérabilité (comment un utilisateur est vulnérable)

  • Info (comment la vulnérabilité existe)

  • Versions concernées

  • Solution

  • Recommandations

  • Chronologie

  • Crédit

  1. A la date de publication, l’avis de sécurité sera publié sur le forum, dans la section « OS > Security advisories ».