LINUX.ORG.RU

Репозиторий с правами коллективной публикации коммитов через подпись

 , ,


0

1

В ходе неспешной разработки vcs пришла в голову такая идея, но я не уверен что она полезная, вот хочу узнать чьё-нить мнение.

Введение (это не вопрос ещё):

В репе есть разные модели хранения, одна из них - «публикация официальных ревизий» (то есть линейный пронумерованный список релизных/одобренных версий продукта). Очевидно, в целях надёжности эти релизы (включая факт публикации под указанным номером ревизии и, на всякий случай, ссылку на подпись предыдущей) должны быть подписаны владельцем репы или ещё каким ответственным лицом. Эта подпись, кроме защиты от подмены репы путём взлома сервера, её раздающего, так же позволяет зеркалировать репу куда угодно в ненадёжные места, при этом ничем, кроме как запозданием доставки нового релиза, это не будет грозить.

Теперь собственно вопрос. А что, если:

1) право публикации привязать не к одному ключу владельца, а к набору ключей ответственного за публикацию коллектива, и для валидной публикации требовать наличие подписей всех участников, либо какого-то порогового процента их количества

2) список ответственных подписей версионировать, то есть в ревизии номер 137 будет информация о том, как именно должна быть подписана ревизия номер 138

3) для смены информации о правах публикации (список участников и правила подсчёта достаточных голосов) всё та же процедура с подписями, но, возможно, более высокое их пороговое количество, или обязательное наличие среди списка подписей подписи «председателя» (которую, вероятно, тоже можно сменить); при этом так же возможна процедура одностороннего отзыва своего членства - такую ревизию достаточно подписать только одной подписью - того человека, который самоустраняется (хотя тут проблема - это может спровоцировать недопустимое ветвление, возможно нельзя одной и должны одобрить остальные)

На мой взгляд, выглядит красиво, криптографически обеспеченная преемственность, но есть ли тут полезные применения?

С одной стороны, видится полностью отвязанная от физического хранилища сущность, добавление информации в которую делается не на основании доступа к конкретному серверу, а на основании криптографического разрешения. С другой, на практике скорее всего всё равно получится некий сервер с урлом, который люди будут воспринимать как первоисточник, и на котором никто не помешает написать что-то типа «ой, у нас проблемы, старые ключи отменяются, новые такие». Ну или другим способом сделать «хард форк». Даже более того, в этом может возникнуть нужда: какие-нить диверсанты могут в результате многолетней секретной операции по внедрению получить достаточный для принятия любых решений комплект подписей, и испортить проект - не хоронить же его после этого? Ну или просто тупо украсть или отнять ключи у настоящих участников, что может теоретически случиться даже весьма быстро. Или текущие участники могут забить или пропасть без вести.

Что думаете?

Перемещено dataman из security

★★★★★

1, 2, 3 по идее можно сделать через смарт контракты блохчейн (там аналогично сделаны multisig wallet) и получить тру неизменяемость. Но ты наверное это все хейтишь)

Но зачем все это? Прям чтоб изменения ревьювили по нескольку человек? Ну не знаю, насколько это реально.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Вопрос не «через что сделать», вопрос насколько это нужно. (а вообще смысла привязываться к каким-то внешним сервисам я не вижу, а вот вред вижу)

Не просто чтобы ревьюили (такое и так бывает по-моему), а чтобы факт положительного отзыва был криптографически подтверждён. А ещё случае, когда говорят про ревью, оно обычно так или иначе не совсем обязательно и есть административные способы внести правку в обход этих процедур, а потребители кода не обладают ни компетенцией, ни инструментами чтобы всё это проверить. А ещё запись о пройденном ревью, если она не подписана подписью того, кто это ревью провёл, может быть тоже подделана через неправомерный доступ к базе.

firkax ★★★★★
() автор топика
Ответ на: комментарий от cobold

