[devel] I: SharedLibsPolicy update (libjxl update)

Ср Фев 28 23:03:45 MSK 2024

В Wed, 28 Feb 2024 00:17:37 +0300
Vitaly Lipatov <lav на altlinux.ru> пишет:

> Anton Farygin писал(а) 23.2.24 12:56:
> ...
> > Думаю что надо добить SharedLibsPolicy до стадии утверждённой политики 
> > и внести проверки на обязательное соответствие policy в сборочную 
> > систему.  
> 
> Согласен, что для массово используемых (т.е. известных) библиотек это 
> просто необходимо, особенно когда они имеют внешних пользователей или 
> стали де факто частью Linux-системы.

  Мне кажется, что нужно более веское обоснование, чем "просто
необходимо". На вики, например, есть такое:

  https://www.altlinux.org/Shared_Libs_Policy_and_updates

  Процитирую. "При проблемах обновления с бранча на бранч возможность
точечных обновлений чрезвычайно расширяется" ... "Например, возможность
обновить один новый пакет foo, зависящий от libexiv2_77 не затронет другой
старый пакет bar, который зависит от старой версии libexiv2_11, которой уже
нет в новом репозитории, но еще есть в системе."

  Кажется, что SharedLibsPolicy должна решить проблему точечных
обновлений. Но с чем на самом деле сталкивается пользователь пакета
bar, решивший поставить foo из нового бранча? В 90% случаев блокер ---
это libc! Из-за того, что foo собран с новой libc, последнюю нужно
обновить, а это значит --- вынести всю или почти всю старую систему,
включая, конечно, и пакет bar. Так для чего заострять внимание на
частной зависимости от libexiv, когда это --- второстепенная проблема?

  В связи с этим, если у наших пользователей есть необходимость
использовать программы из старых бранчей, я бы подумал над тем,
как предоставить им возможность разворачивать старую базовую систему
(p7, p8, p9, ...) в chroot, ставить туда пакеты и запускать эти
программы "бесшовно", то есть на актуальном десктопе. Но это, очевидно,
тема отдельного обсуждения.

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

  Предлагаю сперва разобраться, откуда берутся такие актуальные приложения
и почему мы должны считать их актуальными? Какие здесь возможные причины?

  Если у приложения просто "тормозной" апстрим, то по факту такой проект
почти наверняка неподдерживаемый. Можно ли считать его актуальным?

  Другой вариант: апстрим вполне живой, но он не поспевает за обновлением
библиотеки в Сизифе. На мой взгляд, такая ситуация может означать, что
мэйнтейнер библиотеки в Сизифе слишком торопится её обновлять: к примеру,
собирает development, а не stable версию. Но здесь уместно будет спросить,
а нужно ли так торопиться? Ведь сборка не утверждённой сообществом версии
известной, широко используемой библиотеки приносит с собой (кроме проблем с
совместимостью с приложениями) неизвестные уязвимости. Тут мы подходим к
самому главному.

  Если мы, как пишет Виталий ниже, идём к "необходимости присутствия
в системе всех ожидаемых ими [версий] библиотек (а это может быть и 5-7 лет
существования приложения)", то, очевидно, это будет система, в которой
собраны все известные CVE за 5--7 лет!

  Правда, есть такая штука, как security bugfixes. То есть возможен такой
случай, когда сосуществует несколько версий библиотеки и все эти версии
снабжаются исправлениями безопасности. На мой взгляд, это именно тот
_единственный_ случай, когда допустимо одновременное наличие нескольких
версий известной библиотеки. Однако этот случай также отличается от того,
что советует SharedLibsPolicy. Что на практике означает наличие
security bugfixes для разных версий библиотеки? Это означает, что
апстрим библиотеки, а не только её мэйнтейнер в Сизифе, _поддерживает_
несколько _стабильных_ версий библиотеки: к примеру, текущую и LTS.
Но поддержка многоверсионности такого типа означает, что в Сизифе должно
быть несколько "полноценных" пакетов с разной версией библиттеки:
"полноценных" --- значит, должно быть несколько исходных пакетов,
каждый для своей версии, которые регулярно обновляются. Если я правильно
понял SharedLibsPolicy, то она этого не требует (хотя и не противоречит).

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

  Теперь насчёт сторонних приложений:

> И если при наличии замкнутого репозитория долгое время удавалось это 
> обходить удалением пакетов, обновлением всех под новую версию (с 
> проблемами), то при наличии внешних пользователей к необходимости 
> присутствия в системе всех ожидаемых ими библиотек (а это может быть и 
> 5-7 лет существования приложения) стоит отнестись серьёзнее.
> Например, допускать одновременное существование в репозитории libssl1.1 
> и libssl3.

  Мне кажется относительно "внешних пользователей" библиотеки, то есть
к внешних программ, вполне можно задать те же вопросы, что и
относительно программ внутренних (сизифных). Почему они "запали" на
конкретную (старую) версию библиотеки? Что это означает в смысле CVE?
Должна ли программная платформа потворствовать этому? Не исключено,
конечно, что это мэйнтейнер библиотеки поторопился (собрал devel вместо
stable).

  Мне кажется, что для тех внешних программ, которые _хотят_ собираться
под нашу платформу, вполне логично использовать актуальные версии
библиотек. А для остальных, которых платформа как платформа не
интересует, и которые хотят чтобы "просто работало", вполне допустим,
мне кажется, подход Flatpack (то есть, все библиотеки носит с собой).
Понятно, что такое стороннее приложение, вместе со старыми версиями
библиотек, приносит и известные уязвимости. Но по крайней мере эти
старые библиотеки тогда не являются частью программной платформы.