[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