Проблему компрометации ответственного кода через всего лишь одну найденную точку компрометации. Я даже про свой собственный код иногда подумывал что хорошо бы его перепроверять и вот так одобрять с независимых устройств перед выносом в прод - чтобы в случае компрометации одного из них туда не могло попасть что-то плохое. Но для моего случая систему можно сделать заметно проще. А тут я обобщил на более глобальную разработку.

firkax ★★★★★
() автор топика
Ответ на: комментарий от cobold

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

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

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

А ты один чтоль разработку ведёшь? Просто если не один, то вопрос решается через code review. Даже если я что-то кривое запушил в ветку из-за того что мое устройство скомпрометировано, то ревьювер должен это заметить. В теории. То что ты описываешь как раз и похоже на процедуру code review с несколькими ревьюверами

cobold ★★★★★
()
Ответ на: комментарий от goingUp

1, 2, 3 по идее можно сделать через смарт контракты блохчейн (там аналогично сделаны multisig wallet)

для 1 никакой блокчейн не нужен, и вообще ничего не нужно. Сумма подписей Шнорра равна подписи Шнорра суммой секретных ключей. Организуем всем ответственным такие ключи и просим их подписать коммит независимо друг от друга, после чего сливаем их подписи в одну.

К подходящим алгоритмам относится например ed25519. Как подписать коммит с помощью ed25519 - задача для самостоятельного изучения.

И да, мультисиг кошельки в блокчейне именно так и устроены. Ради этого в битке например даже алгоритм подписей меняли пару лет назад.

Вариант, когда могут подписать не все, называется «пороговая подпись» или «threshold signature». Для этого нужно дополнительно применить например схему разделения секрета Шамира.

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)
Ответ на: комментарий от cobold

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

firkax ★★★★★
() автор топика
Ответ на: комментарий от Lrrr

Мне кажется что с мультиподписями всё проще - в репе должны храниться все подписи по отдельности, а их проверка может быть сделана и на стороне клиента, желающего из репы что-то скачать. И никакая специальная математика тут не потребуется, годится любой алгоритм подписи.

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

firkax ★★★★★
() автор топика
  1. список ответственных подписей версионировать, то есть в ревизии номер 137 будет информация о том, как именно должна быть подписана ревизия номер 138

А не попутана ли тут причина со следствием? Логичнее было бы в ревизии 138 подтверждать ревизию 137 - если есть подозрение на малварь или некомпетентных мантайнеров - красный варнинг на весь терминал.

ALiEN175
()

Этих «дистрибутед-блохчейин-vcs» c мультисигами как говна за баней. Ни одна не взлетела. От распиздяйства, срачей, разбродов и шатаний математическая доказуемость не спасает. А вот похожее на твою схему уже давно применяется в некоторых документооборотах на пермиссивных блокчейнах.

bdrbt
()

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

и всё равно мерджи в мастер должен просматривать кто-то ответственный за мастер-ветку.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

я не интересовалась, как там это реализовано, но можно посмотреть. наверняка через ключи.

Очевидно, нет, просто одобрение записывается в базу, а потом показывается остальным в веб-интерфейсе. Ничего другого в вебе быть не может.

и всё равно мерджи в мастер должен просматривать кто-то ответственный за мастер-ветку.

Речь про коллективную ответственность и избавление от центра.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 4)
Ответ на: комментарий от firkax

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

но всё равно кто-то должен проверять, что, например, набрано нужное количество подписей. то есть, у тебя всё равно получится сервер.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Я нигде не спрашивал «как мне это реализовать». Как реализовать я могу и сам разобраться. Тема про другое, прочти нормально.

логинится

Отмечу только что логины в данной схеме не предусмотрены.

но всё равно кто-то должен проверять, что, например, набрано нужное количество подписей

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

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

ну тогда ты излагай свой бэкграунд в теме, а не где-то в середине обсуждения.

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

ну тогда ты излагай свой бэкграунд в теме

