[devel] RFC: ca-certificates a la Fedora

[devel] RFC: ca-certificates a la Fedora

[Mikhail Efremov]

Hello!

Я сейчас готовлю ca-certificates (сегодня сделаю тестовое задание) с
использованием p11-kit (https://p11-glue.freedesktop.org/), как в
Федоре.
Их схема выглядит вполне разумной, скрипт на питоне для генерации
p11-kit-бандла я тоже взял из Федоры (там есть часть про legacy trust,
которая у нас не актуальна, но она не мешает и проще оставить, чем
выкидывать).
При использовании этой схемы, добавление дополнительных CA сертификатов
(или blacklist неугодных), становится очень простым делом.
Пакеты ca-gost-certificates и ca-gost-certificates-auc должны будут
просто положить сертификаты, которым нужно доверять,
в /usr/share/pki/ca-trust-source/anchors/ (можно прям в DER формате)
и больше не делать ничего.
Это должно работать с openssl и gnutls, а вот с nss проблема: я так
понимаю, что nss использует собственный бандл, а не системный, и
использует libnssckbi.so для работы с ним. В p11-kit используется модуль
pkcs11/p11-kit-trust.so и утверждается, что он бинарно совместим с
libnssckbi.so, так что в Федоре некоторое время имели модули
libnssckbi.so и p11-kit-trust.so на альтернативах, а сейчас просто
выкинули libnssckbi.so из nss
(https://bugzilla.redhat.com/show_bug.cgi?id=1484449).
Но даже если про бинарную совместимость - это правда, то у меня есть
сомнения, что это всегда будет так в следующих версиях nss и p11-kit и
нас нет автоматической проверки таких вещей при сборке.
Но вообще хорошо бы заставить nss использовать p11-kit-trust.so вместо
libnssckbi.so, тогда у нас действительно будет единое место для
хранения CA сертификатов. Эту проблему придется как-то решать.
В первую очередь мне бы хотелось услышать комментарии от lakostis@,
который уже несколько лет поддерживает ca-certificates в актуальном
состоянии, и legion@, как мантейнера libnss.

-- 
WBR, Mikhail Efremov

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

[Mikhail Efremov]

On Thu, 21 Dec 2017 18:48:16 +0300 Mikhail Efremov wrote:
> Hello!
> 
> Я сейчас готовлю ca-certificates (сегодня сделаю тестовое задание) с

#197295

- 
WBR, Mikhail Efremov

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

[Mikhail Efremov]

On Fri, 22 Dec 2017 02:21:33 +0300 Mikhail Efremov wrote:
> On Thu, 21 Dec 2017 18:48:16 +0300 Mikhail Efremov wrote:
> > Hello!
> > 
> > Я сейчас готовлю ca-certificates (сегодня сделаю тестовое задание)
> > с  
> 
> #197295

Таск обновлен:
update-ca-trust вынесен в отдельный пакет ca-trust, в ca-certificates
остался только бандл в формате p11-kit. Кроме того update-ca-trust
теперь просто запускает хуки /usr/libexec/ca-trust/update.d/*.hook,
которые и выполняют всю работу. Подпакет ca-trust-java заменяет
ca-certificates-java с его сертификатами 2011 года.
В p11-kit-trust запакована альтернатива для libnssckbi.so с весом 30,
соответственно в libnss должна быть альтернатива с весом меньше.
Подпакет p11-kit-checkinstall в %post выполняет проверку на
совместимость libnssckbi.so и p11-kit-trust.so, сравниваются списки
названий выводимых сертификатов. Но ошибка в %post не мешает установить
пакет, так что узнать о проблеме можно только из лога. Там надо что-то
писать если проверка успешна, кстати?
В пакете libnss-checkinstall нужно будет просто поставить зависимость
на p11-kit-checkinstall.
Я расшарил таск, там еще должны быть как минимум libnss с альтернативой
и ca-gost-certificates*.
Впрочем, текущий вариант еще может быть не окончательным, конечно.

2lav@: Я не хочу сам трогать пакеты с гостовыми сертификатами, я ничего
в них не понимаю.

-- 
WBR, Mikhail Efremov

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

[Dmitry V. Levin]

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

On Fri, Dec 29, 2017 at 06:38:37PM +0300, Mikhail Efremov wrote:
> On Fri, 22 Dec 2017 02:21:33 +0300 Mikhail Efremov wrote:
> > On Thu, 21 Dec 2017 18:48:16 +0300 Mikhail Efremov wrote:
> > > Hello!
> > > 
> > > Я сейчас готовлю ca-certificates (сегодня сделаю тестовое задание)
> > > с  
> > 
> > #197295
> 
> Таск обновлен:
> update-ca-trust вынесен в отдельный пакет ca-trust, в ca-certificates
> остался только бандл в формате p11-kit. Кроме того update-ca-trust
> теперь просто запускает хуки /usr/libexec/ca-trust/update.d/*.hook,
> которые и выполняют всю работу. Подпакет ca-trust-java заменяет
> ca-certificates-java с его сертификатами 2011 года.

Наконец-то!

> В p11-kit-trust запакована альтернатива для libnssckbi.so с весом 30,
> соответственно в libnss должна быть альтернатива с весом меньше.
> Подпакет p11-kit-checkinstall в %post выполняет проверку на
> совместимость libnssckbi.so и p11-kit-trust.so, сравниваются списки
> названий выводимых сертификатов. Но ошибка в %post не мешает установить
> пакет, так что узнать о проблеме можно только из лога.

При ошибке в %post пакет устанавливается, но rpm должен завершаться
с ненулевым статусом, означающим, что что-то пошло не так.

По крайней мере, старый добрый rpm вёл себя именно так.

> Там надо что-то писать если проверка успешна, кстати?

Зачем?

> В пакете libnss-checkinstall нужно будет просто поставить зависимость
> на p11-kit-checkinstall.
> Я расшарил таск, там еще должны быть как минимум libnss с альтернативой
> и ca-gost-certificates*.

Обновление пакета filesystem тоже туда добавить, или отправить отдельно?


-- 
ldv

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

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

[Dmitry V. Levin]

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

On Fri, Dec 29, 2017 at 06:53:38PM +0300, Dmitry V. Levin wrote:
> On Fri, Dec 29, 2017 at 06:38:37PM +0300, Mikhail Efremov wrote:
> > On Fri, 22 Dec 2017 02:21:33 +0300 Mikhail Efremov wrote:
> > > On Thu, 21 Dec 2017 18:48:16 +0300 Mikhail Efremov wrote:
> > > > Hello!
> > > > 
> > > > Я сейчас готовлю ca-certificates (сегодня сделаю тестовое задание)
> > > > с  
> > > 
> > > #197295
> > 
> > Таск обновлен:
> > update-ca-trust вынесен в отдельный пакет ca-trust, в ca-certificates
> > остался только бандл в формате p11-kit. Кроме того update-ca-trust
> > теперь просто запускает хуки /usr/libexec/ca-trust/update.d/*.hook,
> > которые и выполняют всю работу. Подпакет ca-trust-java заменяет
> > ca-certificates-java с его сертификатами 2011 года.
> 
> Наконец-то!
> 
> > В p11-kit-trust запакована альтернатива для libnssckbi.so с весом 30,
> > соответственно в libnss должна быть альтернатива с весом меньше.
> > Подпакет p11-kit-checkinstall в %post выполняет проверку на
> > совместимость libnssckbi.so и p11-kit-trust.so, сравниваются списки
> > названий выводимых сертификатов. Но ошибка в %post не мешает установить
> > пакет, так что узнать о проблеме можно только из лога.
> 
> При ошибке в %post пакет устанавливается, но rpm должен завершаться
> с ненулевым статусом, означающим, что что-то пошло не так.
> 
> По крайней мере, старый добрый rpm вёл себя именно так.
> 
> > Там надо что-то писать если проверка успешна, кстати?
> 
> Зачем?
> 
> > В пакете libnss-checkinstall нужно будет просто поставить зависимость
> > на p11-kit-checkinstall.
> > Я расшарил таск, там еще должны быть как минимум libnss с альтернативой
> > и ca-gost-certificates*.
> 
> Обновление пакета filesystem тоже туда добавить, или отправить отдельно?

При добавлении каталогов /etc/pki и /usr/share/pki в пакет filesystem
все остальные пакеты должны перестать это делать, иначе sisyphus_check
найдёт в них filesystem intersections.


-- 
ldv

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

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

[Mikhail Efremov]

On Fri, 29 Dec 2017 19:08:26 +0300 Dmitry V. Levin wrote:
> On Fri, Dec 29, 2017 at 06:53:38PM +0300, Dmitry V. Levin wrote:
> > On Fri, Dec 29, 2017 at 06:38:37PM +0300, Mikhail Efremov wrote:  
> > > В p11-kit-trust запакована альтернатива для libnssckbi.so с весом
> > > 30, соответственно в libnss должна быть альтернатива с весом
> > > меньше. Подпакет p11-kit-checkinstall в %post выполняет проверку
> > > на совместимость libnssckbi.so и p11-kit-trust.so, сравниваются
> > > списки названий выводимых сертификатов. Но ошибка в %post не
> > > мешает установить пакет, так что узнать о проблеме можно только
> > > из лога.  
> > 
> > При ошибке в %post пакет устанавливается, но rpm должен завершаться
> > с ненулевым статусом, означающим, что что-то пошло не так.
> > 
> > По крайней мере, старый добрый rpm вёл себя именно так.

А, я не посмотрел с каким статусом завершился rpm.
   
> > > Там надо что-то писать если проверка успешна, кстати?  
> > 
> > Зачем?

Ну, я и не стал. Но мало ли, может грепать удобно.

> > > В пакете libnss-checkinstall нужно будет просто поставить
> > > зависимость на p11-kit-checkinstall.
> > > Я расшарил таск, там еще должны быть как минимум libnss с
> > > альтернативой и ca-gost-certificates*.  
> > 
> > Обновление пакета filesystem тоже туда добавить, или отправить
> > отдельно?  
> 
> При добавлении каталогов /etc/pki и /usr/share/pki в пакет filesystem
> все остальные пакеты должны перестать это делать, иначе sisyphus_check
> найдёт в них filesystem intersections.

В ca-trust они не пакуются, /etc/pki принадлежит libnss. Можно
действительно filesystem в тот же таск для ясности.

-- 
WBR, Mikhail Efremov

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

[Mikhail Efremov]

On Fri, 29 Dec 2017 18:38:37 +0300 Mikhail Efremov wrote:
> On Fri, 22 Dec 2017 02:21:33 +0300 Mikhail Efremov wrote:
> > On Thu, 21 Dec 2017 18:48:16 +0300 Mikhail Efremov wrote:  
> > > Hello!
> > > 
> > > Я сейчас готовлю ca-certificates (сегодня сделаю тестовое задание)
> > > с    
> > 
> > #197295  
> 
> Таск обновлен:

Я еще немного протестирую и завтра (точнее уже сегодня) отправлю таск в
Сизиф, видимо.

> 2lav@: Я не хочу сам трогать пакеты с гостовыми сертификатами, я
> ничего в них не понимаю.

Эти пакеты можно будет переделать позже, думаю не стоит их ждать.

-- 
WBR, Mikhail Efremov

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

[Mikhail Efremov]

On Wed, 10 Jan 2018 02:22:38 +0300 Mikhail Efremov wrote:
> On Fri, 29 Dec 2017 18:38:37 +0300 Mikhail Efremov wrote:
> > On Fri, 22 Dec 2017 02:21:33 +0300 Mikhail Efremov wrote:  
> > > On Thu, 21 Dec 2017 18:48:16 +0300 Mikhail Efremov wrote:    
> > > > Hello!
> > > > 
> > > > Я сейчас готовлю ca-certificates (сегодня сделаю тестовое
> > > > задание) с      
> > > 
> > > #197295    
> > 
> > Таск обновлен:  
> 
> Я еще немного протестирую и завтра (точнее уже сегодня) отправлю таск
> в Сизиф, видимо.

Кстати, пакеты firefox-gost и newmoon-base таскают с собой свои
собственные libnss вместе с libnssckbi.so. Я не знаю насколько им
действительно нужна своя libnss, но возможно хотя бы libnssckbi.so
стоит использовать системную.

> > 2lav@: Я не хочу сам трогать пакеты с гостовыми сертификатами, я
> > ничего в них не понимаю.  
> 
> Эти пакеты можно будет переделать позже, думаю не стоит их ждать.
> 


-- 
WBR, Mikhail Efremov

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

[Ivan Zakharyaschev]

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


On Wed, 10 Jan 2018, Mikhail Efremov wrote:

> Кстати, пакеты firefox-gost и newmoon-base таскают с собой свои
> собственные libnss вместе с libnssckbi.so. Я не знаю насколько им
> действительно нужна своя libnss, но возможно хотя бы libnssckbi.so
> стоит использовать системную.

Там почти весь патч как раз на security/nss/lib/ (но не знаю насчёт 
того, затрагивается ли libnssckbi.so):

$ grep '^+++ ' firefox-cryptopro-gost_patch45.patch
+++ b/browser/branding/unofficial/branding.nsi	Thu Jul 07 18:22:25 2016 
+0400
+++ b/browser/branding/unofficial/configure.sh	Thu Jul 07 18:22:25 2016 
+0400
+++ b/browser/branding/unofficial/locales/en-US/brand.dtd	Thu Jul 07 
18:22:25 2016 +0400
+++ b/browser/branding/unofficial/locales/en-US/brand.properties 
Thu Jul 07 18:22:25 2016 +0400
+++ b/browser/installer/windows/nsis/installer.nsi	Thu Jul 07 
18:22:25 2016 +0400
+++ b/browser/installer/windows/nsis/maintenanceservice_installer.nsi 
Thu Jul 07 18:22:25 2016 +0400
+++ b/browser/installer/windows/nsis/shared.nsh	Thu Jul 07 18:22:25 2016 
+0400
+++ b/browser/installer/windows/nsis/uninstaller.nsi	Thu Jul 07 
18:22:25 2016 +0400
+++ b/netwerk/base/nsICryptoHash.idl	Thu Jul 07 18:22:25 2016 +0400
+++ b/netwerk/base/security-prefs.js	Thu Jul 07 18:22:25 2016 +0400
+++ b/netwerk/mime/nsMimeTypes.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/apps/AppTrustDomain.cpp	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/apps/AppTrustDomain.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/certverifier/ExtendedValidation.cpp	Thu Jul 07 
18:22:25 2016 +0400
+++ b/security/certverifier/NSSCertDBTrustDomain.cpp	Thu Jul 07 
18:22:25 2016 +0400
+++ b/security/certverifier/NSSCertDBTrustDomain.h	Thu Jul 07 
18:22:25 2016 +0400
+++ b/security/manager/ssl/SSLServerCertVerification.cpp	Thu Jul 07 
18:22:25 2016 +0400
+++ b/security/manager/ssl/nsCryptoHash.cpp	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/manager/ssl/nsKeygenHandler.cpp	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/manager/ssl/nsNSSCallbacks.cpp	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/manager/ssl/nsNSSComponent.cpp	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/certdb/certdb.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/certdb/certt.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/certdb/stanpcertdb.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/cryptohi/keyhi.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/cryptohi/keythi.h	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/cryptohi/sechash.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/cryptohi/sechash.h	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/cryptohi/seckey.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/cryptohi/secsign.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/cryptohi/secvfy.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/nss/nss.def	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/nss/nssinit.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/pk11wrap/pk11akey.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pk11wrap/pk11cert.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pk11wrap/pk11mech.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pk11wrap/pk11obj.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pk11wrap/pk11pub.h	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pk11wrap/pk11skey.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pk11wrap/pk11slot.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/pkcs7/secmime.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/smime/cmscipher.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/smime/cmslocal.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/smime/cmspubkey.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/smime/cmsrecinfo.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/smime/smimeutil.c	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/nss/lib/ssl/derive.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/ssl.def	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/ssl.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/ssl3con.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/ssl3ext.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/ssl3prot.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslenum.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslimpl.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslinfo.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslproto.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslsecur.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslsock.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/ssl/sslt.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/util/Makefile	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/util/ciferfam.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/util/hasht.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/util/pkcs11t.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/util/secoid.c	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/nss/lib/util/secoidt.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/include/pkix/pkixnss.h	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/pkix/include/pkix/pkixtypes.h	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/pkix/lib/pkixbuild.cpp	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/lib/pkixcheck.cpp	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/lib/pkixder.cpp	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/lib/pkixder.h	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/lib/pkixnss.cpp	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/lib/pkixverify.cpp	Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/test/gtest/pkixbuild_tests.cpp	Thu Jul 07 
18:22:25 2016 +0400
+++ b/security/pkix/test/gtest/pkixcert_signature_algorithm_tests.cpp 
Thu Jul 07 18:22:25 2016 +0400
+++ b/security/pkix/test/gtest/pkixgtest.h	Thu Jul 07 18:22:25 2016 
+0400
+++ b/security/pkix/test/gtest/pkixocsp_CreateEncodedOCSPRequest_tests.cpp 
Thu Jul 07 18:22:25 2016 +0400
$


-- 
Best regards,
Ivan

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

[Alexey Gladkov]

On Thu, Dec 21, 2017 at 06:48:16PM +0300, Mikhail Efremov wrote:
> Hello!
> 
> Это должно работать с openssl и gnutls, а вот с nss проблема: я так
> понимаю, что nss использует собственный бандл, а не системный, и
> использует libnssckbi.so для работы с ним. В p11-kit используется модуль
> pkcs11/p11-kit-trust.so и утверждается, что он бинарно совместим с
> libnssckbi.so, так что в Федоре некоторое время имели модули
> libnssckbi.so и p11-kit-trust.so на альтернативах, а сейчас просто
> выкинули libnssckbi.so из nss
> (https://bugzilla.redhat.com/show_bug.cgi?id=1484449).
> Но даже если про бинарную совместимость - это правда, то у меня есть
> сомнения, что это всегда будет так в следующих версиях nss и p11-kit и
> нас нет автоматической проверки таких вещей при сборке.

Нету. Плюс появление несовместимости станет блокирокером к обновлению nss,
что с точке зрения безопасности мне не нравится.

Если идти по этому пути, то я бы сделал альтернативы для этой библиотеки.

Кроме того, в nssckbi встроенная база Root CA Certificate поддерживается в
актуальном состоянии Mozilla.

В тоже время

#
# ALT CA
#
         
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, O=ALT Linux Team, OU=ALT Certification Authority, CN=ALT Root Certification Authority/emailAddress=ca-root@altlinux.org
        Validity
            Not Before: Jan  1 00:00:00 2007 GMT
            Not After : Jan  1 00:00:00 2017 GMT
        Subject: C=RU, O=ALT Linux Team, OU=ALT Certification Authority, CN=ALT Root Certification Authority/emailAddress=ca-root@altlinux.org

И вот `Not After : Jan  1 00:00:00 2017 GMT` вселяет сомнения в таком же
уровне поддержки.

> libnssckbi.so, тогда у нас действительно будет единое место для
> хранения CA сертификатов. Эту проблему придется как-то решать.

На мой взгляд правильный путь это добавление сертификатов в базу nss.

https://wiki.mozilla.org/NSS_Shared_DB
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Ну или альтертантивы для libnssckbi.so.

-- 
Rgrds, legion

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

[Dmitry V. Levin]

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

On Fri, Dec 22, 2017 at 01:36:06AM +0100, Alexey Gladkov wrote:
> On Thu, Dec 21, 2017 at 06:48:16PM +0300, Mikhail Efremov wrote:
> > Hello!
> > 
> > Это должно работать с openssl и gnutls, а вот с nss проблема: я так
> > понимаю, что nss использует собственный бандл, а не системный, и
> > использует libnssckbi.so для работы с ним. В p11-kit используется модуль
> > pkcs11/p11-kit-trust.so и утверждается, что он бинарно совместим с
> > libnssckbi.so, так что в Федоре некоторое время имели модули
> > libnssckbi.so и p11-kit-trust.so на альтернативах, а сейчас просто
> > выкинули libnssckbi.so из nss
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1484449).
> > Но даже если про бинарную совместимость - это правда, то у меня есть
> > сомнения, что это всегда будет так в следующих версиях nss и p11-kit и
> > нас нет автоматической проверки таких вещей при сборке.
> 
> Нету. Плюс появление несовместимости станет блокирокером к обновлению nss,
> что с точке зрения безопасности мне не нравится.
> 
> Если идти по этому пути, то я бы сделал альтернативы для этой библиотеки.

Альтернативы для библиотек -- это вообще плохая идея, я всё никак не
придумаю способа их эффективно запретить.

> Кроме того, в nssckbi встроенная база Root CA Certificate поддерживается в
> актуальном состоянии Mozilla.

Пакет ca-certificates, насколько я понимаю, поставляет ту же самую базу,
которую импортирует из nss/lib/ckfw/builtins/certdata.txt,
достаточно просто обновлять её своевременно.

> В тоже время
> 
> #
> # ALT CA
> #
>          
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 0 (0x0)
>     Signature Algorithm: sha1WithRSAEncryption
>         Issuer: C=RU, O=ALT Linux Team, OU=ALT Certification Authority, CN=ALT Root Certification Authority/emailAddress=ca-root@altlinux.org
>         Validity
>             Not Before: Jan  1 00:00:00 2007 GMT
>             Not After : Jan  1 00:00:00 2017 GMT
>         Subject: C=RU, O=ALT Linux Team, OU=ALT Certification Authority, CN=ALT Root Certification Authority/emailAddress=ca-root@altlinux.org
> 
> И вот `Not After : Jan  1 00:00:00 2017 GMT` вселяет сомнения в таком же
> уровне поддержки.

Это артефакт, ALT CA давно решили упразднить.

> > libnssckbi.so, тогда у нас действительно будет единое место для
> > хранения CA сертификатов. Эту проблему придется как-то решать.
> 
> На мой взгляд правильный путь это добавление сертификатов в базу nss.
> https://wiki.mozilla.org/NSS_Shared_DB
> https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Существует ли инструмент экспорта в формат, с которым работает libnssckbi.so?

> Ну или альтертантивы для libnssckbi.so.

Либо разные реализации libnssckbi.so окажутся настолько совместимы, что
будет использоваться только одна, либо нет, и тогда придётся использовать
разные реализации одновременно и мы вернёмся к нынешней ситуации.


-- 
ldv

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

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

[Alexey Gladkov]

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

On Fri, Dec 22, 2017 at 04:28:05AM +0300, Dmitry V. Levin wrote:
> > Нету. Плюс появление несовместимости станет блокирокером к обновлению nss,
> > что с точке зрения безопасности мне не нравится.
> > 
> > Если идти по этому пути, то я бы сделал альтернативы для этой библиотеки.
> 
> Альтернативы для библиотек -- это вообще плохая идея, я всё никак не
> придумаю способа их эффективно запретить.

Если всё как сказал sem@ и действительно есть полная совместимость, то
проблем не будет. Если несовместимость всё-таки появится/может появиться,
то пользователи смогут переключиться на апстримную библиотеку (хотя бы
временно). Это лучше, чем класть все яйца в одну корзину.

> Пакет ca-certificates, насколько я понимаю, поставляет ту же самую базу,
> которую импортирует из nss/lib/ckfw/builtins/certdata.txt,
> достаточно просто обновлять её своевременно.

Сейчас с обновлением nss firefox, thunderbird и chromium получают новую
базу (это почти правде). Если ca-certificates обновляются из того же
источника,тогда почему он не собирается из libnss ?

> Это артефакт, ALT CA давно решили упразднить.

Его больше нет в ca-certificates. В следующей сборке nss тоже выкину.

> > На мой взгляд правильный путь это добавление сертификатов в базу nss.
> > https://wiki.mozilla.org/NSS_Shared_DB
> > https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
> 
> Существует ли инструмент экспорта в формат, с которым работает libnssckbi.so?

Я начинал делать общую базу для nss, когда поддерживал всё от mozilla, но
остановился и выпал из контекста. Поэтому ответить на этот вопрос сейчас
не могу.

После поверхностного просмотра там вроде формат базы sqlite.

Я знаю, что в этом плане у RH были наработки. Правда, ходят слухи, что RH
планирует уйти с nss. Так что, кто знает...

> > Ну или альтертантивы для libnssckbi.so.
> 
> Либо разные реализации libnssckbi.so окажутся настолько совместимы, что
> будет использоваться только одна, либо нет, и тогда придётся использовать
> разные реализации одновременно и мы вернёмся к нынешней ситуации.

Именно, но откат пользователя к апстримной библиотеке мне кажется более
удачным вариантом, чем невозможность пользоваться браузером/почтой вообще,
в случае, когда вместо libnssckbi.so будет несовместимая библиотека.

-- 
Rgrds, legion


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

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

[Mikhail Efremov]

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.

> > Пакет ca-certificates, насколько я понимаю, поставляет ту же самую базу,
> > которую импортирует из nss/lib/ckfw/builtins/certdata.txt,
> > достаточно просто обновлять её своевременно.  
> 
> Сейчас с обновлением nss firefox, thunderbird и chromium получают новую
> базу (это почти правде). Если ca-certificates обновляются из того же
> источника,тогда почему он не собирается из libnss ?

В принципе можно собирать и из libnss, но мне кажется отдельным пакетом
удобнее. Можно будет вносить изменения в скрипты не пересобирая ради
этого libnss или собрать новую версию с новыми сертификатами не
дожидаясь выхода новой libnss. И ничего не мешает обновлять
ca-certificates синхронно с выходом новой версии libnss.

> > > На мой взгляд правильный путь это добавление сертификатов в базу nss.
> > > https://wiki.mozilla.org/NSS_Shared_DB
> > > https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX  
> > 
> > Существует ли инструмент экспорта в формат, с которым работает libnssckbi.so?  
> 
> Я начинал делать общую базу для nss, когда поддерживал всё от mozilla, но
> остановился и выпал из контекста. Поэтому ответить на этот вопрос сейчас
> не могу.
> После поверхностного просмотра там вроде формат базы sqlite.
> 
> Я знаю, что в этом плане у RH были наработки. Правда, ходят слухи, что RH
> планирует уйти с nss. Так что, кто знает...

Это может и был бы неплохой вариант, просто экспортировать сертификаты в
базу nss также, как они экспортируются для openssl и т.д. Если бы не это
(https://wiki.gentoo.org/wiki/Certificates):
Warning
Although common sense would imply that applications which use the NSS
library would also consult the system-wide database, this is more
exception than rule. Neither Chromium nor Firefox (or any of the
derived browsers) support the system-wide database. Hence, the below
instructions are generally ineffective on a system-wide basis, but can
be altered to suit per-application specific databases.

Впрочем, мне все рано в этом варианте не нравится, что у libnss может
быть другой набор CA сертификатов. Идея как раз в том, чтобы иметь
единый набор CA сертификатов для всех библиотек. И управлять уже им.
Добавил сертификат - все приложения начинают ему доверять, не зависимо
от того, используют ли они openssl, gnutls или nss. Ну и с blacklist,
соответственно, так же.

> > > Ну или альтертантивы для libnssckbi.so.  
> > 
> > Либо разные реализации libnssckbi.so окажутся настолько совместимы, что
> > будет использоваться только одна, либо нет, и тогда придётся использовать
> > разные реализации одновременно и мы вернёмся к нынешней ситуации.  
> 
> Именно, но откат пользователя к апстримной библиотеке мне кажется более
> удачным вариантом, чем невозможность пользоваться браузером/почтой вообще,
> в случае, когда вместо libnssckbi.so будет несовместимая библиотека.

Учитывая, что это не совсем библиотека, насколько я понимаю, т.е. с ней
никто не линкуется, то может альтернативы и не самый плохой вариант.
Лучше бы, конечно, убрать ее из nss совсем, заменив ссылкой на
p11-kit-trust.so, а в случае разлома можно временно вернуть
libnssckbi.so. Проблема в том, как обнаружить этот разлом.

-- 
WBR, Mikhail Efremov

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

[Dmitry V. Levin]

[-- 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 --]

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

[Alexey Gladkov]

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

On Sat, Dec 23, 2017 at 01:37:09AM +0300, Dmitry V. Levin wrote:
> Получается, что единственное доступное нам решение задачи, чтобы в nss
> были те же сертификаты, что и в openssl с gnutls - это заменить
> libnssckbi.so, который использует nss, ссылкой на альтернативного
> провайдера (/usr/lib64/pkcs11/p11-kit-trust.so), который это реализует.
> 
> Можно, конечно, управлять этой ссылкой с помощью механизма альтернатив,
> но я не вижу в этом смысла.
> Если какая-то версия nss перестанет работать с p11-kit-trust.so, то эту
> ссылку придётся временно заменить на файл, поставляемый с libnss, до тех
> пор, пока p11-kit-trust.so снова не заработает, после чего ссылку можно
> будет вернуть, поставив соответствующие зависимости (в данном случае,
> наверное, конфликты).
> Чем в этой ситуации поможет механизм альтернатив?

Я хотел бы иметь возможность использовать именно libnssckbi.so без
пересборки собственного пакета. Мне это хочется по ряду причин.

-- 
Rgrds, legion


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

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

[Dmitry V. Levin]

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

On Sat, Dec 23, 2017 at 12:53:30AM +0100, Alexey Gladkov wrote:
> On Sat, Dec 23, 2017 at 01:37:09AM +0300, Dmitry V. Levin wrote:
> > Получается, что единственное доступное нам решение задачи, чтобы в nss
> > были те же сертификаты, что и в openssl с gnutls - это заменить
> > libnssckbi.so, который использует nss, ссылкой на альтернативного
> > провайдера (/usr/lib64/pkcs11/p11-kit-trust.so), который это реализует.
> > 
> > Можно, конечно, управлять этой ссылкой с помощью механизма альтернатив,
> > но я не вижу в этом смысла.
> > Если какая-то версия nss перестанет работать с p11-kit-trust.so, то эту
> > ссылку придётся временно заменить на файл, поставляемый с libnss, до тех
> > пор, пока p11-kit-trust.so снова не заработает, после чего ссылку можно
> > будет вернуть, поставив соответствующие зависимости (в данном случае,
> > наверное, конфликты).
> > Чем в этой ситуации поможет механизм альтернатив?
> 
> Я хотел бы иметь возможность использовать именно libnssckbi.so без
> пересборки собственного пакета. Мне это хочется по ряду причин.

В таком случае альтернатива на libnssckbi.so -- это то, что надо.
Но что это за причины?
И почему libnssckbi.so находится непосредственно в %_libdir?


-- 
ldv

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

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

[Alexey Gladkov]

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

On Sat, Dec 23, 2017 at 02:58:55AM +0300, Dmitry V. Levin wrote:
> В таком случае альтернатива на libnssckbi.so -- это то, что надо.
> Но что это за причины?

1. Для проверки работоспособности libnss хочется иметь возможность отключить
сторонний p11-kit-trust.so. У меня нет уверенности в этом модуле.

2. Мне очень хотелось бы иметь возможность использовать CA поддерживаемые
Mozilla.

> И почему libnssckbi.so находится непосредственно в %_libdir?

Спек был взят из RH и они паковали его в %_libdir. Даже когда они перешли
на альтернативы для libnssckbi.so, то тоже паковали её именно в libdir:

http://pkgs.fedoraproject.org/rpms/nss/c/61169569b13845986b3aeed3cfc3a3012a4427f3?branch=master

-- 
Rgrds, legion


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

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

[Alexey Gladkov]

On Fri, Dec 22, 2017 at 07:33:46PM +0300, Mikhail Efremov wrote:
> > Если всё как сказал 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.

Отлично!

> > Сейчас с обновлением nss firefox, thunderbird и chromium получают новую
> > базу (это почти правде). Если ca-certificates обновляются из того же
> > источника,тогда почему он не собирается из libnss ?
> 
> В принципе можно собирать и из libnss, но мне кажется отдельным пакетом
> удобнее. Можно будет вносить изменения в скрипты не пересобирая ради
> этого libnss или собрать новую версию с новыми сертификатами не
> дожидаясь выхода новой libnss. И ничего не мешает обновлять
> ca-certificates синхронно с выходом новой версии libnss.

Я совершенно не настаиваю :)

> Впрочем, мне все рано в этом варианте не нравится, что у libnss может
> быть другой набор CA сертификатов. Идея как раз в том, чтобы иметь
> единый набор CA сертификатов для всех библиотек. И управлять уже им.
> Добавил сертификат - все приложения начинают ему доверять, не зависимо
> от того, используют ли они openssl, gnutls или nss. Ну и с blacklist,
> соответственно, так же.

Тогда давайте сделаем альтертанивы.

-- 
Rgrds, legion

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

[Dmitry V. Levin]

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

On Sat, Dec 23, 2017 at 01:05:13AM +0100, Alexey Gladkov wrote:
> On Fri, Dec 22, 2017 at 07:33:46PM +0300, Mikhail Efremov wrote:
> > > Если всё как сказал 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.
> 
> Отлично!

Если сборочная зависимость на p11-kit-trust.so не напрягает, то можно
добавить какой-нибудь аналогичный тест в %check пакета nss.

> > > Сейчас с обновлением nss firefox, thunderbird и chromium получают новую
> > > базу (это почти правде). Если ca-certificates обновляются из того же
> > > источника,тогда почему он не собирается из libnss ?
> > 
> > В принципе можно собирать и из libnss, но мне кажется отдельным пакетом
> > удобнее. Можно будет вносить изменения в скрипты не пересобирая ради
> > этого libnss или собрать новую версию с новыми сертификатами не
> > дожидаясь выхода новой libnss. И ничего не мешает обновлять
> > ca-certificates синхронно с выходом новой версии libnss.
> 
> Я совершенно не настаиваю :)

В новой редакции пакета ca-certificates, который мы обсуждаем, есть
сборочные зависимости на openssl, asciidoc, asciidoc-a2x, и libxslt.
Я не уверен, что ты хочешь такие сборочные зависимости в пакете nss. :)

2sem: а зачем сборочная зависимость на libxslt?  Это же библиотека,
которая должна вытягиваться по зависимостям, если она нужна.

> > Впрочем, мне все рано в этом варианте не нравится, что у libnss может
> > быть другой набор CA сертификатов. Идея как раз в том, чтобы иметь
> > единый набор CA сертификатов для всех библиотек. И управлять уже им.
> > Добавил сертификат - все приложения начинают ему доверять, не зависимо
> > от того, используют ли они openssl, gnutls или nss. Ну и с blacklist,
> > соответственно, так же.
> 
> Тогда давайте сделаем альтертанивы.

Альтернативы? :)
Непосредственно на %_libdir/libnssckbi.so ?


-- 
ldv

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

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

[Alexey Gladkov]

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

On Sat, Dec 23, 2017 at 03:22:39AM +0300, Dmitry V. Levin wrote:
> Если сборочная зависимость на p11-kit-trust.so не напрягает, то можно
> добавить какой-нибудь аналогичный тест в %check пакета nss.

Как валидировать результат вывода этой команды ?

Что делать, если тест провален ? Похоже это будет blocker для nss чему
конечно я не рад :(

> В новой редакции пакета ca-certificates, который мы обсуждаем, есть
> сборочные зависимости на openssl, asciidoc, asciidoc-a2x, и libxslt.
> Я не уверен, что ты хочешь такие сборочные зависимости в пакете nss. :)

Совершенно не хочу :)

> Альтернативы? :)
> Непосредственно на %_libdir/libnssckbi.so ?

Да.

-- 
Rgrds, legion


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

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

[Dmitry V. Levin]

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

On Sat, Dec 23, 2017 at 01:35:50AM +0100, Alexey Gladkov wrote:
> On Sat, Dec 23, 2017 at 03:22:39AM +0300, Dmitry V. Levin wrote:
> > Если сборочная зависимость на p11-kit-trust.so не напрягает, то можно
> > добавить какой-нибудь аналогичный тест в %check пакета nss.
> 
> Как валидировать результат вывода этой команды ?

Совпадение списка сертификатов с тем, который может быть получен другим
способом?

> Что делать, если тест провален ? Похоже это будет blocker для nss чему
> конечно я не рад :(

Если тест провален, то есть два варианта: выключить тест или исправить
проблему.  А вот если теста нет, то как мы узнаем, что эта связка вообще
работает?

Если не хочется засорения сборочных зависимостей nss, могу предложить
другой вариант: запаковать в составе nss подпакет что-нибудь-test, который
в %post будет запускать скрипт, выполняющий аналогичный тест.

Преимуществом такого варианта является возможность запускать тот же скрипт
из какого-нибудь подпакета p11-kit-trust-test, чтобы тестировать эту
связку при обновлении p11-kit.

Это не обязательно делать одновременно с добавлением альтернативы на
libnssckbi.so, но возможность автоматического тестирования хотелось бы
реализовать.


-- 
ldv

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

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

[Alexey Gladkov]

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

On Sat, Dec 23, 2017 at 03:58:56AM +0300, Dmitry V. Levin wrote:
> > Что делать, если тест провален ? Похоже это будет blocker для nss чему
> > конечно я не рад :(
> 
> Если тест провален, то есть два варианта: выключить тест или исправить
> проблему.  А вот если теста нет, то как мы узнаем, что эта связка вообще
> работает?

Согласен.

> Если не хочется засорения сборочных зависимостей nss, могу предложить
> другой вариант: запаковать в составе nss подпакет что-нибудь-test, который
> в %post будет запускать скрипт, выполняющий аналогичный тест.

2sem: Вы сможете сделать такой скрипт, тогда я добавлю его в пакет ?

> Преимуществом такого варианта является возможность запускать тот же скрипт
> из какого-нибудь подпакета p11-kit-trust-test, чтобы тестировать эту
> связку при обновлении p11-kit.
> 
> Это не обязательно делать одновременно с добавлением альтернативы на
> libnssckbi.so, но возможность автоматического тестирования хотелось бы
> реализовать.

Вариант с подпакетом мне нравится.

-- 
Rgrds, legion


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

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

[Mikhail Efremov]

On Sat, 23 Dec 2017 02:07:02 +0100 Alexey Gladkov wrote:
> On Sat, Dec 23, 2017 at 03:58:56AM +0300, Dmitry V. Levin wrote:
> > > Что делать, если тест провален ? Похоже это будет blocker для nss
> > > чему конечно я не рад :(  
> > 
> > Если тест провален, то есть два варианта: выключить тест или
> > исправить проблему.  А вот если теста нет, то как мы узнаем, что
> > эта связка вообще работает?  
> 
> Согласен.
> 
> > Если не хочется засорения сборочных зависимостей nss, могу
> > предложить другой вариант: запаковать в составе nss подпакет
> > что-нибудь-test, который в %post будет запускать скрипт,
> > выполняющий аналогичный тест.  
> 
> 2sem: Вы сможете сделать такой скрипт, тогда я добавлю его в пакет ?

Да, сделаю. Надо только написать в описании пакета, что он существует
только для install-test в сборочнице и его не нужно ставить в реальную
систему. Мне не слишком нравится, что в Сизифе будет такие пакеты, но
альтернатива - делать такую проверку в %check и libnss, и p11-kit. В
результате чего у них будут сборочные зависимости друг на друга, что
еще хуже.
Сам скрипт будет тривиальным, можно даже не проверять, что список
сертификатов чему-то соответствует, достаточно того, что он вообще есть:
чтобы заставить certutil вывести список CA-сертификатов даже из
libnssckbi.so - тоже приходится делать симлинк в /etc/pki/nssdb.
Вообще то, что certutil работает именно так, для меня выглядит дико. Но
может я просто не умею ею пользоваться.
Может есть какой-то другой, более надежный, но тоже простой способ
проверить использование libnssckbi.so/p11-kit-trust.so? Но я не нашел.

-- 
WBR, Mikhail Efremov

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

[Dmitry V. Levin]

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

On Sat, Dec 23, 2017 at 02:54:55PM +0300, Mikhail Efremov wrote:
> On Sat, 23 Dec 2017 02:07:02 +0100 Alexey Gladkov wrote:
> > On Sat, Dec 23, 2017 at 03:58:56AM +0300, Dmitry V. Levin wrote:
> > > > Что делать, если тест провален ? Похоже это будет blocker для nss
> > > > чему конечно я не рад :(  
> > > 
> > > Если тест провален, то есть два варианта: выключить тест или
> > > исправить проблему.  А вот если теста нет, то как мы узнаем, что
> > > эта связка вообще работает?  
> > 
> > Согласен.
> > 
> > > Если не хочется засорения сборочных зависимостей nss, могу
> > > предложить другой вариант: запаковать в составе nss подпакет
> > > что-нибудь-test, который в %post будет запускать скрипт,
> > > выполняющий аналогичный тест.  
> > 
> > 2sem: Вы сможете сделать такой скрипт, тогда я добавлю его в пакет ?
> 
> Да, сделаю. Надо только написать в описании пакета, что он существует
> только для install-test в сборочнице и его не нужно ставить в реальную
> систему. Мне не слишком нравится, что в Сизифе будет такие пакеты, но

Почему?  Тогда тесты можно будет по крону запускать! :)


-- 
ldv

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

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

[Mikhail Efremov]

On Sat, 23 Dec 2017 15:00:38 +0300 Dmitry V. Levin wrote:
> On Sat, Dec 23, 2017 at 02:54:55PM +0300, Mikhail Efremov wrote:
> > On Sat, 23 Dec 2017 02:07:02 +0100 Alexey Gladkov wrote:  
> > > On Sat, Dec 23, 2017 at 03:58:56AM +0300, Dmitry V. Levin wrote:  
> > > > > Что делать, если тест провален ? Похоже это будет blocker для
> > > > > nss чему конечно я не рад :(    
> > > > 
> > > > Если тест провален, то есть два варианта: выключить тест или
> > > > исправить проблему.  А вот если теста нет, то как мы узнаем, что
> > > > эта связка вообще работает?    
> > > 
> > > Согласен.
> > >   
> > > > Если не хочется засорения сборочных зависимостей nss, могу
> > > > предложить другой вариант: запаковать в составе nss подпакет
> > > > что-нибудь-test, который в %post будет запускать скрипт,
> > > > выполняющий аналогичный тест.    
> > > 
> > > 2sem: Вы сможете сделать такой скрипт, тогда я добавлю его в
> > > пакет ?  
> > 
> > Да, сделаю. Надо только написать в описании пакета, что он
> > существует только для install-test в сборочнице и его не нужно
> > ставить в реальную систему. Мне не слишком нравится, что в Сизифе
> > будет такие пакеты, но  
> 
> Почему?  Тогда тесты можно будет по крону запускать! :)

Ну, пожалуй да, у нас и так есть пакеты, не предназначенные для
установки в реальные системы, те же installer-features. А сделать так,
чтобы пакет не наносил вреда системе, даже если какой пытливый ум его
поставит, не сложно, думаю.

-- 
WBR, Mikhail Efremov

Re: [devel] RFC: *-install-test

[Dmitry V. Levin]

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

On Sat, Dec 23, 2017 at 02:54:55PM +0300, Mikhail Efremov wrote:
> On Sat, 23 Dec 2017 02:07:02 +0100 Alexey Gladkov wrote:
> > On Sat, Dec 23, 2017 at 03:58:56AM +0300, Dmitry V. Levin wrote:
> > > > Что делать, если тест провален ? Похоже это будет blocker для nss
> > > > чему конечно я не рад :(  
> > > 
> > > Если тест провален, то есть два варианта: выключить тест или
> > > исправить проблему.  А вот если теста нет, то как мы узнаем, что
> > > эта связка вообще работает?  
> > 
> > Согласен.
> > 
> > > Если не хочется засорения сборочных зависимостей nss, могу
> > > предложить другой вариант: запаковать в составе nss подпакет
> > > что-нибудь-test, который в %post будет запускать скрипт,
> > > выполняющий аналогичный тест.  
> > 
> > 2sem: Вы сможете сделать такой скрипт, тогда я добавлю его в пакет ?
> 
> Да, сделаю. Надо только написать в описании пакета, что он существует
> только для install-test в сборочнице и его не нужно ставить в реальную
> систему. Мне не слишком нравится, что в Сизифе будет такие пакеты, но

Мне кажется, что это, наоборот, очень перспективная тема.

Для того, чтобы пакеты *-install-test не были установлены случайно, можно
- индексировать их отдельно, по аналогии с *-debuginfo;
- подключать этот индекс только при тестировании установки пакетов
  *-install-test;
- завести фиксированный формат %description таких пакетов,
  и проверять их на стадии sisyphus_check.


-- 
ldv

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

Re: [devel] RFC: *-install-test

[Alexey Gladkov]

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

On Sun, Dec 24, 2017 at 03:04:48AM +0300, Dmitry V. Levin wrote:
> Мне кажется, что это, наоборот, очень перспективная тема.
> 
> Для того, чтобы пакеты *-install-test не были установлены случайно, можно
> - индексировать их отдельно, по аналогии с *-debuginfo;
> - подключать этот индекс только при тестировании установки пакетов
>   *-install-test;
> - завести фиксированный формат %description таких пакетов,
>   и проверять их на стадии sisyphus_check.

Может сделать для них отдельный компонент ?

-- 
Rgrds, legion


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

Re: [devel] RFC: *-install-test

[Dmitry V. Levin]

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

On Sun, Dec 24, 2017 at 02:05:39AM +0100, Alexey Gladkov wrote:
> On Sun, Dec 24, 2017 at 03:04:48AM +0300, Dmitry V. Levin wrote:
> > Мне кажется, что это, наоборот, очень перспективная тема.
> > 
> > Для того, чтобы пакеты *-install-test не были установлены случайно, можно
> > - индексировать их отдельно, по аналогии с *-debuginfo;
> > - подключать этот индекс только при тестировании установки пакетов
> >   *-install-test;
> > - завести фиксированный формат %description таких пакетов,
> >   и проверять их на стадии sisyphus_check.
> 
> Может сделать для них отдельный компонент ?

Может быть, я недостаточно ясно выразился, когда сравнил их с debuginfo.
Да, отдельный компонент, как и debuginfo.


-- 
ldv

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

Re: [devel] RFC: *-install-test

[Dmitry V. Levin]

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

On Sun, Dec 24, 2017 at 04:09:49AM +0300, Dmitry V. Levin wrote:
> On Sun, Dec 24, 2017 at 02:05:39AM +0100, Alexey Gladkov wrote:
> > On Sun, Dec 24, 2017 at 03:04:48AM +0300, Dmitry V. Levin wrote:
> > > Мне кажется, что это, наоборот, очень перспективная тема.
> > > 
> > > Для того, чтобы пакеты *-install-test не были установлены случайно, можно
> > > - индексировать их отдельно, по аналогии с *-debuginfo;
> > > - подключать этот индекс только при тестировании установки пакетов
> > >   *-install-test;
> > > - завести фиксированный формат %description таких пакетов,
> > >   и проверять их на стадии sisyphus_check.
> > 
> > Может сделать для них отдельный компонент ?
> 
> Может быть, я недостаточно ясно выразился, когда сравнил их с debuginfo.
> Да, отдельный компонент, как и debuginfo.

Новый компонент сделан, называется он, как все уже догадались,
checkinstall.


-- 
ldv

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

Re: [devel] RFC: *-install-test

[Alexey Tourbin]

2018-01-07 2:22 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
>> > > Для того, чтобы пакеты *-install-test не были установлены случайно, можно
>> > > - индексировать их отдельно, по аналогии с *-debuginfo;
>> > > - подключать этот индекс только при тестировании установки пакетов
>> > >   *-install-test;
>> > > - завести фиксированный формат %description таких пакетов,
>> > >   и проверять их на стадии sisyphus_check.
>> >
>> > Может сделать для них отдельный компонент ?
>>
>> Может быть, я недостаточно ясно выразился, когда сравнил их с debuginfo.
>> Да, отдельный компонент, как и debuginfo.
>
> Новый компонент сделан, называется он, как все уже догадались,
> checkinstall.

Вы зря это делаете, то есть идете на поводу у Виталия Липатова, у
которого голова большая и бездумная, и в ней помещается много разных
противоположных мыслей. Вопрос не стоит и выведенного яйца. Если не
хочешь линковаться с графическими библиотеками, то не надо с ними
линковаться! Если же хочется налагать произвольные предикаты или лучше
сказать инварианты на репозиторий, то хотеть не вредно (вот мыслители
развелись, а?), но при чем тут какая-то новая компонента репозитория,
не понятно вообще. Мама, роди меня обратно.

Re: [devel] RFC: *-install-test

[Dmitry V. Levin]

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

On Sun, Jan 07, 2018 at 03:23:46AM +0300, Alexey Tourbin wrote:
> 2018-01-07 2:22 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
> >> > > Для того, чтобы пакеты *-install-test не были установлены случайно, можно
> >> > > - индексировать их отдельно, по аналогии с *-debuginfo;
> >> > > - подключать этот индекс только при тестировании установки пакетов
> >> > >   *-install-test;
> >> > > - завести фиксированный формат %description таких пакетов,
> >> > >   и проверять их на стадии sisyphus_check.
> >> >
> >> > Может сделать для них отдельный компонент ?
> >>
> >> Может быть, я недостаточно ясно выразился, когда сравнил их с debuginfo.
> >> Да, отдельный компонент, как и debuginfo.
> >
> > Новый компонент сделан, называется он, как все уже догадались,
> > checkinstall.
> 
> Вы зря это делаете, то есть идете на поводу у Виталия Липатова, у
> которого голова большая и бездумная, и в ней помещается много разных
> противоположных мыслей. Вопрос не стоит и выведенного яйца. Если не
> хочешь линковаться с графическими библиотеками, то не надо с ними
> линковаться! Если же хочется налагать произвольные предикаты или лучше
> сказать инварианты на репозиторий, то хотеть не вредно (вот мыслители
> развелись, а?), но при чем тут какая-то новая компонента репозитория,
> не понятно вообще. Мама, роди меня обратно.

Новая компонента репозитория решает следующие задачи:
- пакеты оттуда не покажет apt-cache search и не установит
  apt-get install, пока эта компонента не будет подключена,
  что практически исключает случайную установку таких пакетов;
- пакеты оттуда не будут установлены при сборке пакетов.

Посмотрите task #197295, там пример пакетов (p11-kit-checkinstall и
libnss-nssckbi-checkinstall), которые мы не хотим видеть в classic.


-- 
ldv

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

Re: [devel] RFC: *-install-test

[Alexey Tourbin]

2018-01-07 3:46 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
>> > Новый компонент сделан, называется он, как все уже догадались,
>> > checkinstall.
>>
>> Вы зря это делаете, то есть идете на поводу у Виталия Липатова, у
>> которого голова большая и бездумная, и в ней помещается много разных
>> противоположных мыслей. Вопрос не стоит и выведенного яйца. Если не
>> хочешь линковаться с графическими библиотеками, то не надо с ними
>> линковаться! Если же хочется налагать произвольные предикаты или лучше
>> сказать инварианты на репозиторий, то хотеть не вредно (вот мыслители
>> развелись, а?), но при чем тут какая-то новая компонента репозитория,
>> не понятно вообще. Мама, роди меня обратно.
>
> Новая компонента репозитория решает следующие задачи:
> - пакеты оттуда не покажет apt-cache search и не установит
>   apt-get install, пока эта компонента не будет подключена,
>   что практически исключает случайную установку таких пакетов;
> - пакеты оттуда не будут установлены при сборке пакетов.

Новая компонента репозитория решает важную задачу: установка пакетов
из нее практически исключается.

> Посмотрите task #197295, там пример пакетов (p11-kit-checkinstall и
> libnss-nssckbi-checkinstall), которые мы не хотим видеть в classic.

Посмотрел немного.

$ rpm -qpR build/.../libnss-nssckbi-checkinstall-3.34.1-alt2.x86_64.rpm
p11-kit-checkinstall
rpmlib(PayloadIsLzma)
$ rpm -qp --conflicts
build/.../libnss-nssckbi-checkinstall-3.34.1-alt2.x86_64.rpm
$

Зачем нужен пакет libnss-nssckbi-checkinstall? Это умножение сущностей
без необходимости.

$ rpm -qpR build/.../p11-kit-checkinstall-0.23.9-alt2.i586.rpm
nss-utils
/bin/sh
nss-utils
coreutils
sed
p11-kit-trust = 0.23.9-alt2
rpmlib(PayloadIsLzma)
$ rpm -qp --conflicts build/.../p11-kit-checkinstall-0.23.9-alt2.i586.rpm
$

Ну конфликтов снова нет, в чем тогда цимес? Проверить, что пакеты
coreutils, sed и /bin/sh могут быть установлены одновременно? Это
тянет на нобелевскую премию!

Re: [devel] RFC: *-install-test

[Dmitry V. Levin]

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

On Sun, Jan 07, 2018 at 09:25:19AM +0300, Alexey Tourbin wrote:
> 2018-01-07 3:46 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
> >> > Новый компонент сделан, называется он, как все уже догадались,
> >> > checkinstall.
> >>
> >> Вы зря это делаете, то есть идете на поводу у Виталия Липатова, у
> >> которого голова большая и бездумная, и в ней помещается много разных
> >> противоположных мыслей. Вопрос не стоит и выведенного яйца. Если не
> >> хочешь линковаться с графическими библиотеками, то не надо с ними
> >> линковаться! Если же хочется налагать произвольные предикаты или лучше
> >> сказать инварианты на репозиторий, то хотеть не вредно (вот мыслители
> >> развелись, а?), но при чем тут какая-то новая компонента репозитория,
> >> не понятно вообще. Мама, роди меня обратно.
> >
> > Новая компонента репозитория решает следующие задачи:
> > - пакеты оттуда не покажет apt-cache search и не установит
> >   apt-get install, пока эта компонента не будет подключена,
> >   что практически исключает случайную установку таких пакетов;
> > - пакеты оттуда не будут установлены при сборке пакетов.
> 
> Новая компонента репозитория решает важную задачу: установка пакетов
> из нее практически исключается.
> 
> > Посмотрите task #197295, там пример пакетов (p11-kit-checkinstall и
> > libnss-nssckbi-checkinstall), которые мы не хотим видеть в classic.
> 
> Посмотрел немного.
> 
> $ rpm -qpR build/.../libnss-nssckbi-checkinstall-3.34.1-alt2.x86_64.rpm
> p11-kit-checkinstall
> rpmlib(PayloadIsLzma)
> $ rpm -qp --conflicts
> build/.../libnss-nssckbi-checkinstall-3.34.1-alt2.x86_64.rpm
> $
> 
> Зачем нужен пакет libnss-nssckbi-checkinstall? Это умножение сущностей
> без необходимости.
> 
> $ rpm -qpR build/.../p11-kit-checkinstall-0.23.9-alt2.i586.rpm
> nss-utils
> /bin/sh
> nss-utils
> coreutils
> sed
> p11-kit-trust = 0.23.9-alt2
> rpmlib(PayloadIsLzma)
> $ rpm -qp --conflicts build/.../p11-kit-checkinstall-0.23.9-alt2.i586.rpm
> $
> 
> Ну конфликтов снова нет, в чем тогда цимес? Проверить, что пакеты
> coreutils, sed и /bin/sh могут быть установлены одновременно? Это
> тянет на нобелевскую премию!

В пакете p11-kit-checkinstall есть %post-скрипт, а в пакете
libnss-nssckbi-checkinstall - зависимость на p11-kit-checkinstall.

Такое ощущение, будто вы пропустили всё обсуждение на тему
"RFC: ca-certificates a la Fedora", том числе и ту часть треда,
где обсуждались эти checkinstall-пакеты.


-- 
ldv

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

[devel] check_*_pkg? Was: Re: RFC: *-install-test

[Ivan Zakharyaschev]

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


On Sun, 24 Dec 2017, Dmitry V. Levin wrote:

>> Да, сделаю. Надо только написать в описании пакета, что он существует
>> только для install-test в сборочнице и его не нужно ставить в реальную
>> систему. Мне не слишком нравится, что в Сизифе будет такие пакеты, но
>
> Мне кажется, что это, наоборот, очень перспективная тема.
>
> Для того, чтобы пакеты *-install-test не были установлены случайно, можно
> - индексировать их отдельно, по аналогии с *-debuginfo;
> - подключать этот индекс только при тестировании установки пакетов
>  *-install-test;
> - завести фиксированный формат %description таких пакетов,
>  и проверять их на стадии sisyphus_check.

Да, я тоже хотел такое начать делать! Не помню, как я назвал первую 
попытку (кажется: *-checkpkg), потом обдумывал, как это вообще может быть 
устроено в целом, и заодно родились схемы названий (Не буду утверждать, 
что они лучше):

1) check_*_pkg

2)
check_NAME0_pkg_with_NAME1
check_NAME0_pkg_with_NAME1_NAME2

или check_NAME0_NAME1_NAME2_pkgs

Второе -- на случаи, если захочется тестировать каждый раз, например, при 
обновлении NAME1, NAME2 (поставить зависимость на их EVR).

Разделитель другой (_), чтобы легче было читать NAME* обычных пакетов 
(вычленять), учитывая, что обычный разделитель -- это - (rpm-build так 
оформляет подпакеты).

Чтобы не спутатьс пакетами, просто пакующими тесты, я решил, что нужно 
использовать на слово test в названии, а check. (Чтобы ни люди не 
спутали, ни автоматика, которая их будет откладывать в отдельный 
подрепозиторий.) К тому же это больше похоже на команду "Check smth!", что 
отражает суть: поставить этот пакет == проверить что-то (это действие 
произойдёт в системе).

Обрамлять название пакета с двух сторон (check_*_pkg) мне захотелось, 
чтобы с большей вероятностью избежать совпадений с обычными пакетами.

Единственное, что мне в этой схеме не очень нравится -- это то, что они 
все будут иметь одинаковое начало, а это мешает сортировке, работе со 
спсиком (как со "словарём") пакетов отдельного подрепозитория...

Есть ещё мысль: следует иметь в виду разные возможности:

1) более сильные install-time проверки check_NAME0_NAME1_NAME2_pkgs с
    зависимостями на EVR всех пакетов. Будут вызывать unmet-ы при,
    требовать прохождения при сборке новых релизов сразу же.

2) более слабые (информационные) аналоги check_NAME0_NAME1_NAME2_pkgs с 
build-time проверками; они в BuildPreReq ставят проверяемые пакеты, и в 
%build делают их тесты. Тогда о нерохождении мы будем информироваться 
просто раз в сутки в рамках FTBFS от beehive. Схему именования я ещё не 
придумал.

-- 
Best regards,
Ivan

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

[Mikhail Efremov]

On Sat, 23 Dec 2017 03:22:39 +0300 Dmitry V. Levin wrote:
> On Sat, Dec 23, 2017 at 01:05:13AM +0100, Alexey Gladkov wrote:
> 2sem: а зачем сборочная зависимость на libxslt?  Это же библиотека,
> которая должна вытягиваться по зависимостям, если она нужна.

Невнимательный copy/paste из федорного спека, должно быть xsltproc.

-- 
WBR, Mikhail Efremov

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

[Dmitry V. Levin]

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

On Sat, Dec 23, 2017 at 02:21:31PM +0300, Mikhail Efremov wrote:
> On Sat, 23 Dec 2017 03:22:39 +0300 Dmitry V. Levin wrote:
> > On Sat, Dec 23, 2017 at 01:05:13AM +0100, Alexey Gladkov wrote:
> > 2sem: а зачем сборочная зависимость на libxslt?  Это же библиотека,
> > которая должна вытягиваться по зависимостям, если она нужна.
> 
> Невнимательный copy/paste из федорного спека, должно быть xsltproc.

Значит, не нужен ни libxslt, ни xsltproc.  Можно ещё buildreq прогнать.

Я всё же думаю, что ca-certificates и ca-trust лучше не объединять
в единый пакет.  Это разные сущности с разным исходным кодом/данными,
разными циклами обновления, и разными сборочными зависимостями.

Пусть в ca-certificates остаётся /usr/share/ca-certificates/ и
/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit,
а всё остальное отправляется в ca-trust.

Каталоги /etc/pki и /usr/share/pki, видимо, тогда придётся запаковать
в пакет filesystem.


-- 
ldv

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

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

[Alexey V. Vissarionov]

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

On 2017-12-23 14:58:18 +0300, Dmitry V. Levin wrote:

 > Я всё же думаю, что ca-certificates и ca-trust лучше не объединять
 > в единый пакет. Это разные сущности с разным исходным
 > кодом/данными, разными циклами обновления, и разными
 > сборочными зависимостями.
 > Пусть в ca-certificates остаётся /usr/share/ca-certificates/
 > и /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit, а
 > всё остальное отправляется в ca-trust.
 > Каталоги /etc/pki и /usr/share/pki, видимо, тогда придётся
 > запаковать в пакет filesystem.

Если только каталоги - нормально. В любом другом случае лучше
сделать отдельный пакет - например, pki-hier


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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