On Sun, 07 Apr 2024 20:30:26 +0300 Vitaly Lipatov wrote:
> Обратил внимание, в
> /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
> в отличие от других дистрибутивов, у нас не заполнен (по факту — пуст в 
> свежеустановленной системе).

Бандл сертификатов в ca-certificates генерится из certdata.txt, который
берется из mozilla nss. И там у всех сертификатов указано
CKA_TRUST_CODE_SIGNING CKT_NSS_MUST_VERIFY_TRUST, что
равнозначно CKT_NSS_NOT_TRUSTED. Поэтому objsign-ca-bundle.pem и пуст:
просто нет сертификатов, которые можно использовать для этих целей.
Сертификаты же, добавленные в anchors, можно использовать для любых
целей, поэтому те же сертификаты из ca-certificates-digital.gov.ru
там появляются.
А вот в Fedora в certdata.txt у многих сертификатов стоит
CKA_TRUST_CODE_SIGNING CKT_NSS_TRUSTED_DELEGATOR, поэтому эти
сертификаты будут добавлены в objsign-ca-bundle.pem.
Где они берут такой certdata.txt я не знаю.

> При этом оказалось, что dotnet активно использует сертификаты для 
> проверки подлинности модулей, и в итоге проверить не может.
> 
> В качестве временного хака я добавил
> ca-certificates-nuget.org
> https://packages.altlinux.org/ru/sisyphus/srpms/ca-certificates-nuget.org/
> но он не помогает в больших реальных проектах.

Почему? В objsign-ca-bundle.pem же сертификаты в этом случае
добавляются?

> Какая у нас политика, можем ли мы разместить там все сертификаты для 
> проверки подписи объектников, или допустимо только точечное добавление?
 
Вообще, конечно, логичнее было бы менять значение
CKA_TRUST_CODE_SIGNING в certdata.txt для нужных сертификатов, как в
Fedora. Но вопрос как это делать автоматически, не руками же это менять
каждый раз. Брать certdata.txt из Fedora вместо апстримного мне тоже
кажется не лучшей идеей.
Так что вариант с упаковкой в отдельном пакете может и не плохой.
Впрочем, мантейнер ca-certificates - legion@, тут нужно его мнение.

-- 
WBR, Mikhail Efremov