[devel] __libc_enable_secure в openssl libcrypto

[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, чтобы на обратной совместимости работало более-менее
  везде (варианты сборки под более развесистые/заточенные
  наборы интерфейсов мне кажутся прогрессирующей рулеткой);

- если учиться делать по уму, то учиться собирать "нативно"
  (в плане ABI) на альте весьма полезно для получения заодно
  и покрытия автоматическим контролем качества упаковки
  от нашего инструментария -- что может быть полезно на
  любом другом как минимум линуксе.

Кстати, Вы слышали про http://wiki.etersoft.ru/korinf?

> Думаю, что нужно сильно постараться, чтобы их поймать, т.к.
> внутренний API __libc_enable_secure заведомо не стоит
> использовать, но, может быть, есть другие подобные нюансы.

Ещё у нас ncurses была на что-то из glibc завязана, помнится.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info