Я там всё написал, просто кто-то не прочёл до конца.

то в один прекрасный день репа просто исчезнет без следа.

Распределённые репы исчезают только тогда, когда не осталось никого кто бы в них участвовал или хотя бы пользовался.

и да, как вообще клиент сможет определить, что это именно та самая репа, а не какая-то другая, например.

По подписям.

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

Нет, это какие-то твои выдумки. Всё подписано авторитетными подписями, других критериев истинности репы или её публикаций нет. Собственно, пофиг на репу, важна подпись публикации, в которой указано «это ревизия номер 123 в репе mycoolprog, созданная в такой-то момент времени, имеющая такой-то хэш файлового дерева, идущая после ревизии 122 с таким-то хэшом метаданных» и подпись именно тем ключом, публичная часть которого у тебя хранится в качестве метаданных репы (вместе со словом mycoolprog). То есть если ты встречаешь подписанную именно этим ключом публикацию с именно этим именем - то это публикация именно той репы, вне зависимости от того, откуда она была скачана.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

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

ещё и «авторитетность» сюда приплёл. как ты определяешь «авторитетов»? «а я милого узнаю по походке»? :)

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от firkax

проще говоря, мне никто не мешает создать репу с таким же именем, нагенерить от балды ключей, наподписывать ими что попало и опубликовать публичные ключи для «проверки». и чем моя фейковая репа будет отличаться от твоей тру-репы для юзера, который пришёл со стороны и пытается понять, какую лепёшку надо брать.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

какие подписи вообще надо проверять

Подписи ты узнаешь оттуда, откуда узнаёшь о существовании репы и том, что она тебе нужна. Они - неотъемлемая её часть. Просто «имя репы» без подписей смысла не имеет. Этот вопрос лежит вне темы безопасного её сопровождения.

приплёл. как ты определяешь «авторитетов»?

Авторитетная подпись это та, которая указана в конфиге твоего клиента к ней.

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

и сразу попутный вопрос: а как форкать такую репу? имя, подписи и всё прочее потащатся вместе с репой. как потом отличить разные форки?

если форкать нельзя, то это не свободное ПО, например.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Забудь про имя репы, оно вторично. Первичен ключ, идентификация по нему. Имя чтобы отличить разные репы общих авторов между собой и не более того. В упрощённом виде имя можно вообще выкинуть из схемы, только надо потребовать чтобы один автор не использовал один и тот же ключ для своих разных реп.

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Подписи ты узнаешь оттуда, откуда узнаёшь о существовании репы и том, что она тебе нужна. Они - неотъемлемая её часть. Просто «имя репы» без подписей смысла не имеет. Этот вопрос лежит вне темы безопасного её сопровождения.

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

Авторитетная подпись это та, которая указана в конфиге твоего клиента к ней.

а если у меня нет никакого клиента? вот я новый юзер. нет у меня клиента к репе. я вижу 150 клонов, которые нагенерили боты. который из них брать?

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

firkax ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

Что значит новый юзер? С чего этот юзер решил что ему нужна эта репа вообще? Он, очевидно, откуда-то про неё узнал. И вот там, где он про неё узнал, ему должны были сообщить её публичные ключи - они являются неотъемлемой частью её адреса. Видела когда-нить доменные адреса в торе или i2p? Вот там тоже в адрес зашит ключ. «Просто имён» нет, есть криптографический идентификатор.

firkax ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

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

эти вопросы решаются с помощью инфраструктуры открытых ключей, PKI, которая уже реализована для GPG и X509, и может быть реализована для SSH.

Lrrr ★★★★★
()
Ответ на: комментарий от firkax

Что значит новый юзер? С чего этот юзер решил что ему нужна эта репа вообще? Он, очевидно, откуда-то про неё узнал.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Lrrr

инфраструктура открытых ключей где-то должна лежать. кто будет аутентифицировать эти самые ключи? кто скажет, что вот этот конкретный ключ принадлежит Васе Пупкину, известному разработчику.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

