http://git.altlinux.org/tasks/255033/logs/events.3.1.log pesign.git$ git diff p9..sisyphus -- src/daemon.h |grep PESIGND_VERSION -#define PESIGND_VERSION 0xa3cf41cb +#define PESIGND_VERSION 0x2a9edaf0
Это скорее к ldv@, чем к nickel@ -- экземпляр pesign в signery не подлежит автоматическому бесконтрольному обновлению, насколько понимаю.
(In reply to Michael Shigorin from comment #1) > Это скорее к ldv@, чем к nickel@ -- экземпляр pesign в signery не подлежит > автоматическому бесконтрольному обновлению, насколько понимаю. Тут другая проблема: клиенты во всех репозиториях, кроме Сизифа, совместимы с сервером, а в Сизифе после недавнего обновления не совместим.
Видимо, надо одновременно обновлять клиентов во всех репозиториях и на сервере. Ну или менять инфраструктуру так, что бы сервер был той же версии, как и клиент (в смысле - из одного репозитория). Дима, последнее возможно ?
(In reply to Anton Farygin from comment #3) > Видимо, надо одновременно обновлять клиентов во всех репозиториях Я не против, но мантейнеры репозиториев повышенной сертифицированности могут не разделять эту точку зрения. > и на сервере. > > Ну или менять инфраструктуру так, что бы сервер был той же версии, как и > клиент (в смысле - из одного репозитория). > > Дима, последнее возможно ? Зачем вообще используется клиент-сервер? Чтобы в hasher chroot, который формируется для подписи некоторых файлов в пакете, не попал ключ. Если сервер, работающий с ключом, будет автоматически формироваться из того же репозитория, что и клиент, это обесценит ту самую идею, из-за которой используется разделение на клиент и сервер.
Д(Ответ для Dmitry V. Levin на комментарий #4) > (In reply to Anton Farygin from comment #3) > > Видимо, надо одновременно обновлять клиентов во всех репозиториях > > Я не против, но мантейнеры репозиториев повышенной сертифицированности могут > не разделять эту точку зрения. Да, это их право, но у них может не оказаться другого выбора. > > > и на сервере. > > > > Ну или менять инфраструктуру так, что бы сервер был той же версии, как и > > клиент (в смысле - из одного репозитория). > > > > Дима, последнее возможно ? > > Зачем вообще используется клиент-сервер? Чтобы в hasher chroot, который > формируется для подписи некоторых файлов в пакете, не попал ключ. Если > сервер, работающий с ключом, будет автоматически формироваться из того же > репозитория, что и клиент, это обесценит ту самую идею, из-за которой > используется разделение на клиент и сервер. Да, я понимаю. В качестве объезда хочу предложить развернуть два сервера разных версий на переходный период. Конечно, можно дождаться выхода из отпуска ментейнера pesign, что бы он посмотрел - можно ли ослабить проверку на версии протоколов на стороне клиента. Но я бы, конечно. предпочёл решить этот вопрос на стороне серверов, подписывающих efi в сборочнице.
(Ответ для Anton Farygin на комментарий #5) > > > Видимо, надо одновременно обновлять клиентов во всех репозиториях > > Я не против, но мантейнеры репозиториев повышенной сертифицированности > > могут не разделять эту точку зрения. Насколько помню, pesign не входит в дистрибутивы (или легко убирается, не будучи нужен иначе как диагностический/исследовательский инструмент). Если бы у нас поддерживались пользовательские ключи секирбута по полной, это было бы иначе. > Да, это их право, но у них может не оказаться другого выбора. То есть твой сотрудник сломал pesign, а теперь у других "нет выбора", я всё правильно уловил? А выбор откатить pesign и не создавать коллегам аврала на ровном месте, обдумывая проблему своими силами и консультируясь с другими -- часом не рассматривали? Я много где мог жёстко поставить "нет выбора" по части той же сборки дистрибутивов -- но почему-то предпочёл так не делать, вместо такого подхода давая _возможность_, а не навязывая её, аки шпана глобалистская. > Конечно, можно дождаться выхода из отпуска ментейнера pesign Сломать и уйти в отпуск допустимо для молодого специалиста (к nickel@ у меня тут особых претензий нет) -- но, надеюсь, ты непременно поделишься с ним своим богатым опытом, чтоб мне меньше сожалеть о передаче pesign в твоё хозяйство.
Ну судя по сообщению Миши, данная проблема оптимально будет решаться поднятием двух разных версий pesign сервера на стороне сборочницы. Да, "ничего не делать" вариант не рассматриваем. Дима, если не сможешь поднять две версии pesign на сборочнице - напиши, я начну раскидывать по веткам новую версию.
Нынешний pesign в Сизифе с 16-го июня, т.е. уже больше месяца, так что это не аврал, а плановые работы. Поэтому прежде, чем что-либо предпринять, нужно дождаться мантейнера.
Насколько я понял из git blame, в b07f изменилась PESIGND_VERSION, потому что: 1) в daemon.c в структуру cmd_table_t добавлены два поля. 2) Добавлена команда get-cmd-version в pesignd_cmd. Не могу предсказать, что произойдёт, если разрешить использовать старого клиента с новым сервером и наоборот. Скорее всего, ничего хорошего - эти вещи не просто так сделаны несовместимыми. Кстати, в этом же коммите и ввели проверку на версию, которая в случае несовпадения завершает работу с подозрением на эксплоит.
(Ответ для Dmitry V. Levin на комментарий #8) > Нынешний pesign в Сизифе с 16-го июня, т.е. уже больше месяца, так что это > не аврал, а плановые работы. Поэтому прежде, чем что-либо предпринять, > нужно дождаться мантейнера. да, pesign у нас не часто используется, но когда он нужен - он обычно нужен "прямо срочно" ;) Так что скажешь по поводу того, что бы запустить две параллельных версии pesign в сборочнице ?
(In reply to Олег Соловьев from comment #9) > Насколько я понял из git blame, в b07f изменилась PESIGND_VERSION, потому > что: > 1) в daemon.c в структуру cmd_table_t добавлены два поля. > 2) Добавлена команда get-cmd-version в pesignd_cmd. > > Не могу предсказать, что произойдёт, если разрешить использовать старого > клиента с новым сервером и наоборот. > Скорее всего, ничего хорошего - эти вещи не просто так сделаны > несовместимыми. Новый клиент не заработает со старым сервером как минимум потому, что клиент теперь всегда использует новую команду, которую нет в старом сервере. > Кстати, в этом же коммите и ввели проверку на версию, которая в случае > несовпадения завершает работу с подозрением на эксплоит. Проверка на версию была и раньше.
(Ответ для Dmitry V. Levin на комментарий #11) > (In reply to Олег Соловьев from comment #9) > > Кстати, в этом же коммите и ввели проверку на версию, которая в случае > > несовпадения завершает работу с подозрением на эксплоит. > > Проверка на версию была и раньше. Признаю, перепутал.
(In reply to Anton Farygin from comment #10) > (Ответ для Dmitry V. Levin на комментарий #8) > > Нынешний pesign в Сизифе с 16-го июня, т.е. уже больше месяца, так что это > > не аврал, а плановые работы. Поэтому прежде, чем что-либо предпринять, > > нужно дождаться мантейнера. > > да, pesign у нас не часто используется, но когда он нужен - он обычно нужен > "прямо срочно" ;) Я бы понял, если бы в Сизифе сразу что-то сломалось, но что за срочность может быть в Сизифе месяц спустя? > Так что скажешь по поводу того, что бы запустить две параллельных версии > pesign в сборочнице ? Для этого, насколько я помню, следует клонировать контейнер, установить в клон другую версию сервера и мигрировать его хранилище ключей на эту версию. У меня в плане этих работ не было.
(Ответ для Dmitry V. Levin на комментарий #13) > (In reply to Anton Farygin from comment #10) > > (Ответ для Dmitry V. Levin на комментарий #8) > > > Нынешний pesign в Сизифе с 16-го июня, т.е. уже больше месяца, так что это > > > не аврал, а плановые работы. Поэтому прежде, чем что-либо предпринять, > > > нужно дождаться мантейнера. > > > > да, pesign у нас не часто используется, но когда он нужен - он обычно нужен > > "прямо срочно" ;) > > Я бы понял, если бы в Сизифе сразу что-то сломалось, но что за срочность > может быть в Сизифе месяц спустя? Нам нужна поддержка btrfs subvol в дистрибутиве, в ходе реализации которой нам нужен новый grub, чтобы заработал автоугадав subvolume с добавлением rootflags=... в параметры ядра, иначе установленная на subvol система не загрузится.
(Ответ для Dmitry V. Levin на комментарий #13) > (In reply to Anton Farygin from comment #10) > > (Ответ для Dmitry V. Levin на комментарий #8) > > > Нынешний pesign в Сизифе с 16-го июня, т.е. уже больше месяца, так что это > > > не аврал, а плановые работы. Поэтому прежде, чем что-либо предпринять, > > > нужно дождаться мантейнера. > > > > да, pesign у нас не часто используется, но когда он нужен - он обычно нужен > > "прямо срочно" ;) > > Я бы понял, если бы в Сизифе сразу что-то сломалось, но что за срочность > может быть в Сизифе месяц спустя? Версии grub сейчас в Sisyphus и p9 синхронны, соответственно если нужно что-то исправить в нём для p9, то исправление сначала придётся притащить в sisyphus. Только не спрашивайте меня, пожалуйста, кто такое придумал. > > Так что скажешь по поводу того, что бы запустить две параллельных версии > > pesign в сборочнице ? > > Для этого, насколько я помню, следует клонировать контейнер, установить в > клон другую версию сервера и мигрировать его хранилище ключей на эту версию. > У меня в плане этих работ не было. Выглядит не очень сложно. А как будет определяться, к какому pesign серверу подключаться на стороне клиента ?
(In reply to Anton Farygin from comment #15) > (Ответ для Dmitry V. Levin на комментарий #13) > > (In reply to Anton Farygin from comment #10) > > > Так что скажешь по поводу того, что бы запустить две параллельных версии > > > pesign в сборочнице ? > > > > Для этого, насколько я помню, следует клонировать контейнер, установить в > > клон другую версию сервера и мигрировать его хранилище ключей на эту версию. > > У меня в плане этих работ не было. > > Выглядит не очень сложно. А как будет определяться, к какому pesign серверу > подключаться на стороне клиента ? Это может настраиваться для каждого целевого репозитория в отдельности. Сейчас для Сизифа настроен отдельный экземпляр pesignery.
Поскольку ldv@ настроил отдельный сервер pesign для Sisyphus и подпись давно работает, полагаю, багу можно закрыть. Если есть замечания - заново откройте.
