[devel] Q: gostcrypto howto
Vladimir D. Seleznev
vseleznv на altlinux.org
Пн Дек 9 22:10:24 MSK 2019
On Mon, Dec 09, 2019 at 08:35:30PM +0300, Mikhail Novosyolov wrote:
> 03.12.2019 01:15, Dmitry V. Levin пишет:
>
> >
> > В openssh поддержка gost реализована посредством динамической загрузки
> > алгоритмов, что, с одной стороны, правильно, но, с другой стороны,
> > мне бы этого не хотелось в том openssh, которым я пользуюсь.
> >
> В LibreSSL, у которой общий с OpenSSH апстрим, есть поддержка
> ГОСТ-ов. Технически не проблема собрать openssh с libressl вместо
> openssl, у libtls, libssl, libcrypto из opensls и libressl одинаковые
> so name, но разные мажорные версии, поэтому они нормально уживаются
> рядом с друг другом.
У libssl и libcrypto из OpenSSL и LibreSSL разные soname'ы:
$ objdump -x /lib64/libcrypto.so.1.1 |grep SONAME
SONAME libcrypto.so.1.1
$ objdump -x /lib64/libssl.so.1.1 |grep SONAME
SONAME libssl.so.1.1
$ objdump -x /usr/lib64/libcrypto.so.45 |grep SONAME
SONAME libcrypto.so.45
$ objdump -x /usr/lib64/libssl.so.47 |grep SONAME
SONAME libssl.so.47
> Это позволит избежать dlopen() внешней библиотеки libgost.so и
> избежать вызова depreceated функций, например,
> OpenSSL_add_all_algorithms(). С учетом близости близости апстримов
> libressl и openssh не вижу особой проблемы в применении альтернативной
> libssl.
>
> А не могли бы Вы пояснить, чем динамическая загрузка алгоритмов
> "правильна" и почему не хотелось бы ее иметь в своем openssh?
По-моему, динамическая подгрузка алгоритмов — неправильное решение.
> Мне не нравится идея подгружать внешние библиотеки в таком компоненте,
> как ssh, но затрудняюсь придумать хорошее обоснование. На ум приходят,
> например, потенциальные сложности с chroot, selinux (в
> openssh-gostcryptro нет правок чрутования для прокидывания libgost.so
> в chroot, интересно, как это должно работать).
--
С уважением,
Владимир Селезнев
Подробная информация о списке рассылки Devel