44314 2022-11-16 10:21:20 +0300 epm ei недопустим 2023-11-30 17:09:55 +0300 1 1 4 Development Sisyphus eepm unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 rider lav aen amakeenk lav ldv manowar qwetwe rider sin zerg qa-sisyphus oldest_to_newest 217413 0 rider 2022-11-16 10:21:20 +0300 epm ei обновляет сам себя из стороннего репозитория, такое поведение для него допустимо, т.к. значительно усложняет сопровождение этой утилиты. Предлагаю отключить такую возможность. см. bug #44183 218750 1 lav 2022-12-11 21:07:56 +0300 (Ответ для Anton Farygin на комментарий #0) > epm ei обновляет сам себя из стороннего репозитория, такое поведение для > него допустимо, т.к. значительно усложняет сопровождение этой утилиты. Да, но значительно упрощает сопровождение. Особенно в условиях, когда из-за непреодолимых мелочей в стабильный репозиторий месяцами не может попасть новая версия. Самообновлением можно и не пользоваться. В силу специфики тот же epm play завязан не на конкретный репозиторий, а на конкретный момент времени (состояние сторонних пакетов), поэтому регулярное обновление epm важнее, чем его стабилизация к конкретной ветке репозитория. Это как с антивирусными базами. Никому не придёт в голову иметь в репозитории стабильную версию баз сигнатур вирусов. 218757 2 rider 2022-12-12 08:48:26 +0300 к сожалению им пользуются 100% пользователей, а т.к. eepm ei выкачивает свой код, не прошедший никакой проверки - то именно это и недопустимо. Расскажи, пожалуйста, подробнее - что и как делает eepm ei. 219023 3 lav 2022-12-16 07:38:01 +0300 (Ответ для Anton Farygin на комментарий #2) > к сожалению им пользуются 100% пользователей, а т.к. eepm ei выкачивает свой Я тоже не доволен, что пользователям приходится обновлять пакет не из репозитория. Наверное, это вопрос к применяемой методике пропускания в бранч, которая не позволяет новой версии пакета добраться до пользователя через репозиторий? > код, не прошедший никакой проверки - то именно это и недопустимо. Не никакой проверки, а не прошедший проверки QA для попадания в бранч, потому что в изменяющейся среде всегда можно ошибку, которая будет препятствием. > Расскажи, пожалуйста, подробнее - что и как делает eepm ei. Подписанный мантейнером src.rpm собирается в Korinf через hasher и выкладывается на http://download.etersoft.ru/pub/Korinf, откуда и устанавливается через epm ei. Более широко epm ei это команда для установки пакетов из репозитория Korinf: epm ei [название пакета] 219031 4 rider 2022-12-16 09:11:00 +0300 (Ответ для Vitaly Lipatov на комментарий #3) > (Ответ для Anton Farygin на комментарий #2) > > к сожалению им пользуются 100% пользователей, а т.к. eepm ei выкачивает свой > Я тоже не доволен, что пользователям приходится обновлять пакет не из > репозитория. > > Наверное, это вопрос к применяемой методике пропускания в бранч, которая не > позволяет новой версии пакета добраться до пользователя через репозиторий? не допускайте ошибок и eepm доберётся до бранча. > > > код, не прошедший никакой проверки - то именно это и недопустимо. > Не никакой проверки, а не прошедший проверки QA для попадания в бранч, > потому что в изменяющейся среде всегда можно ошибку, которая будет > препятствием. Делайте решение таким образом, что бы оно работало без регрессий. Речь про изменяющуюся среду не идёт. > > > Расскажи, пожалуйста, подробнее - что и как делает eepm ei. > Подписанный мантейнером src.rpm собирается в Korinf через hasher и > выкладывается на http://download.etersoft.ru/pub/Korinf, откуда и > устанавливается через epm ei. Более широко epm ei это команда для установки > пакетов из репозитория Korinf: > epm ei [название пакета] именно потому, что пакет(ы) не проходит стадии сборки на нашей сборочнице - данное решение не приемлемо. Пользователь не понимает, что он устанавливает пакеты не из Альта - для него это не очевидно и если после выполнения команды eepm ei у него что-то ломается, то он подразумевает что виноват репозиторий альта. 219082 5 lav 2022-12-16 15:23:59 +0300 (Ответ для Anton Farygin на комментарий #4) ... > > > код, не прошедший никакой проверки - то именно это и недопустимо. > > Не никакой проверки, а не прошедший проверки QA для попадания в бранч, > > потому что в изменяющейся среде всегда можно ошибку, которая будет > > препятствием. > > Делайте решение таким образом, что бы оно работало без регрессий. Речь про > изменяющуюся среду не идёт. Хорошо, тогда собирайте пакеты в репозиторий так, чтобы их сборка не ломалась и они не попадали в FTBFS. Но я объясню на всякий случай. epm play скачивает и устанавливает пакеты с сайтов сторонних поставщиков. Там эти пакеты меняются (обновляются), что иногда приводит к регрессии. Да даже адрес для скачивания меняются, названия пакетов и т.п. Также обновляются пакеты в репозитории (версии библиотек, сборочная среда, тулчейн), это тоже приводит к регрессии (поломке сборки). Поскольку инструмент и рецепт перепаковки находится в пакете eepm, для устранения регрессий его требуется обновлять. Поскольку рецептов (поддерживаемых приложений) много, достаточно редка ситуация, когда совершенно всё работает. А если ещё начинать придираться к количеству и качеству значков приложения, к ошибкам в самих устанавливаемых пакетах и программах — то тестирование можно не пройти никогда. > Пользователь не понимает, что он устанавливает пакеты не из Альта - для него > это не очевидно и если после выполнения команды eepm ei у него что-то > ломается, то он подразумевает что виноват репозиторий альта. А есть какие пруфы, что пользователь понимает, и что подразумевает? Я достаточно слежу за группой ALT Linux в Телеграме и не мог бы сделать таких выводов. (Ответ для Anton Farygin на комментарий #0) > epm ei обновляет сам себя из стороннего репозитория, такое поведение для > него допустимо, т.к. значительно усложняет сопровождение этой утилиты. Тут опечатка, наличие epm ei значительно упрощает сопровождение. По крайней мере так считает тот, кто сопровождает. > Предлагаю отключить такую возможность. > > см. bug #44183 Эта бага иллюстрирует, что проблемы есть со старыми версиями в репозитории, а со своевременно обновляемым пакетом eepm проблем нет. То есть подтверждает востребованность возможности получения актуальной версии. 219089 6 aen 2022-12-16 15:40:20 +0300 Доводы Виталия мне кажутся резонными. Мы не можем проверить на безопасность сторонние проприетарные пакеты, а вот безопасности сборок Etersoft доверия куда больше. Проблема есть, но я бы отложил обсуждение вариантов решения до окончания праздников. 219127 7 rider 2022-12-17 12:15:58 +0300 Ничего резонного в них нет. Собственно как и ничего резонного в перепаковке сторонних приложений, но это уже другой вопрос. И да, мы вообще никак не можем доверять пакетам, собранным вне сборочной системы и тем более скриптам, которые обновляют пакеты стабильного репозитория из внешних источников, тестирование пакетов в которых отсутствует/ Тем более, категорически неприемлемо рекомендовать такой инструмент пользователям. 219128 8 rider 2022-12-17 12:16:36 +0300 конечно переоткрываю, не исправлять эту ошибку невозможно. 219131 9 aen 2022-12-17 12:58:08 +0300 Не спеши. Обсудим после праздников. Пользователям нравится. 219132 10 rider 2022-12-17 13:03:18 +0300 то, что нравится пользователям - не означает что это правильно с точки зрения целостоности системы. Пользователь подходит к этому вопросу с другой точки зрения. 219133 11 aen 2022-12-17 13:07:31 +0300 (In reply to Anton Farygin from comment #10) > то, что нравится пользователям - не означает что это правильно с точки > зрения целостоности системы. > > Пользователь подходит к этому вопросу с другой точки зрения. Значит надо искать решения. Пользователь будет ставить сторонние пакеты. 219134 12 rider 2022-12-17 13:08:39 +0300 ключевая ошибка в слове "пакет". можно ставить что-то, но надо его ставить в ограниченное окружение, контейнер. 219135 13 rider 2022-12-17 13:09:29 +0300 И конкретно эта ошибка о другом - об установке пакетов репозитория из источников вне репозитория. 219136 14 aen 2022-12-17 13:17:13 +0300 (In reply to Anton Farygin from comment #13) > И конкретно эта ошибка о другом - об установке пакетов репозитория из > источников вне репозитория. От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. Хорошая задача, даже тебе до старости хватит. Проблема в проприетарности внешнего софта. И доверии ему ФСТЭК ты доверяешь? //Я -- нет 219137 15 rider 2022-12-17 13:31:30 +0300 (Ответ для AEN на комментарий #14) > (In reply to Anton Farygin from comment #13) > > И конкретно эта ошибка о другом - об установке пакетов репозитория из > > источников вне репозитория. > > От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. > Хорошая задача, даже тебе до старости хватит. Задача выглядит совсем простой - сборка и установка контейнера не сильно отличается от перепаковки пакета. > > > Проблема в проприетарности внешнего софта. И доверии ему > ФСТЭК ты доверяешь? > //Я -- нет И я нет, поэтому такая ошибка и возникла 219138 16 aen 2022-12-17 13:37:47 +0300 (In reply to Anton Farygin from comment #15) > (Ответ для AEN на комментарий #14) > > (In reply to Anton Farygin from comment #13) > > > И конкретно эта ошибка о другом - об установке пакетов репозитория из > > > источников вне репозитория. > > > > От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. > > Хорошая задача, даже тебе до старости хватит. > > Задача выглядит совсем простой - сборка и установка контейнера не сильно > отличается от перепаковки пакета. > > > > > > > Проблема в проприетарности внешнего софта. И доверии ему > > ФСТЭК ты доверяешь? > > //Я -- нет > > И я нет, поэтому такая ошибка и возникла Тем не менее, они прошли проверку и считаются доверенными. Наверное, сейчас достаточно настроек, какие пакеты доверенные по умолчанию в зависимости от дистрибутива и задачи. Например, исключение пакетов по происхождению, по наличию сертификата etc. Пользователю же ты не запретишь уродовать систему как он захочет. 219139 17 aen 2022-12-17 13:38:18 +0300 (In reply to Anton Farygin from comment #15) > (Ответ для AEN на комментарий #14) > > (In reply to Anton Farygin from comment #13) > > > И конкретно эта ошибка о другом - об установке пакетов репозитория из > > > источников вне репозитория. > > > > От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. > > Хорошая задача, даже тебе до старости хватит. > > Задача выглядит совсем простой - сборка и установка контейнера не сильно > отличается от перепаковки пакета. > > > > > > > Проблема в проприетарности внешнего софта. И доверии ему > > ФСТЭК ты доверяешь? > > //Я -- нет > > И я нет, поэтому такая ошибка и возникла Тем не менее, они прошли проверку и считаются доверенными. Наверное, сейчас достаточно настроек, какие пакеты доверенные по умолчанию в зависимости от дистрибутива и задачи. Например, исключение пакетов по происхождению, по наличию сертификата etc. Пользователю же ты не запретишь уродовать систему как он захочет. 219140 18 rider 2022-12-17 13:40:23 +0300 eepm ei обновляет сам себя так, что бы у пользователя появился пакет, не прошедший проверок. Т.е. - это такой не очень хитрый способ обойти наш процесс тестирования обновлений в стабильные репозитории. 219141 19 aen 2022-12-17 13:53:11 +0300 (Ответ для Anton Farygin на комментарий #18) > eepm ei обновляет сам себя так, что бы у пользователя появился пакет, не > прошедший проверок. > > Т.е. - это такой не очень хитрый способ обойти наш процесс тестирования > обновлений в стабильные репозитории. У нас довольно большой список совместимости. Он тестируется. По умолчанию можно включить в конфигурацию epm его как рекомендуемый нами. 219142 20 rider 2022-12-17 13:58:14 +0300 для включения eepm в рекомендуемый надо сделать так, что бы он не ломал целостность системы. 219143 21 aen 2022-12-17 14:07:46 +0300 (In reply to Anton Farygin from comment #20) > для включения eepm в рекомендуемый надо сделать так, что бы он не ломал > целостность системы. Можно пример сломанной целостности при установке пакета, входящего в список совместимости, при помощи epm? 219145 22 aen 2022-12-17 14:10:34 +0300 Виталий, как часто обновляется epm? 219147 23 rider 2022-12-17 14:11:42 +0300 целостность - это про обновление eepm с помощью eepm. контрольная сумма eepm при этом не совпадает с контрольной суммой eepm из репозитория. 219150 24 lav 2022-12-17 15:52:51 +0300 (Ответ для AEN на комментарий #22) > Виталий, как часто обновляется epm? Например, в августе 2022 почти каждый день. Я бы стремился к обновлению 1-2 раза в неделю, это позволит поддерживать устанавливаемость с приемлемым лагом. К сожалению, добавление каждого нового приложения влечёт потом цепочку исправлений с перетестированием. Потому что я часто добавляю лишь базовую поддержку, по какому-то опыту установки, а далее пользователи или отдел тестирования выявляют тысячу мелочей, на которые я и не рассчитывал, потому что приложение было нужно какому-то одному пользователю для его частного случая и его всё устраивало. То есть тут вопрос ещё об уровне поддержки приложений, я бы разделил на базовую и полную. Иначе тут будет много работы, ещё и в контакте со сторонними вендорами, потому что по сути перепаковка — это решение их интеграционных косяков. 219151 25 lav 2022-12-17 15:55:05 +0300 (Ответ для Anton Farygin на комментарий #13) > И конкретно эта ошибка о другом - об установке пакетов репозитория из > источников вне репозитория. Думаю надо начать с отключения в apt возможности установки пакетов по URL. Это же просто ужас, штатным инструментом для установки пакетов из репозитория можно установить любой мусор из интернета с непредсказуемыми последствиями. При этом даже скрипты установочные выполняются (что выключено в epm). Завести багу? 219152 26 rider 2022-12-17 16:16:32 +0300 Виталий, ты передёргиваешь. при установке по URL явно и очевидно видно, что пакет устанавливается из внешнего источника. 219154 27 aen 2022-12-17 18:13:25 +0300 (Ответ для Vitaly Lipatov на комментарий #24) > (Ответ для AEN на комментарий #22) > > Виталий, как часто обновляется epm? > Например, в августе 2022 почти каждый день. Я бы стремился к обновлению 1-2 > раза в неделю, это позволит поддерживать устанавливаемость с приемлемым > лагом. > > К сожалению, добавление каждого нового приложения влечёт потом цепочку > исправлений с перетестированием. Потому что я часто добавляю лишь базовую > поддержку, по какому-то опыту установки, а далее пользователи или отдел > тестирования выявляют тысячу мелочей, на которые я и не рассчитывал, потому > что приложение было нужно какому-то одному пользователю для его частного > случая и его всё устраивало. То есть тут вопрос ещё об уровне поддержки > приложений, я бы разделил на базовую и полную. Иначе тут будет много работы, > ещё и в контакте со сторонними вендорами, потому что по сути перепаковка — > это решение их интеграционных косяков. Я вижу два варианта: 1. Унификация технологии тестирования в Обнинске и Этерсофт. Различные вопросы взаимодействия между старыми партнерами, думаю, решаемы. 2. Выпуск не более 2х версий в неделю с передачей в Обнинск на срочное тестирование. Прошу не спеша подумать и обсудить потом по ВКС. С Наступающим, коллеги! 219155 28 lav 2022-12-17 19:01:13 +0300 (Ответ для Anton Farygin на комментарий #26) > Виталий, ты передёргиваешь. > > при установке по URL явно и очевидно видно, что пакет устанавливается из > внешнего источника. А, ну тогда наверное будет достаточно для начала добавить в epm ei предупреждение, что будет установка из внешнего источника? Хоть есть два момента: 1. epm ei в принципе инструмент для установки из внешнего источника (репозитория Korinf), и там не только пакет eepm 2. epm play так же скачивает из внешнего источника. Но мне кажется, что предупреждение для пользователя при epm ei поможет сгладить остроту вопроса. 219156 29 aen 2022-12-17 19:05:15 +0300 Полагаю, что да. Но это не отменяет моего предложения. Виталий, а можно где-то ознакомиться с описанием содержимого Коринфа? 224747 30 aen 2023-04-20 12:48:17 +0300 Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода приложения? 224767 31 aen 2023-04-20 17:06:51 +0300 (Ответ для AEN на комментарий #30) > Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода > приложения? Я согласен с Антоном в том, ято обновление кода в стабильном бранче без тестирования для нас недопустимо. Вместе с тем, обновление внешней базы возможно. Это должно быть явно указано. Наверное, нцдев специальная версия для стабильного бранча, с ограничениями. Любители погорячее могут взять в другом месте, в том числе в Сизифе. 224775 32 lav 2023-04-21 00:00:34 +0300 (Ответ для AEN на комментарий #29) > Полагаю, что да. Но это не отменяет моего предложения. Со стороны отдела тестирования сейчас проведено полное тестирование и заведены баги. С моей стороны я подбираюсь к тому, чтобы решить все эти баги и отправить на тестирование очередную версию. Также у меня проводится автоматически тестирование устанавливаемости текущих версий, и только успешно протестированные версии предлагаются пользователю при обновлении всех установленных через epm play пакетов (при команде epm play --update all или epm full-upgrade) На данный момент при выполнении команды epm ei выдаётся запрос: $ epm ei You are about to install https://updates.etersoft.ru/pub/Korinf/x86_64/ALTLinux/p10/eepm-3.52.2-alt0.p10.1.noarch.rpm package(s). Are you sure? [y/N] То есть пользователь явно видит, что и откуда устанавливает и должен подтвердить. > Виталий, а можно где-то ознакомиться с описанием содержимого Коринфа? По сути, там ничего серьёзного пока что, несколько пакетов из Сизифа собирается и всё: https://download.etersoft.ru/pub/Korinf/sources/ (Ответ для AEN на комментарий #30) > Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода > приложения? Нет. epm ei устанавливает пакет eepm из Korinf, то есть это обновление пакета. Ничем не отличается от apt-get install https://download.etersoft.ru/pub/Korinf/x86_64/ALTLinux/p10/eepm-3.52.2-alt0.p10.1.noarch.rpm просто короче. 224776 33 lav 2023-04-21 00:08:15 +0300 (Ответ для AEN на комментарий #31) > (Ответ для AEN на комментарий #30) > > Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода > > приложения? > Я согласен с Антоном в том, ято обновление кода в стабильном бранче без > тестирования для нас недопустимо. Вместе с тем, обновление внешней базы > возможно. Это должно быть явно указано. > Наверное, нцдев специальная версия для стабильного бранча, с ограничениями. > Любители погорячее могут взять в другом месте, в том числе в Сизифе. Я надеюсь решить этот вопрос прохождением актуальной версии eepm в стабильные бранчи. С другой стороны, вся ситуация связана только с излишними требованиями QA к функциональности приложения в той части, которая связана с априори неопределённым поведением — установки последних версий пакетов сторонних поставщиков. То есть сначала созданы условия для того, чтобы пакет не попал в репозиторий, а потом мы героически решаем эту проблему и боремся с тем, что пользователям всё же нужна актуальная версия, пытаемся создать им неудобства. Считаю изначальную постановку проблемы в этой баге надуманной, а поломки устанавливаемости, аналогичные заявленной в в bug #44183 исключёнными тем, что перед релизом eepm выполняется проверка устанавливаемости всех приложений. 224777 34 lav 2023-04-21 00:44:25 +0300 Мы обсудили с aen@ в телефонном разговоре и я подготовлю решение по отключению epm ei для стабильных бранчей. 224780 35 sin 2023-04-21 04:22:17 +0300 У меня несколько отстранённое видение по поводу обсуждаемого сложилось. Предлагаю разделить сущности - инструмент и список источников для установки, в том числе и самого epm. Считаю, что Виталий остаивает не только свой личный интерес, встраивая соответствующий механизм обновлений, но любого стороннего разработчика. Чем, в сущности, отличает epm от других сторонних разработок? А вот чем: - открытый и свободный; - sisyphus-ориентированный; - доступный в других ОС. Я бы тут предложил, всё-таки делать упор не столько на запреты по умолчанию, сколько на инструментарий контроля за установленным ПО. Например, у нас в тегах пакетов присутствует тег Vendor. Нам требуется такой пользовательский (админы для нас тут тоже пользователи наших дистрибутивных решений) инструментарий, который позволяет явно определить какие установленные пакеты наши, а какие - нет. В таком случае стоило бы рассчитывать увидеть разницу в этом теге для пакетов установленных из родных альтовых репозиториев и сторонних: $ rpm -q eepm --queryformat="%{VENDOR}\n" ALT Linux Team $ sudo apt-get install http://download.etersoft.ru/pub/Korinf/x86_64/ALTLinux/p10/eepm-3.52.3-eter0.p10.1.noarch.rpm Получено: 1 http://download.etersoft.ru/pub/Korinf/x86_64/ALTLinux/p10/eepm-3.52.3-eter0.p10.1.noarch.rpm [309kB] Получено 309kB за 0s (2247kB/s). Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Выбрано eepm для 'eepm-3.52.3-eter0.p10.1.noarch.rpm' Следующие пакеты будут ОБНОВЛЕНЫ: eepm 1 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 259 не будет обновлено. Необходимо получить 0B/309kB архивов. После распаковки потребуется дополнительно 255kB дискового пространства. Совершаем изменения... Подготовка... ###...#### [100%] Обновление / установка... 1: eepm-3.52.3-eter0.p10.1 ###...### [ 50%] Очистка / удаление... 2: eepm-3.28.1-alt1 ###...### [100%] Завершено. $ rpm -q eepm --queryformat="%{VENDOR}\n" ALT Linux Team В данном случае, после установки пакета из Korinf, я бы рассчитывал увидеть для тега Vendor значение Etersoft. 224781 36 lav 2023-04-21 05:03:26 +0300 (Ответ для Evgeny Sinelnikov на комментарий #35) ... > Я бы тут предложил, всё-таки делать упор не столько на запреты по умолчанию, > сколько на инструментарий контроля за установленным ПО. Например, у нас в > тегах пакетов присутствует тег Vendor. Кажется, что имеется в виду вендор программы, а не пакета... Есть более точный способ — пакеты каким-то образом подписаны ключами мантейнеров Signature : RSA/SHA512, Пт 29 апр 2022 12:19:59, Key ID ff979dedda2773bb Хотя я и не понимаю, откуда там моя подпись, если я подписывал только тэг в git-репозитории. Но есть ещё проблема, что нет отличия между пакетом из репозитория и из таска. > Нам требуется такой пользовательский (админы для нас тут тоже пользователи > наших дистрибутивных решений) инструментарий, который позволяет явно > определить какие установленные пакеты наши, а какие - нет. И на самом деле хотелось бы ещё не наши/не наши, а из репозитория или нет, то есть протестированы (прошли QA) или нет. Да, мне бы проверка наш/не наш в epm не помешала бы. Есть ряд пакетов, которые могут быть из репозитория, и тогда мне их надо игнорировать при обновлении в epm play. > В таком случае стоило бы рассчитывать увидеть разницу в этом теге для > пакетов установленных из родных альтовых репозиториев и сторонних: > > $ rpm -q eepm --queryformat="%{VENDOR}\n" > ALT Linux Team ... > В данном случае, после установки пакета из Korinf, я бы рассчитывал увидеть > для тега Vendor значение Etersoft. Я пытался явно задать Vendor и Distribution в спеке, но почему-то это у меня не срабатывает на ALT при сборке в hasher. Кстати, ещё есть проблема типа пакета yandex-browser-stable: specs]$ git grep ^Vendor: e/education-portals/education-portals.spec:Vendor: ALT Linux Team e/epsidm24-secc0001/epsidm24.spec:Vendor: Seiko Epson Corporation l/libpam-google-authenticator/libpam-google-authenticator.spec:Vendor: ALT Linux Team l/librtpam/librtpam.spec:Vendor: Aktiv Co. l/libuvc/libuvc.spec:Vendor: ALT Linux Team n/nspec/nspec.spec:Vendor: ALT Linux Team o/openssl-engines-rutoken/openssl-engines-rutoken.spec:Vendor: Aktiv Co. o/opera64-dev/opera64-dev.spec:Vendor: Opera Software ASA y/yandex-browser-stable/browser.spec:Vendor: YANDEX LLC Поэтому я сделал проверку по релизу (altX), а пакеты в Korinf стал собирать с релизом eterX и таким образом реализовал твоё предложение. Также ещё есть тэг Distribution с вариантами ALT Sisyphus и ALT p10, которые я видел в собранных в репозиторий пакетах и просто ALT в собираемых просто. 224782 37 aen 2023-04-21 08:01:25 +0300 Евгений, мне кажется, Вы не учитываете существенную разницу между назначением и ответственностью за стабильные продукты и проекты в разработке. 224783 38 aen 2023-04-21 08:34:05 +0300 Я прошу дождаться рассказа Виталия о нашем разговоре. В его трактовке. Спасибо. 224787 39 ldv 2023-04-21 10:55:53 +0300 (In reply to Vitaly Lipatov from comment #36) > (Ответ для Evgeny Sinelnikov на комментарий #35) > ... > > Я бы тут предложил, всё-таки делать упор не столько на запреты по умолчанию, > > сколько на инструментарий контроля за установленным ПО. Например, у нас в > > тегах пакетов присутствует тег Vendor. > Кажется, что имеется в виду вендор программы, а не пакета... > > Есть более точный способ — пакеты каким-то образом подписаны ключами > мантейнеров > Signature : RSA/SHA512, Пт 29 апр 2022 12:19:59, Key ID ff979dedda2773bb > Хотя я и не понимаю, откуда там моя подпись, если я подписывал только тэг в > git-репозитории. > > Но есть ещё проблема, что нет отличия между пакетом из репозитория и из > таска. По сути единственный надёжный и поддерживаемый метод проверки источника - это проверка подписи base/release, которую выполняет apt до начала скачивания пакетов. 224788 40 rider 2023-04-21 11:10:56 +0300 (Ответ для Dmitry V. Levin на комментарий #39) > (In reply to Vitaly Lipatov from comment #36) > > (Ответ для Evgeny Sinelnikov на комментарий #35) > > ... > > > Я бы тут предложил, всё-таки делать упор не столько на запреты по умолчанию, > > > сколько на инструментарий контроля за установленным ПО. Например, у нас в > > > тегах пакетов присутствует тег Vendor. > > Кажется, что имеется в виду вендор программы, а не пакета... > > > > Есть более точный способ — пакеты каким-то образом подписаны ключами > > мантейнеров > > Signature : RSA/SHA512, Пт 29 апр 2022 12:19:59, Key ID ff979dedda2773bb > > Хотя я и не понимаю, откуда там моя подпись, если я подписывал только тэг в > > git-репозитории. > > > > Но есть ещё проблема, что нет отличия между пакетом из репозитория и из > > таска. > > По сути единственный надёжный и поддерживаемый метод проверки источника - > это проверка подписи base/release, которую выполняет apt до начала > скачивания пакетов. Это, кстати, проблема - если кто-то перегенерил хеши апта, то отличить подписанные нами пакеты от неподписанных уже невозможно. 224791 41 ldv 2023-04-21 13:06:10 +0300 (In reply to Anton Farygin from comment #40) > (Ответ для Dmitry V. Levin на комментарий #39) > > (In reply to Vitaly Lipatov from comment #36) > > > (Ответ для Evgeny Sinelnikov на комментарий #35) > > > ... > > > > Я бы тут предложил, всё-таки делать упор не столько на запреты по умолчанию, > > > > сколько на инструментарий контроля за установленным ПО. Например, у нас в > > > > тегах пакетов присутствует тег Vendor. > > > Кажется, что имеется в виду вендор программы, а не пакета... > > > > > > Есть более точный способ — пакеты каким-то образом подписаны ключами > > > мантейнеров > > > Signature : RSA/SHA512, Пт 29 апр 2022 12:19:59, Key ID ff979dedda2773bb > > > Хотя я и не понимаю, откуда там моя подпись, если я подписывал только тэг в > > > git-репозитории. > > > > > > Но есть ещё проблема, что нет отличия между пакетом из репозитория и из > > > таска. > > > > По сути единственный надёжный и поддерживаемый метод проверки источника - > > это проверка подписи base/release, которую выполняет apt до начала > > скачивания пакетов. > > Это, кстати, проблема - если кто-то перегенерил хеши апта, то отличить > подписанные нами пакеты от неподписанных уже невозможно. От подписи самих пакетов толку мало. Например, пакет, собранный год назад, сейчас уже может содержать известные уязвимости и быть неподлежащим установке. Есть целый класс атак, в котором пользователю специально подсовывают старый уязвимый, но при этом подписанный софт. Поэтому подпись имеет смысл только на репозитории. Если кто-то перегенерил подпись репозитория, то это уже другой репозиторий. 224825 42 rider 2023-04-21 16:05:30 +0300 А проверка по версии на уязвимости - это отдельная задача, мы её сейчас решаем. Ну и вторая проблема - в уже установленной системе нет репозитория (соответственно нет проверки подписи репозитория), и так же можно оставить старую версию ПО через Hold. Но при этом действительно криптографически стойкой offline валидации того, что пакет собран у нас на сборочнице сейчас нет (online я могу реализовать быстро). 224881 43 lav 2023-04-24 12:11:39 +0300 На данный момент при использовании пакета из репозитория в системе на стабильном бранче (не на Сизифе) команда epm ei отключена: $ epm ei Warning: Using external (Korinf) repo is forbidden for stable ALT branch p10. Check https://bugzilla.altlinux.org/44314 for reasons. You can install eepm package from Korinf manually, check instruction at https://eepm.ru Понятно, что в реальности это будет происходить только после того, как в репозитории появится новый epm с этим исправлением. 224882 44 lav 2023-04-24 12:49:11 +0300 (Ответ для Dmitry V. Levin на комментарий #41) ... > От подписи самих пакетов толку мало. Например, пакет, собранный год назад, > сейчас уже может содержать известные уязвимости и быть неподлежащим > установке. Есть целый класс атак, в котором пользователю специально > подсовывают старый уязвимый, но при этом подписанный софт. Поэтому подпись > имеет смысл только на репозитории. Если кто-то перегенерил подпись > репозитория, то это уже другой репозиторий. Тем не менее хотелось бы иметь способ узнать происхождение пакета: взят ли он из репозитория (в том числе конкретного стабильного репозитория), а в идеале бы ещё и знать, что пакет прошёл QA. Наверное, можно принять допущение, что при этом пакет имеет актуальную версию (последнюю) и установлен из подписанного репозитория. 224923 45 ldv 2023-04-24 19:32:16 +0300 (In reply to Vitaly Lipatov from comment #44) > (Ответ для Dmitry V. Levin на комментарий #41) > ... > > От подписи самих пакетов толку мало. Например, пакет, собранный год назад, > > сейчас уже может содержать известные уязвимости и быть неподлежащим > > установке. Есть целый класс атак, в котором пользователю специально > > подсовывают старый уязвимый, но при этом подписанный софт. Поэтому подпись > > имеет смысл только на репозитории. Если кто-то перегенерил подпись > > репозитория, то это уже другой репозиторий. > Тем не менее хотелось бы иметь способ узнать происхождение пакета: Непонятно, какая от этого могла бы быть польза. Впрочем, это лучше выносить отсюда в devel@, наверное. 225132 46 manowar 2023-04-28 01:53:34 +0300 (Ответ для Dmitry V. Levin на комментарий #39) > По сути единственный надёжный и поддерживаемый метод проверки источника - > это проверка подписи base/release, которую выполняет apt до начала > скачивания пакетов. А он, случаем, не единственный вообще реализованный технически? Просто кто-то, кажется, Денис, говорил, что rpm у нас не проверяет подписи, поскольку эта задача возложена на apt. Если это действительно так, то тут есть противоречие: за аутентичность пакетов отвечает только apt, но apt — не единственный способ установки пакетов. 238027 47 zerg 2023-11-29 16:15:57 +0300 (Ответ для Vitaly Lipatov на комментарий #5) > А есть какие пруфы, что пользователь понимает, и что подразумевает? Я Есть. https://t.me/alt_linux/353358 > достаточно слежу за группой ALT Linux в Телеграме > и не мог бы сделать таких выводов. Видимо, этого недостаточно. В p10 проблема ещё не исправлена. 238030 48 manowar 2023-11-29 16:48:49 +0300 (Ответ для Vitaly Lipatov на комментарий #5) > Поскольку инструмент и рецепт перепаковки находится в пакете eepm, для > устранения регрессий его требуется обновлять. (Ответ для Vitaly Lipatov на комментарий #1) > Это как с антивирусными > базами. Никому не придёт в голову иметь в репозитории стабильную версию баз > сигнатур вирусов. А нельзя ли, в самом деле, поступить так, как с антивирусными базами? Пусть инструмент перепаковки находится в пакете eepm, обновляется редко, проходит проверку перед попаданием в бранч и устанавливается только из прошедшего проверку пакета. А рецепты, напротив, располагаются вне пакета, обновляются часто и загружаются напрямую с сайта разработчика этих рецептов (Этерсофт)? 238073 49 zerg 2023-11-30 13:36:15 +0300 (Ответ для manowar@altlinux.org на комментарий #48) > часто и загружаются напрямую с сайта разработчика этих рецептов (Этерсофт)? Без проверки, чтоб потом выполняться от root? 238074 50 manowar 2023-11-30 13:59:37 +0300 ИМХО тут не тестирование, а больше code review тогда нужен. И проверка статическим анализатором. Выявление уязвимостей вообще непростая задача, она не решается службой QA в одиночку. 238075 51 manowar 2023-11-30 14:09:40 +0300 А мы не можем сделать так, чтобы epm работал бы в выделенном чруте? Как всякие там Flatpack делают и прочее? Потому что основная проблема, на мой взгляд, это всё-таки проприетарщина прямо в системе, а не установочные скрипты от Этерсофт. 238076 52 zerg 2023-11-30 14:15:44 +0300 (Ответ для manowar@altlinux.org на комментарий #50) > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > не решается службой QA в одиночку. Это не отменяет непроверенную загрузку непойми чего непойми откуда. 238080 53 aen 2023-11-30 14:27:12 +0300 (Ответ для Sergey V Turchin на комментарий #52) > (Ответ для manowar@altlinux.org на комментарий #50) > > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > > не решается службой QA в одиночку. > Это не отменяет непроверенную загрузку непойми чего непойми откуда. Можно конкретно? Пример "непойми чего непойми откуда" с epm play. 238081 54 zerg 2023-11-30 14:30:55 +0300 (Ответ для AEN на комментарий #53) > Пример "непойми чего непойми откуда" с epm play. MITM 238082 55 aen 2023-11-30 14:32:45 +0300 (Ответ для Sergey V Turchin на комментарий #54) > (Ответ для AEN на комментарий #53) > > Пример "непойми чего непойми откуда" с epm play. > MITM Я просил конкретный пример с epm play. 238084 56 zerg 2023-11-30 14:44:10 +0300 (Ответ для AEN на комментарий #55) > Я просил конкретный пример с epm play. Любой. Каждый. Все. Мне это очевидно как не-специалисту. Хотите более страшных подробностей -- проконсультируйтесь у специалиста. 238085 57 aen 2023-11-30 14:47:26 +0300 (Ответ для Sergey V Turchin на комментарий #56) > (Ответ для AEN на комментарий #55) > > Я просил конкретный пример с epm play. > Любой. Каждый. Все. > > Мне это очевидно как не-специалисту. Хотите более страшных подробностей -- > проконсультируйтесь у специалиста. Извините, это пустые слова. 238086 58 zerg 2023-11-30 14:53:43 +0300 (Ответ для AEN на комментарий #57) > Извините, это пустые слова. Не суть. Факта они не отменяют. 238089 59 rider 2023-11-30 14:55:48 +0300 (Ответ для AEN на комментарий #53) > (Ответ для Sergey V Turchin на комментарий #52) > > (Ответ для manowar@altlinux.org на комментарий #50) > > > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > > > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > > > не решается службой QA в одиночку. > > Это не отменяет непроверенную загрузку непойми чего непойми откуда. > > Можно конкретно? > Пример "непойми чего непойми откуда" с epm play. Так вот же все примеры: https://git.altlinux.org/gears/e/eepm.git?p=eepm.git;a=tree;f=play.d;h=9f11e59ca6e8576bf6799063590feaddfc2a84d4;hb=0d05f5e7fa44c50d745d6ee531bcdf7fa0159912 238090 60 aen 2023-11-30 14:59:45 +0300 (Ответ для Anton Farygin на комментарий #59) > (Ответ для AEN на комментарий #53) > > (Ответ для Sergey V Turchin на комментарий #52) > > > (Ответ для manowar@altlinux.org на комментарий #50) > > > > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > > > > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > > > > не решается службой QA в одиночку. > > > Это не отменяет непроверенную загрузку непойми чего непойми откуда. > > > > Можно конкретно? > > Пример "непойми чего непойми откуда" с epm play. > > Так вот же все примеры: > https://git.altlinux.org/gears/e/eepm.git?p=eepm.git;a=tree;f=play.d; > h=9f11e59ca6e8576bf6799063590feaddfc2a84d4; > hb=0d05f5e7fa44c50d745d6ee531bcdf7fa0159912 https://bugzilla.altlinux.org/show_bug.cgi?id=44314#c53 238091 61 zerg 2023-11-30 15:12:36 +0300 Баг был не исправлен, а замаскирован исключительно для Sisyphus https://git.altlinux.org/gears/e/eepm.git?p=eepm.git;a=commit;h=3d87c08e753c3e674919d2cba73339d9d36ff2b6 238092 62 zerg 2023-11-30 15:15:45 +0300 (Ответ для Sergey V Turchin на комментарий #61) > Баг был не исправлен, а замаскирован исключительно для Sisyphus Извиняюсь, "исправлен" был, но у меня он считает, что у меня "p10" на Сизифе. 238093 63 rider 2023-11-30 15:19:34 +0300 (Ответ для AEN на комментарий #60) > (Ответ для Anton Farygin на комментарий #59) > > (Ответ для AEN на комментарий #53) > > > (Ответ для Sergey V Turchin на комментарий #52) > > > > (Ответ для manowar@altlinux.org на комментарий #50) > > > > > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > > > > > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > > > > > не решается службой QA в одиночку. > > > > Это не отменяет непроверенную загрузку непойми чего непойми откуда. > > > > > > Можно конкретно? > > > Пример "непойми чего непойми откуда" с epm play. > > > > Так вот же все примеры: > > https://git.altlinux.org/gears/e/eepm.git?p=eepm.git;a=tree;f=play.d; > > h=9f11e59ca6e8576bf6799063590feaddfc2a84d4; > > hb=0d05f5e7fa44c50d745d6ee531bcdf7fa0159912 > > https://bugzilla.altlinux.org/show_bug.cgi?id=44314#c53 Алексей, надо или код начинать читать или прекращать болтологию. Уже неоднократно написали - везде, во всех 100% случаях загрузки из внешних источников нет никаких проверок то ли что хотелось получено. 238095 64 aen 2023-11-30 15:24:29 +0300 (Ответ для Anton Farygin на комментарий #63) > (Ответ для AEN на комментарий #60) > > (Ответ для Anton Farygin на комментарий #59) > > > (Ответ для AEN на комментарий #53) > > > > (Ответ для Sergey V Turchin на комментарий #52) > > > > > (Ответ для manowar@altlinux.org на комментарий #50) > > > > > > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > > > > > > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > > > > > > не решается службой QA в одиночку. > > > > > Это не отменяет непроверенную загрузку непойми чего непойми откуда. > > > > > > > > Можно конкретно? > > > > Пример "непойми чего непойми откуда" с epm play. > > > > > > Так вот же все примеры: > > > https://git.altlinux.org/gears/e/eepm.git?p=eepm.git;a=tree;f=play.d; > > > h=9f11e59ca6e8576bf6799063590feaddfc2a84d4; > > > hb=0d05f5e7fa44c50d745d6ee531bcdf7fa0159912 > > > > https://bugzilla.altlinux.org/show_bug.cgi?id=44314#c53 > > Алексей, надо или код начинать читать или прекращать болтологию. Уже > неоднократно написали - везде, во всех 100% случаях загрузки из внешних > источников нет никаких проверок то ли что хотелось получено. Это пустые слова. та самая болтология . Приведи конкретный пример, когда программа загружается из левого источника. Нет примера, -- разговор ни о чем. 238096 65 manowar 2023-11-30 15:38:38 +0300 (Ответ для Sergey V Turchin на комментарий #54) > (Ответ для AEN на комментарий #53) > > Пример "непойми чего непойми откуда" с epm play. > MITM Нормальный протокол обновления предполагает проверку загрузчиком подписи тех файлов, которые скачиваются. Вот реально, как с антивирусными базами. Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит в себе неплохой план решения проблемы: отделение часто обновляемых скриптов от редко обновляемого ядра. По крайней мере, в качестве первого шага. 238097 66 zerg 2023-11-30 15:46:11 +0300 (Ответ для manowar@altlinux.org на комментарий #65) > Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит > в себе неплохой план решения проблемы: отделение часто обновляемых скриптов > от редко обновляемого ядра. По крайней мере, в качестве первого шага. Кажется, это выглядит как необходимость ещё не-одной дополнительной проверки, а отдел тестирования прогуливается в соседнем лесу. 238098 67 aen 2023-11-30 15:53:46 +0300 (Ответ для manowar@altlinux.org на комментарий #65) > (Ответ для Sergey V Turchin на комментарий #54) > > (Ответ для AEN на комментарий #53) > > > Пример "непойми чего непойми откуда" с epm play. > > MITM > > Нормальный протокол обновления предполагает проверку загрузчиком подписи тех > файлов, которые скачиваются. Вот реально, как с антивирусными базами. > > Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит > в себе неплохой план решения проблемы: отделение часто обновляемых скриптов > от редко обновляемого ядра. По крайней мере, в качестве первого шага. Подпись, боюсь, не всегда есть Проверять контрольную сумму -- да, надо. Обычно она есть на сайте вендора, с которого и идёт скачивание. 238100 68 rider 2023-11-30 15:54:40 +0300 Мы договорились о том, что тестирование всех вариантов загрузки для eepm play не проводится, т.к. это сильно затратный по времени и ресурсам процесс с непредсказуемыми последствиями - сейчас загрузка идёт из внешних источников и она может сломаться по причине смены архивов на этих внешних источниках. Т.е. - архитектурно решение сделано так, что оно может работать а может не работать и гарантировать ничего в этом невозможно. 238101 69 zerg 2023-11-30 15:56:02 +0300 (Ответ для AEN на комментарий #67) > Проверять контрольную сумму -- да, надо. > Обычно она есть на сайте вендора, с которого и идёт скачивание. А у неё есть подпись или контрольная сумма? ;-) 238102 70 aen 2023-11-30 16:11:23 +0300 Бага https://bugzilla.altlinux.org/48465 об этом. Предлагаю перейти туда. 238108 71 manowar 2023-11-30 16:42:34 +0300 (Ответ для AEN на комментарий #67) > (Ответ для manowar@altlinux.org на комментарий #65) > > (Ответ для Sergey V Turchin на комментарий #54) > > > (Ответ для AEN на комментарий #53) > > > > Пример "непойми чего непойми откуда" с epm play. > > > MITM > > > > Нормальный протокол обновления предполагает проверку загрузчиком подписи тех > > файлов, которые скачиваются. Вот реально, как с антивирусными базами. > > > > Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит > > в себе неплохой план решения проблемы: отделение часто обновляемых скриптов > > от редко обновляемого ядра. По крайней мере, в качестве первого шага. > > Подпись, боюсь, не всегда есть > Проверять контрольную сумму -- да, надо. > Обычно она есть на сайте вендора, с которого и идёт скачивание. Я имел в виду, что если epm будет самостоятельно обновлять установочные скрипты с сайта Этерсофт, то эти скрипты должны быть подписаны. Проверка пакетов с сайта вендора — это отдельная задача и проблема. Эта бага — про процедуру обновления самого epm, насколько я понимаю. 238110 72 zerg 2023-11-30 16:45:39 +0300 (Ответ для manowar@altlinux.org на комментарий #71) > Эта бага — про процедуру обновления самого epm, насколько я понимаю. Да. И в p10 она до сих пор не исправлена. 238111 73 amakeenk 2023-11-30 16:48:45 +0300 (Ответ для Sergey V Turchin на комментарий #72) > И в p10 она до сих пор не исправлена. В p10 сейчас: $ rpm -q eepm && epm ei eepm-3.57.6-alt1.noarch WARNING: Using external (Korinf) repo is forbidden for stable ALT branch p10. Check https://bugzilla.altlinux.org/44314 for reasons. You can install eepm package from Korinf manually, check instruction at https://eepm.ru Trying update eepm from the stable ALT repository ... $ epm install eepm $ sudo apt-get -o APT::Install::VirtualVersion=true -o APT::Install::Virtual=true install eepm Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Последняя версия eepm уже установлена. 0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 10 не будет обновлено. 238113 74 zerg 2023-11-30 17:09:42 +0300 (Ответ для Alexander Makeenkov на комментарий #73) > В p10 сейчас: Извиняюсь, проглядел, исправлена.