GitHub: проверьте читателей конфиденциального комментария
Видит ли заявитель внутреннюю заметку? Сначала определите аудиторию. 2 октября GitHub объявил конфиденциальные комментарии в уведомлениях безопасности.
Их читают только пользователи с write в репозитории. Заявители и приглашённые без этого права не видят текст и не получают уведомлений. Схема предлагает процесс, не показывает продукт.
Доступ следует текущим правам
Это не личная заметка автора. Читатели имеют write сейчас; потеря права убирает доступ. Проверяйте метку и состав группы отдельно.
Объявленный охват — публичные репозитории с приватными сообщениями об уязвимостях на Free, Pro, Team и Enterprise Cloud. Мы не предлагаем расширять права. Внутренние заметки и внешние объяснения служат разным целям.
Тип после отправки не меняется
Нельзя переключить опубликованный комментарий между обычным и конфиденциальным. Перед отправкой проверьте аудиторию, текст и выбор. Разделяйте гипотезы и подтверждённые факты в черновиках.
Сначала обсудите внутренних ответственных и гипотезы, заявителю сообщите проверенное воспроизведение. Это предложение, не обязательная форма. Не тестируйте настоящими секретами.
Отсутствие в API не означает отсутствие записи
Комментарии доступны через GraphQL, но не возвращаются REST. REST-архив не доказывает полноту истории. Запишите способ сбора и права читателя.
Просмотры фиксируются в audit log, что не заменяет хранение текста. Экспорт и поиск должны указывать API, аудиторию и непроверенный охват.
Проверяйте безобидным текстом
Спланируйте проверку на уведомлении команды с нечувствительными фразами. Ответственный проверяет объект, аккаунт и права заранее. Сопоставьте видимый тип и сбор, затем документируйте.
Внутренние пространства могут лишить коллег информации. Продолжайте объяснять заявителям ход работы и результаты. Проверены функция, права и API; улучшения безопасности или скорости не выдумываются.