ALT Linux kernel packages development
 help / color / mirror / Atom feed
From: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
To: alexei@taf.ru,
	ALT Linux kernel packages development
	<devel-kernel@lists.altlinux.org>
Subject: Re: [d-kernel] Ядра без подписи
Date: Tue, 15 Sep 2026 17:15:30 +0300
Message-ID: <aqlTAvCWGz09/ZGz@glebfm.altlinux.org> (raw)
In-Reply-To: <f3ae6ad35ae99ea901acdff5600255258985a7a8.camel@taf.ru>

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

On Tue, Sep 15, 2026 at 08:32:48PM +0800, Alexei Takaseev wrote:
> В Вт, 15/09/2026 в 14:58 +0300, Gleb Fotengauer-Malinovskiy пишет:
> > On Tue, Sep 15, 2026 at 02:39:11PM +0400, Ivan A. Melnikov wrote:
> > > On Mon, Sep 14, 2026 at 02:53:10PM +0300, Gleb Fotengauer-
> > > Malinovskiy wrote:
> > > > On Mon, Sep 14, 2026 at 02:44:27PM +0400, Ivan A. Melnikov wrote:
> > > > > On Mon, Sep 14, 2026 at 06:18:27PM +0800, Alexei Takaseev
> > > > > wrote:
> > > > > > Добрый день!
> > > > > > 
> > > > > > При сборке модуля для ядра kernel-image-rockchip64 получается
> > > > > > вот такое
> > > > > > сообщение:
> > > > > > 
> > > > > > ====
> > > > > > 2026-Sep-14 10:01:58 :: [aarch64] #200 kernel-modules-yt6801-
> > > > > > rockchip64.git sisyphus/kernel-modules-yt6801-rockchip64-
> > > > > > 1.0.31-alt2:
> > > > > > build start
> > > > > > 2026-Sep-14 10:02:50 :: [aarch64] #200: modsigning approved
> > > > > > by cas
> > > > > > 2026-Sep-14 10:03:14 :: [aarch64] remote modsign: failed to
> > > > > > modsign
> > > > > > kernel-modules-yt6801-rockchip64-1.0.31-
> > > > > > alt2.397875.1.aarch64.rpm
> > > > > > ====
> > > > > > 
> > > > > > Действительно, для этого ядра не предусматривается процедура
> > > > > > подписания
> > > > > > модулей внешним ключем. Есть ли у сборочницы крутилки,
> > > > > > выключающие
> > > > > > процедуру подписания там, где она не нужна?
> > > > > 
> > > > > Привет Глеб.
> > > > > 
> > > > > Можешь подсказать, что тут cделать?
> > > > > 
> > > > > Как будто бы сейчас сборка будет работать только если её
> > > > > поаппрувит
> > > > > кто-то из @maint, но не из @modsign.
> > > > 
> > > > По сути, мне кажется, что не предполагалось, что кто-то хочет не
> > > > подписывать модули для ядер.
> > > 
> > > Для массового сервиса, рекомендованного всем и каждому собирателю
> > > ядер, modsign'илке как минимум очень сильно не хватает
> > > документации.
> > 
> > Я согласен, не хватает.  К сожалению, реализация и внедрение подписей
> > произошло практически без ценного вклада этих самых собирателей ядер.
> > К счастью, всё ещё можно сформулировать запрос с вашей стороны,
> > поменять реализацию на подходящую и задокументировать её.
> 
> Собственно, это запрос и есть - иметь возможность вернуть поведение
> сборочницы в первоначальное состояние.

Какой должен быть интерфейс?

В какой степени и как именно сборочница должна не давать вам и другим
мейнтейнерам ядер забыть подписать модули, если modsign всё же
используется?  Почему (кроме отсутствия документации) мейнтейнер ядра
может хотеть отказаться от modsign совсем?  Через какой интерфейс?

> > > > Хотелось бы понять, какое решение тут будет лучше, потому что
> > > > самое
> > > > простое решение: сделать список ядер, модули которых не надо
> > > > подписывать.
> > > 
> > > Мне кажется, что отсутстве ключа для ядра не должно быть ошибкой
> > > в общем случае. Форсить modign нужно только для ядер из
> > > $GB_PESIGN_PACKAGES.
> > 
> > C этим я не очень согласен.  Я не вижу никаких причин не подписывать
> > модули для ядер и это никак не связано с тем, есть ли в ядре enforce
> > подписей и подписывается ли оно с помощью pesign.  Связь есть только
> > в
> > обратную сторону, т.е. если в ядре есть enforce, то модули нельзя не
> > подписывать и если есть pesign, то должен быть enforce.
> > 
> > Но если кому-то очень надо *не подписывать* ядерные модули для
> > конкретного
> > ядра, можно реализовать в сборочнице именно это, хоть мне и кажется,
> > что
> > это странная идея.  Отсутствие же ключа может значить, не только, что
> > майнтейнер ядра не хочет подписывать модули, но и то, что он просто
> > забыл/ошибся при выписывании нового ключа для ядра.
> 
> Идея не странная. Механизм был добавлен и активирован по-сути явочно.
> Со времени первого анонса от 3 июня никакого описания и документации
> так и не появилось.

Что поделать, вводить kernel lockdown нужно было срочно, реализация всё
ещё не устраивает (что значит, что документацию писать может быть рано),
а желающих писать документацию тоже не нашлось.

> Про шаманство с аппрувом от нужной группы для подписи oot модуля
> становится известно из личных переписок.

Такой подход не нов и используется в сборочнице для подписи ядер примерно
с 2013 года.

> "Собиратели ядер" может и не против применения новых возможностей, но
> они должны быть описаны и документированы.

Я всегда готов поделиться любой нужной информацией с теми, кто готов это
задокументировать.

-- 
glebfm

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

  reply	other threads:[~2026-09-15 14:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 10:18 Alexei Takaseev
2026-09-14 10:44 ` Ivan A. Melnikov
2026-09-14 11:53   ` Gleb Fotengauer-Malinovskiy
2026-09-14 12:01     ` Alexei Takaseev
2026-09-14 15:25       ` Alexey V. Vissarionov
2026-09-14 15:44         ` Alexei Takaseev
2026-09-15 10:39     ` Ivan A. Melnikov
2026-09-15 11:58       ` Gleb Fotengauer-Malinovskiy
2026-09-15 12:32         ` Alexei Takaseev
2026-09-15 14:15           ` Gleb Fotengauer-Malinovskiy [this message]
2026-09-15 14:28             ` Konstantin Lepikhov
2026-09-15 15:15               ` Gleb Fotengauer-Malinovskiy
2026-09-16  5:36                 ` Alexey V. Vissarionov
2026-09-15 16:12             ` Alexei Takaseev
2026-09-16  5:28             ` Alexey V. Vissarionov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aqlTAvCWGz09/ZGz@glebfm.altlinux.org \
    --to=glebfm@altlinux.org \
    --cc=alexei@taf.ru \
    --cc=devel-kernel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux kernel packages development

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/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-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \
		devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com
	public-inbox-index devel-kernel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git