аутентификация ключей строится путем построения цепочки доверия до известного корневого сертификата. Который обычно уже есть у тебя в системе в составе пакета ca-certificates.

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

ну вот. то есть, вся распределённость всё равно сводится к системе CA и сертифицирующих серверов. это я и хотела услышать.

просто видимость каких-то альтернатив CA - это фикция. и зачем тогда городить огороды, если всё равно в итоге всё сводится туда же, к сертификатам от CA, которые прописаны у всех в ca-certificates. получается лишний наворот, но он по сути ничего не меняет.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Нет, знакомства с разработкой не требуются. Эти самые «третьи лица», от которых ты услышал про репу, сообщат тебе что эта репа, например, называется Bwe5eMP3n4HQ0OR_l-6FOrIFJiuxibMHcH2GHH35cdnCLpeME8v0rdyQdd3kLWW3v1xgv8DeAiHW2NL4A_IStCtS4R9H3ZAn46uOR6eP9huC0hry3hIR5tnbfbJ1EShmRjdUlQaPsXwaviBoa65Gw0f6rlvYZb-k37xtr86oeSw/mycoolprog, и по этому названию ты однозначно будешь знать, какие у неё ключи. Так же они тебе могут заодно сообщить, что одно из её зеркал расположено по адресу http://softs.freehosting.co.cc/coolprog и тогда ты сможешь скачать её с этого адреса (но клиент обязательно спросит у тебя проверку полного названия которое выше), а могут и не сообщить - тогда ты сможешь поискать зеркала поисковиком и скачать с первого попавшегося (опять же, с проверкой полного идентификатора).

а если юзеры репе не нужны, ну это какой-то закрытый клуб по интересам с фейсконтролем по ключам. зачем она тогда вообще?

Это на ответ выше не влияет, но вообще-то это не юзеры нужны репе, а репа юзерам. Репе ничего не нужно, она не живая.

firkax ★★★★★
() автор топика

я гуглю что такое коммит оно мне выдает: В системах контроля версий фиксация — это операция, которая отправляет последние изменения исходного кода в репозиторий, делая эти изменения частью главной ревизии репозитория. В отличие от коммитов в управлении данными, коммиты в системах контроля версий хранятся в репозитории неограниченное время.

pwp888
()
Ответ на: комментарий от firkax

третьи лица»

Третьи лица мне показали на поддельный репозиторий. Что дальше?

по этому названию ты однозначно будешь знать, какие у неё ключи

Откуда я буду это знать?

Siborgium ★★★★★
()
Ответ на: комментарий от pwp888

коммит в git - это объект в хранилище объектов, в котором записаны хэш рабочего дерева, сопровождающее сообщение, хэши родительских коммитов, имя и емейл коммитера, и все это может быть подписано ЭЦП.

Lrrr ★★★★★
()
Ответ на: комментарий от Siborgium

Да что ж такое, почему вместо обсуждения собственно темы приходится объяснять всякие банальности про криптографическую идентификацию? Неужели на лоре всё так плохо с этим?

Третьи лица мне показали на поддельный репозиторий. Что дальше?

Нет такого понятия как «поддельный репозиторий». Есть репозиторий, соответствующий некоему публичному ключу, и в нём публикуются релизы владельцем приватной части этого ключа. У репозиториев, созданных другими лицами, будут другие ключи, перепутать их невозможно. Из разговора с кем-то ты узнал ключ репы, которую он тебе посоветовал. Очевидно, это именно тот ключ, который тебе сообщили (если ты только не сделаешь опечатку при его вводе). Что в нём может быть поддельного?

Откуда я буду это знать?

Потому что публичный ключ это часть названия. Вот ты видишь название из нескольких сотен знаков, похожих на base64, неужели даже это не намекнуло?

firkax ★★★★★
() автор топика