@drakenclimber Я предлагаю краткую схему документа MAINTAINER_PROCESS.md, который мы можем обсудить / отредактировать, но я все еще пытаюсь завершить выпуск v2.4.0 прямо сейчас, и мне, вероятно, понадобится несколько дней, чтобы склонны к нескольким другим не связанным и забытым вопросам :)

@pcmoore - Не беспокойтесь. Кстати, хорошая работа над выпуском v2.4! Сообщите мне, чем я могу помочь.

Не стесняйтесь использовать меня в качестве подопытного кролика, пока мы наладим процесс :)

Кстати, хорошая работа над выпуском v2.4! Сообщите мне, чем я могу помочь.

На этом этапе полезно любое тестирование, которое вы можете сделать. Я довольно хорошо отношусь к качеству этого выпуска, но многие хитрые моменты были изменены, поэтому вполне разумно представить, что какой-то угловой случай сломался в каком-то приложении. Я надеюсь, что нам не придется выпускать «коричневый мешок» v2.4.1, но мало ли.

Не стесняйтесь использовать меня в качестве подопытного кролика, пока мы наладим процесс :)

Рад слышать , что вы говорите , что вы еще потому свинки;)

@drakenclimber Я зарезервировал этот комментарий для черновика документа MAINTAINER_PROCESS.md (полагаю, я могу продолжать редактировать его здесь на основе отзывов). Не стесняйтесь присылать любые идеи, которые у вас есть в этом выпуске, и я составлю PR для этого, как только мы что-нибудь приблизим.

Процесс обслуживания libseccomp

https://github.com/seccomp/libseccomp

В этом документе делается попытка описать процессы, которым должны следовать различные сопровождающие libseccomp. Он не задуман как жесткое требование, а скорее как руководящий документ, призванный упростить управление проектом libseccomp нескольким соавторам.

Мы понимаем, что этот документ, как и все другие части проекта libseccomp, несовершенен. Если необходимо внести изменения, они должны быть внесены в соответствии с указаниями, описанными здесь.

Просмотр и объединение патчей

В идеальном мире каждый патч будет независимо рассмотрен и подтвержден каждым сопровождающим, но мы понимаем, что это вряд ли будет практично для каждого патча. При нормальных обстоятельствах каждый патч должен быть подтвержден простым большинством сопровождающих (в случае четного числа сопровождающих - N / 2 + 1) перед объединением в репозиторий. Сопровождающие должны ACK патчи, используя формат, аналогичный ядру Linux, например:

Acked-by: John Smith <[email protected]>

Сопровождающий, который слил патч в репозиторий, должен добавить свою подписку, убедившись, что это правильно (см. Документацию по отправке патчей); если сопровождающий неправильно добавляет свою подписку, скорее всего, их патч не следует объединять. Сопровождающий должен добавить свое подтверждение в стандартном формате в конце метаданных патча, например:

Signed-off-by: Jane Smith <[email protected])

Сопровождающим рекомендуется общаться друг с другом по многим причинам, одна из которых - позволить другим, когда один из них будет недоступен в течение длительного периода времени. Если патч задерживается из-за отсутствия ACK, а другие сопровождающие не отвечают по прошествии разумного периода времени (например, задержка более двух недель), пока нет ожидающих NACK, патч можно объединить. без простого большинства.

Управление конфиденциальными отчетами об уязвимостях

Процесс сообщения об уязвимостях libseccomp задокументирован в документе SECURITY.md.

Сопровождающие должны работать вместе с докладчиком, чтобы оценить достоверность и серьезность сообщенной уязвимости. По возможности следует придерживаться ответственной практики отчетности и установки исправлений, включая уведомление в списках рассылки _linux-distros_ и _oss-security_.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

Управление трекером проблем GitHub

Мы используем трекер проблем GitHub для отслеживания ошибок, запросов функций, а иногда и вопросов без ответа. Приведенные здесь условные обозначения призваны помочь различать разные виды использования и расставлять приоритеты в рамках этих категорий.

Запросы функций ДОЛЖНЫ иметь префикс «RFE:», добавленный к имени проблемы, и использовать метку «улучшение». Отчеты об ошибках ДОЛЖНЫ быть добавлены к названию проблемы с префиксом «BUG:» и с пометкой «ошибка».

Задачи ДОЛЖНЫ быть приоритизированы с использованием меток «приоритет / высокий», «приоритет / средний» и «приоритет / низкий». Надеюсь, значение должно быть очевидным.

Проблемы МОГУТ быть дополнительно помечены метками «ожидающие / информация», «ожидающие / проверяемые» и «ожидающие / исправленные», чтобы указать, что требуется дополнительная информация, проблема / исправление ожидает проверки и / или исправление требует изменений.

Управление этапами выпуска GitHub

