[devel] __libc_enable_secure в openssl libcrypto

[Mikhail Novosyolov]

27.04.2020 11:56, Michael Shigorin пишет:
> On Mon, Apr 27, 2020 at 11:30:47AM +0300, Mikhail Novosyolov wrote:
>> Единственным выходом из ситуации я вижу попытки рекомендовать
>> разработчикам собирать универсальные исполняемые файлы или
>> пакеты с грамотно сбандленными библиотеками и грамотно
>> прописанные зависимости в RPM, например, не libgnomekeyring,
>> a libgnome-keyring.so.0()(64bit).
> Тянет на небольшой образовательный центр, как мне кажется.
> Хотя ИСП РАН может оказаться при делах, глядишь, сделают
> "русский LSB" ;-)

Звучит прикольно, но вряд ли осуществимо и интересно всем сторонам в достаточной степени.

Да и решение проблемы нужно еще вчера, а не очередной стандарт.

>
>> Была мысль, что многим будет гораздо проще не изобретать
>> сложную систему сборки с частичной статической линковкой,
>> а собирать с системными библиотеками в какой-нибудь ОС,
>> а затем упаковывать AppImage, это очень просто.
> Чревато невоспроизводимостью, поскольку будет искушать
> что-нить напихать/допилить вручную (особенно в аврал).

Воспроизводимость зависит только от желания сделать воспроизводимым.

>
>> AppImage-подобную структуру можно положить в RPM-пакет,
>> зная про AutoReq, AutoProv и др. И вот здесь встает вопрос,
>> насколько помешают такие фокусы. Соберут в Альте - не
>> заработает в других дистрибутивах. Тот же openssl настолько
>> часто используется и однозначно будет сбандливаться, что Альт
>> можно сразу не рекомендовать для сборки AppImage-подобных
>> пакетов. А вот если собрать ПО на другом дистрибутиве, то есть
>> небольшая вероятность возникновения проблем в Альте.
> Думаю так:
>
> - если тяп-ляп, то собирать надёжней всего на чём-то вроде
>   centos6 -- оно достаточно дубовое и консервативное по части
>   ABI, чтобы на обратной совместимости работало более-менее
>   везде (варианты сборки под более развесистые/заточенные
>   наборы интерфейсов мне кажутся прогрессирующей рулеткой);

Думаю, пытаться стандартизировать сборочную среду не нужно, т.к. потребности разные, одно дело собрать hello world, другое дело - что-то сложное и требующее поддержку современных стандартов C++, например.

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

> - если учиться делать по уму, то учиться собирать "нативно"
>   (в плане ABI) на альте весьма полезно для получения заодно
>   и покрытия автоматическим контролем качества упаковки
>   от нашего инструментария -- что может быть полезно на
>   любом другом как минимум линуксе.
>
> Кстати, Вы слышали про http://wiki.etersoft.ru/korinf?

Нет (или забыл), но видел реализацию в wine на etersoft.  Собирать кучу разных пакетов vitlav@ легко, потому что он в этом хорошо разбирается, а вот для типового разработчика ПО это очень сложная процедура, ему надо собрать один раз и чтобы работало везде. И не по RPM под каждый дистрибутив, а один универсальный RPM + DEB + AppImage/tgz.

(если бы кто-нибудь разработчкам разного ПО рассказал про %_build_binary_file_digest_algo 1, то в p8 не мучились бы так сильно с зависимостями от rpmlib)