Re: [devel] RFC: ca-certificates a la Fedora

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]

On Fri, Dec 22, 2017 at 07:33:46PM +0300, Mikhail Efremov wrote:
> On Fri, 22 Dec 2017 03:26:48 +0100 Alexey Gladkov wrote:
> > On Fri, Dec 22, 2017 at 04:28:05AM +0300, Dmitry V. Levin wrote:
> > > > Нету. Плюс появление несовместимости станет блокирокером к обновлению nss,
> > > > что с точке зрения безопасности мне не нравится.
> > > > 
> > > > Если идти по этому пути, то я бы сделал альтернативы для этой библиотеки.  
> > > 
> > > Альтернативы для библиотек -- это вообще плохая идея, я всё никак не
> > > придумаю способа их эффективно запретить.  
> > 
> > Если всё как сказал sem@ и действительно есть полная совместимость, то
> > проблем не будет. Если несовместимость всё-таки появится/может появиться,
> > то пользователи смогут переключиться на апстримную библиотеку (хотя бы
> > временно). Это лучше, чем класть все яйца в одну корзину.
> 
> Если сделать так:
> ln -s /usr/lib64/pkcs11/p11-kit-trust.so /etc/pki/nssdb/libnssckbi.so
> то certutil -L -d sql:/etc/pki/nssdb/ -h 'Builtin Object Token'
> начинает выдавать список сертификатов из p11-kit.

libnssckbi.so в /etc - это оригинально, но по умолчанию в /etc/pki/nssdb
никто не смотрит, так ведь?

[...]
> > > > Ну или альтертантивы для libnssckbi.so.  
> > > 
> > > Либо разные реализации libnssckbi.so окажутся настолько совместимы, что
> > > будет использоваться только одна, либо нет, и тогда придётся использовать
> > > разные реализации одновременно и мы вернёмся к нынешней ситуации.  
> > 
> > Именно, но откат пользователя к апстримной библиотеке мне кажется более
> > удачным вариантом, чем невозможность пользоваться браузером/почтой вообще,
> > в случае, когда вместо libnssckbi.so будет несовместимая библиотека.
> 
> Учитывая, что это не совсем библиотека, насколько я понимаю, т.е. с ней
> никто не линкуется, то может альтернативы и не самый плохой вариант.
> Лучше бы, конечно, убрать ее из nss совсем, заменив ссылкой на
> p11-kit-trust.so, а в случае разлома можно временно вернуть
> libnssckbi.so. Проблема в том, как обнаружить этот разлом.

Я бы сказал, что совсем не библиотека:
$ nm -D /usr/lib64/libnssckbi.so |grep '^[[:xdigit:]]'
0000000000020fb0 T C_GetFunctionList
0000000000000000 A NSS_3.1

Если libnssckbi.so - это не библиотека, то почему она lib*.so,
и почему она упакована непосредственно в %_libdir?
Как её загружают - dlopen'ом?

Получается, что единственное доступное нам решение задачи, чтобы в nss
были те же сертификаты, что и в openssl с gnutls - это заменить
libnssckbi.so, который использует nss, ссылкой на альтернативного
провайдера (/usr/lib64/pkcs11/p11-kit-trust.so), который это реализует.

Можно, конечно, управлять этой ссылкой с помощью механизма альтернатив,
но я не вижу в этом смысла.
Если какая-то версия nss перестанет работать с p11-kit-trust.so, то эту
ссылку придётся временно заменить на файл, поставляемый с libnss, до тех
пор, пока p11-kit-trust.so снова не заработает, после чего ссылку можно
будет вернуть, поставив соответствующие зависимости (в данном случае,
наверное, конфликты).
Чем в этой ситуации поможет механизм альтернатив?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]