Хорошо, что эта проблема «решена» для этого репозитория. Но настоящая проблема всё ещё существует. Как подписывать и какой источник ключа использовать для проверки подписи?
Поэтому моя первая попытка решения этой проблемы — использовать встроенный механизм подписи Git. Discourse тогда должен отслеживать подписанта установленного плагина. Если он изменится, система должна предупредить администратора.
Очевидно, что у этого подхода есть много недостатков.
Откуда брать ключи подписанта? Метаданные в plugin.rb и about.json. Серверы ключей — это хорошо… но довольно сложно. Или… meta.discourse.org выступает в роли сервера ключей, поэтому авторы должны регистрировать свои открытые ключи.
Проверять только самый последний коммит? Вероятно, этого достаточно, ведь с украденными ключами мало что можно сделать.
Но если ключ украден, как проверить его отзыв? Если meta предоставляет ключ, эту проблему можно решить.
Это отлично подходит для интерфейса администратора, но что насчёт установки плагинов в контейнере Docker? Сохранять ранее принятые ключи подписи в общем хранилище и добавить этап проверки при пересборке. Вероятно, предварительная проверка перед сборкой, чтобы не вывести систему из строя и отклонить клонирование; а затем проверка после checkout на случай, если кто-то вмешался в репозиторий?
А как быть со старыми неподписанными репозиториями? Большое предупреждение о том, что их содержимое нельзя проверить. + запрос с вариантами: да/нет/отмена
несёт ответственность. Владелец сервера должен убедиться, что какой-то сервер загружает нужный код. Будь то возложение вины на GitHub, вышестоящий уровень их домена верхнего уровня (например, .com) или дальнейшее перекладывание ответственности.
Но это должно облегчить мою работу как администратора. Я, как разработчик плагинов, хочу облегчить вашу работу.
В настоящее время процесс обновления требует абсолютного доверия к исходному URI. Это вызывает у меня беспокойство, поскольку было показано, что источник (GitHub) не всегда надежен, особенно на определенных этапах пересборки контейнера. Предупреждайте меня, как администратора, о любых изменениях в отношениях доверия.
Я, как администратор, проверял каждый плагин или компонент темы перед его добавлением. После этого Discourse предоставляет мне мало или вообще никаких подсказок для дальнейшей проверки. Сегодня мне пришлось пересобрать свой контейнер, что приведет к повторному клонированию всех плагинов. Я практически лишен контроля, если не внесу сложные изменения в настройку для фиксации конкретной версии.
Это может подойти мне как хорошо отдохнувшему разработчику программного обеспечения в момент, когда мне нужно провести обслуживание. Но это накладывает довольно серьезные ограничения. Помимо того, что Discourse является отличной платформой для дискуссий, нам также нужно сделать его технически безопасной платформой для дискуссий. Скомпрометированные плагины могут нанести серьезный ущерб. Скомпрометированные компоненты тем могут нанести значительный ущерб.
Я думаю, это имеет большой смысл. У нас есть SRI для JavaScript, MS Authenticode для Windows. Было много атак на цепочки поставок, например, на NPM и RubyGems.
Единственное, что меня беспокоит, — это то, что может возникнуть барьер для получения «одобрения» для плагинов или компонентов тем, как это делает Microsoft Smartscreen, предотвращая запуск малоизвестного программного обеспечения от отдельных разработчиков.