GitHub : vérifier les lecteurs d'un commentaire confidentiel
Le déclarant peut-il lire une note interne ? Identifiez d'abord les lecteurs. GitHub a annoncé le 2 octobre des commentaires confidentiels dans les avis de sécurité.
Seules les personnes disposant du droit write sur le dépôt les voient. Déclarants et invités sans ce droit ne les lisent pas et ne sont pas notifiés. Le schéma propose une procédure, pas une capture produit.

La confidentialité suit les droits actuels
Ce n'est pas une note réservée à son auteur. Les titulaires actuels de write sont les lecteurs ; perdre ce droit supprime l'accès. Vérifiez séparément le label et les personnes autorisées.
Le périmètre annoncé couvre les dépôts publics avec signalement privé activé, sur Free, Pro, Team et Enterprise Cloud. Nous ne proposons pas d'étendre les droits. Notes internes et explications externes ont des objectifs distincts.
Le type reste définitif
Impossible de convertir ensuite un commentaire ordinaire en confidentiel ou inversement. Vérifiez lecteurs, texte et choix avant l'envoi. Séparez hypothèses et faits confirmés dans les brouillons.
Examinez d'abord les responsables internes et hypothèses ; transmettez les résultats reproduits au déclarant. C'est une pratique proposée, pas un formulaire imposé. Aucun secret réel pour les tests.
Une absence API n'est pas une absence de trace
GitHub fournit ces commentaires par GraphQL, pas par REST. Une archive REST n'est donc pas nécessairement complète. Documentez collecte et droits du lecteur.
Les consultations figurent dans l'audit, qui n'est pas une copie du texte. Exports et recherches doivent préciser API, lecteurs et zones non vérifiées.
Valider avec un texte inoffensif
Concevez une vérification dans un avis appartenant à l'équipe avec des phrases non sensibles. Un responsable contrôle avis, compte et droits avant exécution. Comparez type visible et collecte puis documentez.
Des espaces internes peuvent aussi priver les collaborateurs d'information. Continuez à expliquer progrès et résultats aux déclarants. Nous vérifions fonctionnalité, droits et API sans inventer de gains de sécurité ou de rapidité.