* [devel] ca-trust и objsign
@ 2024-04-07 17:30 Vitaly Lipatov
2024-04-08 10:24 ` Alexey V. Vissarionov
2024-04-08 16:23 ` Mikhail Efremov
0 siblings, 2 replies; 4+ messages in thread
From: Vitaly Lipatov @ 2024-04-07 17:30 UTC (permalink / raw)
To: ALT Linux Team development discussions
Обратил внимание, в
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
в отличие от других дистрибутивов, у нас не заполнен (по факту — пуст в
свежеустановленной системе).
При этом оказалось, что dotnet активно использует сертификаты для
проверки подлинности модулей, и в итоге проверить не может.
В качестве временного хака я добавил
ca-certificates-nuget.org
https://packages.altlinux.org/ru/sisyphus/srpms/ca-certificates-nuget.org/
но он не помогает в больших реальных проектах.
Какая у нас политика, можем ли мы разместить там все сертификаты для
проверки подписи объектников, или допустимо только точечное добавление?
--
С уважением,
Виталий Липатов,
ALT Linux Team
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [devel] ca-trust и objsign
2024-04-07 17:30 [devel] ca-trust и objsign Vitaly Lipatov
@ 2024-04-08 10:24 ` Alexey V. Vissarionov
2024-04-08 12:00 ` Vitaly Lipatov
2024-04-08 16:23 ` Mikhail Efremov
1 sibling, 1 reply; 4+ messages in thread
From: Alexey V. Vissarionov @ 2024-04-08 10:24 UTC (permalink / raw)
To: ALT Linux Team development discussions
Good ${greeting_time}!
On 2024-04-07 20:30:26 +0300, Vitaly Lipatov wrote:
> Обратил внимание, в
> /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem в отличие
> от других дистрибутивов, у нас не заполнен (по факту пуст в
> свежеустановленной системе).
И это очень хорошо.
> При этом оказалось, что dotnet активно использует сертификаты
> для проверки подлинности модулей, и в итоге проверить не может.
Сертификаты источников этих модулей нужно добавлять явно. И только
тех, которым мы действительно доверяем.
> В качестве временного хака я добавил ca-certificates-nuget.org
> https://packages.altlinux.org/ru/sisyphus/srpms/ca-certificates-nuget.org/
> но он не помогает в больших реальных проектах.
В целом правильно. Лишь бы никто сдуру этот пакет в зависимости
не влепил.
> Какая у нас политика, можем ли мы разместить там все сертификаты
> для проверки подписи объектников, или допустимо только точечное
> добавление?
Насколько я понимаю, строго сформулированной политики нет, но
явное добавление каждого нужного сертификата лично мне видится
единственным разумным решением.
При этом, повторю, зависимостей от пакетов с этими сертификатами
быть не должно: ответственность за их появление в системе нужно
возложить на пользователя, а не на мейнтейнера.
--
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [devel] ca-trust и objsign
2024-04-08 10:24 ` Alexey V. Vissarionov
@ 2024-04-08 12:00 ` Vitaly Lipatov
0 siblings, 0 replies; 4+ messages in thread
From: Vitaly Lipatov @ 2024-04-08 12:00 UTC (permalink / raw)
To: ALT Linux Team development discussions; +Cc: Alexey V. Vissarionov
Alexey V. Vissarionov писал(а) 8.4.24 13:24:
> Good ${greeting_time}!
>
> On 2024-04-07 20:30:26 +0300, Vitaly Lipatov wrote:
>
> > Обратил внимание, в
> > /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem в отличие
> > от других дистрибутивов, у нас не заполнен (по факту пуст в
> > свежеустановленной системе).
>
> И это очень хорошо.
Замечу, что при установке ca-certificates-digital.gov.ru сертификаты
оттуда попадают в objsign.
>
> > При этом оказалось, что dotnet активно использует сертификаты
> > для проверки подлинности модулей, и в итоге проверить не может.
>
> Сертификаты источников этих модулей нужно добавлять явно. И только
> тех, которым мы действительно доверяем.
А в каких местах это доверие может использоваться? Например, в Windows
может проверяться подпись exe-файлов перед выполнением.
А что у нас в системе может быть завязано на эти сертификаты?
...
> Насколько я понимаю, строго сформулированной политики нет, но
> явное добавление каждого нужного сертификата лично мне видится
> единственным разумным решением.
...
> При этом, повторю, зависимостей от пакетов с этими сертификатами
> быть не должно: ответственность за их появление в системе нужно
> возложить на пользователя, а не на мейнтейнера.
Я мог бы вписать это в соответствующее Policy, если нет возражений или
других мнений.
Со своей стороны посмотрю детальнее, как решить возникшую проблему со
сборкой приложений dotnet.
--
С уважением,
Виталий Липатов,
ALT Linux Team
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [devel] ca-trust и objsign
2024-04-07 17:30 [devel] ca-trust и objsign Vitaly Lipatov
2024-04-08 10:24 ` Alexey V. Vissarionov
@ 2024-04-08 16:23 ` Mikhail Efremov
1 sibling, 0 replies; 4+ messages in thread
From: Mikhail Efremov @ 2024-04-08 16:23 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
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
[-- Attachment #2: ЦиÑÑÐ¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑ OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-04-08 16:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-07 17:30 [devel] ca-trust и objsign Vitaly Lipatov
2024-04-08 10:24 ` Alexey V. Vissarionov
2024-04-08 12:00 ` Vitaly Lipatov
2024-04-08 16:23 ` Mikhail Efremov
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git