В любой момент времени должно быть как минимум две вехи GitHub: одна для следующего основного / второстепенного выпуска (например, v2.5) и одна для следующего выпуска патча (например, v2.4.2). По мере того, как проблемы вводятся в систему, они могут быть добавлены к вехам по усмотрению специалистов по сопровождению.

Управление общедоступным списком рассылки

Список рассылки в настоящее время размещен в группах Google, и хотя можно участвовать в обсуждениях без учетной записи Google, учетная запись Google требуется для модерации / администрирования группы. Те сопровождающие, у которых есть учетная запись Google и желают быть добавленными в список модераторов, должны быть добавлены, но в этом нет необходимости.

Несмотря на термин «модератор», список в настоящее время не модерируется и должен оставаться прежним.

Выпуски новых проектов

Процесс выпуска libseccomp задокументирован в документе RELEASE_PROCESS.md.

В идеале, я думаю, было бы неплохо получать ACK от каждого сопровождающего для каждого патча / PR, но я не уверен, что это будет слишком много препятствий? Мне кажется, что патчи / PR libseccomp имеют достаточно низкий объем, поэтому это не должно быть серьезной проблемой, но мне любопытно, что вы думаете

Согласовано. Я думаю, что было бы хорошо стремиться к ACK для каждого патча, но мы можем оставить гибкость открытой, чтобы обойти это для действительно простых патчей или других смягчающих обстоятельств (длительные отпуска и т. Д.). Очевидно, что обход других ACK должен быть исключением, а не нормой.

Независимо от вышесказанного, я считаю, что исправления от любого сопровождающего должны быть подтверждены ACK и переданы другим сопровождающим.

Это определенно будет хорошей привычкой. Это должно помочь избежать глупых ошибок.

Нам также необходимо задокументировать, как обрабатывать объединение PR и патчей, например, выход из системы сопровождающего, выполнение этого вручную, без использования инструментов GitHub и т. Д.

Мне было бы интересно увидеть процесс, который вы рекомендуете. Есть ли причина, по которой мы должны избегать встроенных инструментов github?

Я думаю, что ключевым моментом здесь является перечисление всех сопровождающих в соответствующем разделе README.md и упоминание о том, что сопровождающие должны работать вместе, чтобы решить проблему и следовать соответствующим процессам ответственного раскрытия информации. Мы должны включить ссылки на списки linux-distros и oss-security.

Да, очень важно предоставить другим пользователям простой и безопасный способ сообщить о проблемах. Я согласен.

Согласовано. Я думаю, что было бы хорошо стремиться к ACK для каждого патча, но мы можем оставить гибкость открытой, чтобы обойти это для действительно простых патчей или других смягчающих обстоятельств (длительные отпуска и т. Д.). Очевидно, что обход других ACK должен быть исключением, а не нормой.

Хорошие моменты, согласен.

Нам также необходимо задокументировать, как обрабатывать объединение PR и патчей, например, выход из системы сопровождающего, выполнение этого вручную, без использования инструментов GitHub и т. Д.

Мне было бы интересно увидеть процесс, который вы рекомендуете. Есть ли причина, по которой мы должны избегать встроенных инструментов github?

Мне очень нравится идея, что каждый, кто касается патча, либо создавая его, либо фиксируя его в основном репозитории, явно добавляет свое подтверждение в файл. Я также действительно думаю, что сопровождающие должны сделать make check в своей локальной системе, прежде чем помещать что-либо в основное репо. Слияние PR прямо из интерфейса GitHub на самом деле не позволяет делать ни то, ни другое.

Я полагаю, если бы объем PR когда-либо резко увеличился, мы могли бы пересмотреть это, но сейчас объем достаточно низкий, чтобы дополнительные ручные шаги, на мой взгляд, действительно не значительны.

Мнения @drakenclimber?

Я только что заглянул в список рассылки групп Google, и похоже, что я не могу использовать вашу учетную запись / адрес oracle.com в качестве учетной записи менеджера / модератора, это должна быть учетная запись Google. На данный момент я думаю, что решать вам, @drakenclimber; если вам нужен доступ менеджера / модератора, вам необходимо подписаться с учетной записью Google.

Стоит отметить, что в настоящее время я не модерирую список и не думаю, что он должен модерироваться. В настоящее время единственные сообщения, которые сразу не отправляются в список, - это то, что Google считает СПАМом.

Также ничего не стоит, что трафик в списке рассылки вне уведомлений о фиксации приближается к нулю, большая часть взаимодействия сейчас происходит на GitHub. Хотя я думаю, что мы должны сохранить список рассылки, пожалуйста, не думайте, что вам нужно быть менеджером / модератором списка, чтобы «разделить бремя», в этом случае нет «бремени».

Я полагаю, если бы объем PR когда-либо резко увеличился, мы могли бы пересмотреть это, но сейчас объем достаточно низкий, чтобы дополнительные ручные шаги, на мой взгляд, действительно не значительны. Мнения @drakenclimber?

