GitHub: controllare i lettori dei commenti riservati
Il segnalatore può leggere una nota interna? Prima definisci i lettori. Il 2 ottobre GitHub ha annunciato commenti riservati negli avvisi di sicurezza.
Li vedono solo persone con write sul repository. Segnalatori e invitati senza quel permesso non li leggono né ricevono notifiche. Il diagramma propone un flusso, non mostra il prodotto.
La riservatezza segue i permessi attuali
Non è una nota visibile solo all'autore. I titolari attuali di write sono i lettori; perdere il permesso rimuove l'accesso. Controlla etichetta e gruppo separatamente.
L'ambito annunciato riguarda repository pubblici con segnalazioni private attive su Free, Pro, Team ed Enterprise Cloud. Non suggeriamo più permessi. Note interne e spiegazioni esterne hanno scopi distinti.
Il tipo non cambia dopo l'invio
Un commento pubblicato non si può convertire fra normale e riservato. Controlla lettori, contenuto e selezione prima di inviare. Separa ipotesi e fatti verificati nelle bozze.
Rivedi internamente incarichi e ipotesi; comunica risultati riprodotti al segnalatore. È una proposta operativa, non un modulo imposto. Niente segreti reali nei test.
Assenza nell'API non significa assenza nel registro
GitHub offre questi commenti in GraphQL, non REST. Un archivio REST non è automaticamente completo. Registra percorso di raccolta e permessi del lettore.
Le letture sono nell'audit log, diverso dalla conservazione del testo. Esportazione e ricerca devono indicare API, lettori e copertura non verificata.
Verificare con testo innocuo
Progetta un controllo su un avviso del team con frasi non sensibili. Il responsabile verifica oggetto, account e permessi prima. Confronta tipo visibile e raccolta, poi documenta.
Gli spazi interni possono lasciare collaboratori senza informazioni. Continua a comunicare avanzamento e risultati. Verifichiamo funzionalità, permessi e API senza inventare guadagni di sicurezza o rapidità.