epm ei обновляет сам себя из стороннего репозитория, такое поведение для него допустимо, т.к. значительно усложняет сопровождение этой утилиты. Предлагаю отключить такую возможность. см. bug #44183
(Ответ для Anton Farygin на комментарий #0) > epm ei обновляет сам себя из стороннего репозитория, такое поведение для > него допустимо, т.к. значительно усложняет сопровождение этой утилиты. Да, но значительно упрощает сопровождение. Особенно в условиях, когда из-за непреодолимых мелочей в стабильный репозиторий месяцами не может попасть новая версия. Самообновлением можно и не пользоваться. В силу специфики тот же epm play завязан не на конкретный репозиторий, а на конкретный момент времени (состояние сторонних пакетов), поэтому регулярное обновление epm важнее, чем его стабилизация к конкретной ветке репозитория. Это как с антивирусными базами. Никому не придёт в голову иметь в репозитории стабильную версию баз сигнатур вирусов.
к сожалению им пользуются 100% пользователей, а т.к. eepm ei выкачивает свой код, не прошедший никакой проверки - то именно это и недопустимо. Расскажи, пожалуйста, подробнее - что и как делает eepm ei.
(Ответ для 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 [название пакета]
(Ответ для 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 у него что-то ломается, то он подразумевает что виноват репозиторий альта.
(Ответ для Anton Farygin на комментарий #4) ... > > > код, не прошедший никакой проверки - то именно это и недопустимо. > > Не никакой проверки, а не прошедший проверки QA для попадания в бранч, > > потому что в изменяющейся среде всегда можно ошибку, которая будет > > препятствием. > > Делайте решение таким образом, что бы оно работало без регрессий. Речь про > изменяющуюся среду не идёт. Хорошо, тогда собирайте пакеты в репозиторий так, чтобы их сборка не ломалась и они не попадали в FTBFS. Но я объясню на всякий случай. epm play скачивает и устанавливает пакеты с сайтов сторонних поставщиков. Там эти пакеты меняются (обновляются), что иногда приводит к регрессии. Да даже адрес для скачивания меняются, названия пакетов и т.п. Также обновляются пакеты в репозитории (версии библиотек, сборочная среда, тулчейн), это тоже приводит к регрессии (поломке сборки). Поскольку инструмент и рецепт перепаковки находится в пакете eepm, для устранения регрессий его требуется обновлять. Поскольку рецептов (поддерживаемых приложений) много, достаточно редка ситуация, когда совершенно всё работает. А если ещё начинать придираться к количеству и качеству значков приложения, к ошибкам в самих устанавливаемых пакетах и программах — то тестирование можно не пройти никогда. > Пользователь не понимает, что он устанавливает пакеты не из Альта - для него > это не очевидно и если после выполнения команды eepm ei у него что-то > ломается, то он подразумевает что виноват репозиторий альта. А есть какие пруфы, что пользователь понимает, и что подразумевает? Я достаточно слежу за группой ALT Linux в Телеграме и не мог бы сделать таких выводов. (Ответ для Anton Farygin на комментарий #0) > epm ei обновляет сам себя из стороннего репозитория, такое поведение для > него допустимо, т.к. значительно усложняет сопровождение этой утилиты. Тут опечатка, наличие epm ei значительно упрощает сопровождение. По крайней мере так считает тот, кто сопровождает. > Предлагаю отключить такую возможность. > > см. bug #44183 Эта бага иллюстрирует, что проблемы есть со старыми версиями в репозитории, а со своевременно обновляемым пакетом eepm проблем нет. То есть подтверждает востребованность возможности получения актуальной версии.
Доводы Виталия мне кажутся резонными. Мы не можем проверить на безопасность сторонние проприетарные пакеты, а вот безопасности сборок Etersoft доверия куда больше. Проблема есть, но я бы отложил обсуждение вариантов решения до окончания праздников.
Ничего резонного в них нет. Собственно как и ничего резонного в перепаковке сторонних приложений, но это уже другой вопрос. И да, мы вообще никак не можем доверять пакетам, собранным вне сборочной системы и тем более скриптам, которые обновляют пакеты стабильного репозитория из внешних источников, тестирование пакетов в которых отсутствует/ Тем более, категорически неприемлемо рекомендовать такой инструмент пользователям.
конечно переоткрываю, не исправлять эту ошибку невозможно.
Не спеши. Обсудим после праздников. Пользователям нравится.
то, что нравится пользователям - не означает что это правильно с точки зрения целостоности системы. Пользователь подходит к этому вопросу с другой точки зрения.
(In reply to Anton Farygin from comment #10) > то, что нравится пользователям - не означает что это правильно с точки > зрения целостоности системы. > > Пользователь подходит к этому вопросу с другой точки зрения. Значит надо искать решения. Пользователь будет ставить сторонние пакеты.
ключевая ошибка в слове "пакет". можно ставить что-то, но надо его ставить в ограниченное окружение, контейнер.
И конкретно эта ошибка о другом - об установке пакетов репозитория из источников вне репозитория.
(In reply to Anton Farygin from comment #13) > И конкретно эта ошибка о другом - об установке пакетов репозитория из > источников вне репозитория. От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. Хорошая задача, даже тебе до старости хватит. Проблема в проприетарности внешнего софта. И доверии ему ФСТЭК ты доверяешь? //Я -- нет
(Ответ для AEN на комментарий #14) > (In reply to Anton Farygin from comment #13) > > И конкретно эта ошибка о другом - об установке пакетов репозитория из > > источников вне репозитория. > > От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. > Хорошая задача, даже тебе до старости хватит. Задача выглядит совсем простой - сборка и установка контейнера не сильно отличается от перепаковки пакета. > > > Проблема в проприетарности внешнего софта. И доверии ему > ФСТЭК ты доверяешь? > //Я -- нет И я нет, поэтому такая ошибка и возникла
(In reply to Anton Farygin from comment #15) > (Ответ для AEN на комментарий #14) > > (In reply to Anton Farygin from comment #13) > > > И конкретно эта ошибка о другом - об установке пакетов репозитория из > > > источников вне репозитория. > > > > От этого не убежишь, пока не рассуешь всё сторонние пакеты по контейнерам. > > Хорошая задача, даже тебе до старости хватит. > > Задача выглядит совсем простой - сборка и установка контейнера не сильно > отличается от перепаковки пакета. > > > > > > > Проблема в проприетарности внешнего софта. И доверии ему > > ФСТЭК ты доверяешь? > > //Я -- нет > > И я нет, поэтому такая ошибка и возникла Тем не менее, они прошли проверку и считаются доверенными. Наверное, сейчас достаточно настроек, какие пакеты доверенные по умолчанию в зависимости от дистрибутива и задачи. Например, исключение пакетов по происхождению, по наличию сертификата etc. Пользователю же ты не запретишь уродовать систему как он захочет.
eepm ei обновляет сам себя так, что бы у пользователя появился пакет, не прошедший проверок. Т.е. - это такой не очень хитрый способ обойти наш процесс тестирования обновлений в стабильные репозитории.
(Ответ для Anton Farygin на комментарий #18) > eepm ei обновляет сам себя так, что бы у пользователя появился пакет, не > прошедший проверок. > > Т.е. - это такой не очень хитрый способ обойти наш процесс тестирования > обновлений в стабильные репозитории. У нас довольно большой список совместимости. Он тестируется. По умолчанию можно включить в конфигурацию epm его как рекомендуемый нами.
для включения eepm в рекомендуемый надо сделать так, что бы он не ломал целостность системы.
(In reply to Anton Farygin from comment #20) > для включения eepm в рекомендуемый надо сделать так, что бы он не ломал > целостность системы. Можно пример сломанной целостности при установке пакета, входящего в список совместимости, при помощи epm?
Виталий, как часто обновляется epm?
целостность - это про обновление eepm с помощью eepm. контрольная сумма eepm при этом не совпадает с контрольной суммой eepm из репозитория.
(Ответ для AEN на комментарий #22) > Виталий, как часто обновляется epm? Например, в августе 2022 почти каждый день. Я бы стремился к обновлению 1-2 раза в неделю, это позволит поддерживать устанавливаемость с приемлемым лагом. К сожалению, добавление каждого нового приложения влечёт потом цепочку исправлений с перетестированием. Потому что я часто добавляю лишь базовую поддержку, по какому-то опыту установки, а далее пользователи или отдел тестирования выявляют тысячу мелочей, на которые я и не рассчитывал, потому что приложение было нужно какому-то одному пользователю для его частного случая и его всё устраивало. То есть тут вопрос ещё об уровне поддержки приложений, я бы разделил на базовую и полную. Иначе тут будет много работы, ещё и в контакте со сторонними вендорами, потому что по сути перепаковка — это решение их интеграционных косяков.
(Ответ для Anton Farygin на комментарий #13) > И конкретно эта ошибка о другом - об установке пакетов репозитория из > источников вне репозитория. Думаю надо начать с отключения в apt возможности установки пакетов по URL. Это же просто ужас, штатным инструментом для установки пакетов из репозитория можно установить любой мусор из интернета с непредсказуемыми последствиями. При этом даже скрипты установочные выполняются (что выключено в epm). Завести багу?
Виталий, ты передёргиваешь. при установке по URL явно и очевидно видно, что пакет устанавливается из внешнего источника.
(Ответ для Vitaly Lipatov на комментарий #24) > (Ответ для AEN на комментарий #22) > > Виталий, как часто обновляется epm? > Например, в августе 2022 почти каждый день. Я бы стремился к обновлению 1-2 > раза в неделю, это позволит поддерживать устанавливаемость с приемлемым > лагом. > > К сожалению, добавление каждого нового приложения влечёт потом цепочку > исправлений с перетестированием. Потому что я часто добавляю лишь базовую > поддержку, по какому-то опыту установки, а далее пользователи или отдел > тестирования выявляют тысячу мелочей, на которые я и не рассчитывал, потому > что приложение было нужно какому-то одному пользователю для его частного > случая и его всё устраивало. То есть тут вопрос ещё об уровне поддержки > приложений, я бы разделил на базовую и полную. Иначе тут будет много работы, > ещё и в контакте со сторонними вендорами, потому что по сути перепаковка — > это решение их интеграционных косяков. Я вижу два варианта: 1. Унификация технологии тестирования в Обнинске и Этерсофт. Различные вопросы взаимодействия между старыми партнерами, думаю, решаемы. 2. Выпуск не более 2х версий в неделю с передачей в Обнинск на срочное тестирование. Прошу не спеша подумать и обсудить потом по ВКС. С Наступающим, коллеги!
(Ответ для Anton Farygin на комментарий #26) > Виталий, ты передёргиваешь. > > при установке по URL явно и очевидно видно, что пакет устанавливается из > внешнего источника. А, ну тогда наверное будет достаточно для начала добавить в epm ei предупреждение, что будет установка из внешнего источника? Хоть есть два момента: 1. epm ei в принципе инструмент для установки из внешнего источника (репозитория Korinf), и там не только пакет eepm 2. epm play так же скачивает из внешнего источника. Но мне кажется, что предупреждение для пользователя при epm ei поможет сгладить остроту вопроса.
Полагаю, что да. Но это не отменяет моего предложения. Виталий, а можно где-то ознакомиться с описанием содержимого Коринфа?
Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода приложения?
(Ответ для AEN на комментарий #30) > Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода > приложения? Я согласен с Антоном в том, ято обновление кода в стабильном бранче без тестирования для нас недопустимо. Вместе с тем, обновление внешней базы возможно. Это должно быть явно указано. Наверное, нцдев специальная версия для стабильного бранча, с ограничениями. Любители погорячее могут взять в другом месте, в том числе в Сизифе.
(Ответ для 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 просто короче.
(Ответ для AEN на комментарий #31) > (Ответ для AEN на комментарий #30) > > Правильно ли я понимаю, что epm ei это обновление базы epm, а не кода > > приложения? > Я согласен с Антоном в том, ято обновление кода в стабильном бранче без > тестирования для нас недопустимо. Вместе с тем, обновление внешней базы > возможно. Это должно быть явно указано. > Наверное, нцдев специальная версия для стабильного бранча, с ограничениями. > Любители погорячее могут взять в другом месте, в том числе в Сизифе. Я надеюсь решить этот вопрос прохождением актуальной версии eepm в стабильные бранчи. С другой стороны, вся ситуация связана только с излишними требованиями QA к функциональности приложения в той части, которая связана с априори неопределённым поведением — установки последних версий пакетов сторонних поставщиков. То есть сначала созданы условия для того, чтобы пакет не попал в репозиторий, а потом мы героически решаем эту проблему и боремся с тем, что пользователям всё же нужна актуальная версия, пытаемся создать им неудобства. Считаю изначальную постановку проблемы в этой баге надуманной, а поломки устанавливаемости, аналогичные заявленной в в bug #44183 исключёнными тем, что перед релизом eepm выполняется проверка устанавливаемости всех приложений.
Мы обсудили с aen@ в телефонном разговоре и я подготовлю решение по отключению epm ei для стабильных бранчей.
У меня несколько отстранённое видение по поводу обсуждаемого сложилось. Предлагаю разделить сущности - инструмент и список источников для установки, в том числе и самого 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.
(Ответ для 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 в собираемых просто.
Евгений, мне кажется, Вы не учитываете существенную разницу между назначением и ответственностью за стабильные продукты и проекты в разработке.
Я прошу дождаться рассказа Виталия о нашем разговоре. В его трактовке. Спасибо.
(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 до начала скачивания пакетов.
(Ответ для 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 до начала > скачивания пакетов. Это, кстати, проблема - если кто-то перегенерил хеши апта, то отличить подписанные нами пакеты от неподписанных уже невозможно.
(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 до начала > > скачивания пакетов. > > Это, кстати, проблема - если кто-то перегенерил хеши апта, то отличить > подписанные нами пакеты от неподписанных уже невозможно. От подписи самих пакетов толку мало. Например, пакет, собранный год назад, сейчас уже может содержать известные уязвимости и быть неподлежащим установке. Есть целый класс атак, в котором пользователю специально подсовывают старый уязвимый, но при этом подписанный софт. Поэтому подпись имеет смысл только на репозитории. Если кто-то перегенерил подпись репозитория, то это уже другой репозиторий.
А проверка по версии на уязвимости - это отдельная задача, мы её сейчас решаем. Ну и вторая проблема - в уже установленной системе нет репозитория (соответственно нет проверки подписи репозитория), и так же можно оставить старую версию ПО через Hold. Но при этом действительно криптографически стойкой offline валидации того, что пакет собран у нас на сборочнице сейчас нет (online я могу реализовать быстро).
На данный момент при использовании пакета из репозитория в системе на стабильном бранче (не на Сизифе) команда 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 с этим исправлением.
(Ответ для Dmitry V. Levin на комментарий #41) ... > От подписи самих пакетов толку мало. Например, пакет, собранный год назад, > сейчас уже может содержать известные уязвимости и быть неподлежащим > установке. Есть целый класс атак, в котором пользователю специально > подсовывают старый уязвимый, но при этом подписанный софт. Поэтому подпись > имеет смысл только на репозитории. Если кто-то перегенерил подпись > репозитория, то это уже другой репозиторий. Тем не менее хотелось бы иметь способ узнать происхождение пакета: взят ли он из репозитория (в том числе конкретного стабильного репозитория), а в идеале бы ещё и знать, что пакет прошёл QA. Наверное, можно принять допущение, что при этом пакет имеет актуальную версию (последнюю) и установлен из подписанного репозитория.
(In reply to Vitaly Lipatov from comment #44) > (Ответ для Dmitry V. Levin на комментарий #41) > ... > > От подписи самих пакетов толку мало. Например, пакет, собранный год назад, > > сейчас уже может содержать известные уязвимости и быть неподлежащим > > установке. Есть целый класс атак, в котором пользователю специально > > подсовывают старый уязвимый, но при этом подписанный софт. Поэтому подпись > > имеет смысл только на репозитории. Если кто-то перегенерил подпись > > репозитория, то это уже другой репозиторий. > Тем не менее хотелось бы иметь способ узнать происхождение пакета: Непонятно, какая от этого могла бы быть польза. Впрочем, это лучше выносить отсюда в devel@, наверное.
(Ответ для Dmitry V. Levin на комментарий #39) > По сути единственный надёжный и поддерживаемый метод проверки источника - > это проверка подписи base/release, которую выполняет apt до начала > скачивания пакетов. А он, случаем, не единственный вообще реализованный технически? Просто кто-то, кажется, Денис, говорил, что rpm у нас не проверяет подписи, поскольку эта задача возложена на apt. Если это действительно так, то тут есть противоречие: за аутентичность пакетов отвечает только apt, но apt — не единственный способ установки пакетов.
(Ответ для Vitaly Lipatov на комментарий #5) > А есть какие пруфы, что пользователь понимает, и что подразумевает? Я Есть. https://t.me/alt_linux/353358 > достаточно слежу за группой ALT Linux в Телеграме > и не мог бы сделать таких выводов. Видимо, этого недостаточно. В p10 проблема ещё не исправлена.
(Ответ для Vitaly Lipatov на комментарий #5) > Поскольку инструмент и рецепт перепаковки находится в пакете eepm, для > устранения регрессий его требуется обновлять. (Ответ для Vitaly Lipatov на комментарий #1) > Это как с антивирусными > базами. Никому не придёт в голову иметь в репозитории стабильную версию баз > сигнатур вирусов. А нельзя ли, в самом деле, поступить так, как с антивирусными базами? Пусть инструмент перепаковки находится в пакете eepm, обновляется редко, проходит проверку перед попаданием в бранч и устанавливается только из прошедшего проверку пакета. А рецепты, напротив, располагаются вне пакета, обновляются часто и загружаются напрямую с сайта разработчика этих рецептов (Этерсофт)?
(Ответ для manowar@altlinux.org на комментарий #48) > часто и загружаются напрямую с сайта разработчика этих рецептов (Этерсофт)? Без проверки, чтоб потом выполняться от root?
ИМХО тут не тестирование, а больше code review тогда нужен. И проверка статическим анализатором. Выявление уязвимостей вообще непростая задача, она не решается службой QA в одиночку.
А мы не можем сделать так, чтобы epm работал бы в выделенном чруте? Как всякие там Flatpack делают и прочее? Потому что основная проблема, на мой взгляд, это всё-таки проприетарщина прямо в системе, а не установочные скрипты от Этерсофт.
(Ответ для manowar@altlinux.org на комментарий #50) > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > не решается службой QA в одиночку. Это не отменяет непроверенную загрузку непойми чего непойми откуда.
(Ответ для Sergey V Turchin на комментарий #52) > (Ответ для manowar@altlinux.org на комментарий #50) > > ИМХО тут не тестирование, а больше code review тогда нужен. И проверка > > статическим анализатором. Выявление уязвимостей вообще непростая задача, она > > не решается службой QA в одиночку. > Это не отменяет непроверенную загрузку непойми чего непойми откуда. Можно конкретно? Пример "непойми чего непойми откуда" с epm play.
(Ответ для AEN на комментарий #53) > Пример "непойми чего непойми откуда" с epm play. MITM
(Ответ для Sergey V Turchin на комментарий #54) > (Ответ для AEN на комментарий #53) > > Пример "непойми чего непойми откуда" с epm play. > MITM Я просил конкретный пример с epm play.
(Ответ для AEN на комментарий #55) > Я просил конкретный пример с epm play. Любой. Каждый. Все. Мне это очевидно как не-специалисту. Хотите более страшных подробностей -- проконсультируйтесь у специалиста.
(Ответ для Sergey V Turchin на комментарий #56) > (Ответ для AEN на комментарий #55) > > Я просил конкретный пример с epm play. > Любой. Каждый. Все. > > Мне это очевидно как не-специалисту. Хотите более страшных подробностей -- > проконсультируйтесь у специалиста. Извините, это пустые слова.
(Ответ для AEN на комментарий #57) > Извините, это пустые слова. Не суть. Факта они не отменяют.
(Ответ для 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
(Ответ для 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
Баг был не исправлен, а замаскирован исключительно для Sisyphus https://git.altlinux.org/gears/e/eepm.git?p=eepm.git;a=commit;h=3d87c08e753c3e674919d2cba73339d9d36ff2b6
(Ответ для Sergey V Turchin на комментарий #61) > Баг был не исправлен, а замаскирован исключительно для Sisyphus Извиняюсь, "исправлен" был, но у меня он считает, что у меня "p10" на Сизифе.
(Ответ для 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% случаях загрузки из внешних источников нет никаких проверок то ли что хотелось получено.
(Ответ для 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% случаях загрузки из внешних > источников нет никаких проверок то ли что хотелось получено. Это пустые слова. та самая болтология . Приведи конкретный пример, когда программа загружается из левого источника. Нет примера, -- разговор ни о чем.
(Ответ для Sergey V Turchin на комментарий #54) > (Ответ для AEN на комментарий #53) > > Пример "непойми чего непойми откуда" с epm play. > MITM Нормальный протокол обновления предполагает проверку загрузчиком подписи тех файлов, которые скачиваются. Вот реально, как с антивирусными базами. Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит в себе неплохой план решения проблемы: отделение часто обновляемых скриптов от редко обновляемого ядра. По крайней мере, в качестве первого шага.
(Ответ для manowar@altlinux.org на комментарий #65) > Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит > в себе неплохой план решения проблемы: отделение часто обновляемых скриптов > от редко обновляемого ядра. По крайней мере, в качестве первого шага. Кажется, это выглядит как необходимость ещё не-одной дополнительной проверки, а отдел тестирования прогуливается в соседнем лесу.
(Ответ для manowar@altlinux.org на комментарий #65) > (Ответ для Sergey V Turchin на комментарий #54) > > (Ответ для AEN на комментарий #53) > > > Пример "непойми чего непойми откуда" с epm play. > > MITM > > Нормальный протокол обновления предполагает проверку загрузчиком подписи тех > файлов, которые скачиваются. Вот реально, как с антивирусными базами. > > Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит > в себе неплохой план решения проблемы: отделение часто обновляемых скриптов > от редко обновляемого ядра. По крайней мере, в качестве первого шага. Подпись, боюсь, не всегда есть Проверять контрольную сумму -- да, надо. Обычно она есть на сайте вендора, с которого и идёт скачивание.
Мы договорились о том, что тестирование всех вариантов загрузки для eepm play не проводится, т.к. это сильно затратный по времени и ресурсам процесс с непредсказуемыми последствиями - сейчас загрузка идёт из внешних источников и она может сломаться по причине смены архивов на этих внешних источниках. Т.е. - архитектурно решение сделано так, что оно может работать а может не работать и гарантировать ничего в этом невозможно.
(Ответ для AEN на комментарий #67) > Проверять контрольную сумму -- да, надо. > Обычно она есть на сайте вендора, с которого и идёт скачивание. А у неё есть подпись или контрольная сумма? ;-)
Бага https://bugzilla.altlinux.org/48465 об этом. Предлагаю перейти туда.
(Ответ для AEN на комментарий #67) > (Ответ для manowar@altlinux.org на комментарий #65) > > (Ответ для Sergey V Turchin на комментарий #54) > > > (Ответ для AEN на комментарий #53) > > > > Пример "непойми чего непойми откуда" с epm play. > > > MITM > > > > Нормальный протокол обновления предполагает проверку загрузчиком подписи тех > > файлов, которые скачиваются. Вот реально, как с антивирусными базами. > > > > Возможно, что Виталий привёл этот пример навскидку, но по-моему, он содержит > > в себе неплохой план решения проблемы: отделение часто обновляемых скриптов > > от редко обновляемого ядра. По крайней мере, в качестве первого шага. > > Подпись, боюсь, не всегда есть > Проверять контрольную сумму -- да, надо. > Обычно она есть на сайте вендора, с которого и идёт скачивание. Я имел в виду, что если epm будет самостоятельно обновлять установочные скрипты с сайта Этерсофт, то эти скрипты должны быть подписаны. Проверка пакетов с сайта вендора — это отдельная задача и проблема. Эта бага — про процедуру обновления самого epm, насколько я понимаю.
(Ответ для manowar@altlinux.org на комментарий #71) > Эта бага — про процедуру обновления самого epm, насколько я понимаю. Да. И в p10 она до сих пор не исправлена.
(Ответ для 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 не будет обновлено.
(Ответ для Alexander Makeenkov на комментарий #73) > В p10 сейчас: Извиняюсь, проглядел, исправлена.