Согласовано. Меня устраивает ручной шаг на этом этапе проекта. Фактически, это именно то, чем я занимаюсь уже некоторое время.

На данный момент я думаю, что решать вам, @drakenclimber; если вам нужен доступ менеджера / модератора, вам необходимо подписаться с учетной записью Google.

Хотя я думаю, что мы должны сохранить список рассылки, пожалуйста, не думайте, что вам нужно быть менеджером / модератором списка, чтобы «разделить бремя», в этом случае нет «бремени».

Имеет смысл. Вы можете добавить мой адрес Gmail, если вас это устраивает; Я не вижу недостатков, но позже это может пригодиться. tom dot хроматка в gmail.

Я только что заметил, что на вкладке «Безопасность» для проекта GitHub, похоже, особым образом обрабатывает файл SECURITY.md (см. Пример CONTRIBUTING.md). Мы должны рассмотреть возможность использования этого файла как части этого процесса.

Вкладка «Безопасность» также позволяет вам создать частный форк проекта, чтобы вы могли работать над исправлениями конфиденциально; это может быть большой победой, поскольку позволяет нам лучше сотрудничать над исправлениями безопасности, не делая проблему общедоступной до того, как исправление будет готово.

Это действительно крутая функция. Хорошая находка!

@drakenclimber Я только что обновил документ в комментарии выше, ознакомьтесь с ним и дайте мне знать, что вы думаете. Нам все еще нужно создать документ SECURITY.md, но это должно быть довольно быстро (всего несколько предложений); Я создам черновик, как только вы будете довольны основным документом, приведенным выше.

@drakenclimber Я только что подписал ваш адрес

Я только что подписал ваш адрес Gmail на группу Google и предоставил вам доступ менеджера / модератора, если он не работает, дайте мне знать.

Похоже, работает. Я смог войти в систему и перейти к настройкам списка рассылки. Спасибо!

Я только что обновил документ в комментарии выше, ознакомьтесь с ним и дайте мне знать, что вы думаете.

Мне кажется, это действительно хорошо.

@drakenclimber, вот черновик документа SECURITY.md, мысли?

Процесс обработки уязвимостей безопасности libseccomp

https://github.com/seccomp/libseccomp

В этом документе предпринята попытка описать процессы, посредством которых важные ошибки, связанные с безопасностью, могут быть ответственно сообщены проекту libseccomp, а также то, как сопровождающие проекта должны обрабатывать эти отчеты. Как и другие документы процесса libseccomp, этот документ следует рассматривать как руководящий документ, а не как жесткий, непреклонный набор правил; Отчеты об ошибках и сопровождающие проекта поощряются к совместной работе для решения проблем, насколько это возможно, и таким образом, который лучше всего подходит для всех вовлеченных сторон.

Сообщение о проблемах

Проблемы с библиотекой libseccomp, которые не подходят для немедленного публичного раскрытия, должны быть отправлены по электронной почте текущим сопровождающим libseccomp, список приведен ниже. Обычно мы запрашиваем не более 90 дней для решения проблемы, прежде чем она станет общедоступной, но мы приложим все усилия, чтобы решить проблему как можно быстрее и сократить период раскрытия информации.

• Пол Мур, [email protected]
• Том Хроматка, том. [email protected]

Решение важных проблем безопасности

При обнаружении ошибки сопровождающие должны работать вместе, чтобы исследовать проблему и принять решение. Чтобы предотвратить раннее обнаружение проблемы, тем, кто работает над решением, следует делать это в частном порядке и вне традиционных методов разработки libseccomp. Одним из возможных решений этой проблемы является использование функциональности GitHub «Security» для создания частной ветки разработки, которая может использоваться совместно с сопровождающими и, при необходимости, репортером. Может возникнуть проблема с заполнителем на GitHub, но детали должны оставаться крайне ограниченными до тех пор, пока проблема не будет исправлена ​​и раскрыт ответственно. Если проблеме был присвоен CVE или другой тег, заголовок проблемы GitHub должен включать тег уязвимости после того, как проблема будет обнаружена.

Публичное раскрытие

По возможности следует придерживаться ответственной практики отчетности и установки исправлений, включая уведомление в списках рассылки linux-distros и oss-security.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

способом, который лучше всего подходит для них.

придирка - я бы хотел изменить это на in a manner which works best for all parties involved.

Я думаю, что документ об уязвимостях безопасности выглядит действительно хорошо. Хорошая работа!

способом, который лучше всего подходит для них.

придирка - я бы хотел изменить это на in a manner which works best for all parties involved.

Мне это нравится, обновляю черновик сейчас.

Я думаю, что мы достаточно согласны с тем, что стоит составить PR с обновлениями документации / процесса, я сделаю это сейчас и опубликую ссылку здесь.

Ссылка PR (также включена в историю GH выше): https://github.com/seccomp/libseccomp/pull/158

Я думаю, что у вас все готово ,