[d-kernel] Ядра без подписи

[d-kernel] Ядра без подписи

[Alexei Takaseev]

Добрый день!

При сборке модуля для ядра 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
====

Действительно, для этого ядра не предусматривается процедура подписания
модулей внешним ключем. Есть ли у сборочницы крутилки, выключающие
процедуру подписания там, где она не нужна?

Re: [d-kernel] Ядра без подписи

[Ivan A. Melnikov]

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

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.

-- 
  wbr,
    iv m.

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

Re: [d-kernel] Ядра без подписи

[Gleb Fotengauer-Malinovskiy]

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

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.

По сути, мне кажется, что не предполагалось, что кто-то хочет не
подписывать модули для ядер.

Хотелось бы понять, какое решение тут будет лучше, потому что самое
простое решение: сделать список ядер, модули которых не надо подписывать.

-- 
glebfm

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

Re: [d-kernel] Ядра без подписи

[Alexei Takaseev]

В Пн, 14/09/2026 в 14:53 +0300, Gleb Fotengauer-Malinovskiy пишет:
> 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.
> 
> По сути, мне кажется, что не предполагалось, что кто-то хочет не
> подписывать модули для ядер.
> 
> Хотелось бы понять, какое решение тут будет лучше, потому что самое
> простое решение: сделать список ядер, модули которых не надо
> подписывать.

А сборочница не может отследить, есть ли для данного ядра внешние
ключ/сертификат, и при их отсутствии не запускать процедуру подписи?

Re: [d-kernel] Ядра без подписи

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2026-09-14 20:01:03 +0800, Alexei Takaseev wrote:

 >> По сути, мне кажется, что не предполагалось, что кто-то хочет
 >> не подписывать модули для ядер.

В случае off-tree сборки это зачастую печальная необходимость.

 >> Хотелось бы понять, какое решение тут будет лучше, потому
 >> что самое простое решение: сделать список ядер, модули
 >> которых не надо подписывать.

Это неправильное решение.

 > А сборочница не может отследить, есть ли для данного ядра
 > внешние ключ/сертификат, и при их отсутствии не запускать
 > процедуру подписи?

Я у себя реализовал это так: есть два пакета, один из которых
содержит готовую пару из ключа RSA-8192 и сертификата для него
(kernel-cert-data), а второй (kernel-cert-empty) ничего не
содержит, но тоже предоставляет сборочную зависимость ядра от
kernel-cert. Если при сборке установлен kernel-cert-data - его
содержимое копируется в каталог с исходниками, а если пустой
пакет kernel-cert-empty - ключ и сертификат сгенерируются при
сборке ядра. Разумеется, при этом kernel-cert-data во внешнюю
репу не выкладывается, а доступен только локально.


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

Re: [d-kernel] Ядра без подписи

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Alexey V. Vissarionov" <gremlin@altlinux.org>
> Кому: alexei@taf.ru, "ALT Linux kernel packages development" <devel-kernel@lists.altlinux.org>
> Отправленные: Понедельник, 14 Сентябрь 2026 г 23:25:40
> Тема: Re: [d-kernel] Ядра без подписи

> Good ${greeting_time}!
> 
> On 2026-09-14 20:01:03 +0800, Alexei Takaseev wrote:
> 
> >> По сути, мне кажется, что не предполагалось, что кто-то хочет
> >> не подписывать модули для ядер.
> 
> В случае off-tree сборки это зачастую печальная необходимость.
> 
> >> Хотелось бы понять, какое решение тут будет лучше, потому
> >> что самое простое решение: сделать список ядер, модули
> >> которых не надо подписывать.
> 
> Это неправильное решение.
> 
> > А сборочница не может отследить, есть ли для данного ядра
> > внешние ключ/сертификат, и при их отсутствии не запускать
> > процедуру подписи?
> 
> Я у себя реализовал это так: есть два пакета, один из которых
> содержит готовую пару из ключа RSA-8192 и сертификата для него
> (kernel-cert-data), а второй (kernel-cert-empty) ничего не
> содержит, но тоже предоставляет сборочную зависимость ядра от
> kernel-cert. Если при сборке установлен kernel-cert-data - его
> содержимое копируется в каталог с исходниками, а если пустой
> пакет kernel-cert-empty - ключ и сертификат сгенерируются при
> сборке ядра. Разумеется, при этом kernel-cert-data во внешнюю
> репу не выкладывается, а доступен только локально.

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

Re: [d-kernel] Ядра без подписи

[Ivan A. Melnikov]

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'илке как минимум очень сильно не хватает документации.

> Хотелось бы понять, какое решение тут будет лучше, потому что самое
> простое решение: сделать список ядер, модули которых не надо подписывать.

Мне кажется, что отсутстве ключа для ядра не должно быть ошибкой
в общем случае. Форсить modign нужно только для ядер из $GB_PESIGN_PACKAGES.

-- 
  wbr,
    iv m.

Re: [d-kernel] Ядра без подписи

[Gleb Fotengauer-Malinovskiy]

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

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'илке как минимум очень сильно не хватает документации.

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

> > Хотелось бы понять, какое решение тут будет лучше, потому что самое
> > простое решение: сделать список ядер, модули которых не надо подписывать.
> 
> Мне кажется, что отсутстве ключа для ядра не должно быть ошибкой
> в общем случае. Форсить modign нужно только для ядер из $GB_PESIGN_PACKAGES.

C этим я не очень согласен.  Я не вижу никаких причин не подписывать
модули для ядер и это никак не связано с тем, есть ли в ядре enforce
подписей и подписывается ли оно с помощью pesign.  Связь есть только в
обратную сторону, т.е. если в ядре есть enforce, то модули нельзя не
подписывать и если есть pesign, то должен быть enforce.

Но если кому-то очень надо *не подписывать* ядерные модули для конкретного
ядра, можно реализовать в сборочнице именно это, хоть мне и кажется, что
это странная идея.  Отсутствие же ключа может значить, не только, что
майнтейнер ядра не хочет подписывать модули, но и то, что он просто
забыл/ошибся при выписывании нового ключа для ядра.

-- 
glebfm

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

Re: [d-kernel] Ядра без подписи

[Alexei Takaseev]

В Вт, 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'илке как минимум очень сильно не хватает
> > документации.
> 
> Я согласен, не хватает.  К сожалению, реализация и внедрение подписей
> произошло практически без ценного вклада этих самых собирателей ядер.
> К счастью, всё ещё можно сформулировать запрос с вашей стороны,
> поменять реализацию на подходящую и задокументировать её.

Собственно, это запрос и есть - иметь возможность вернуть поведение
сборочницы в первоначальное состояние.

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

Идея не странная. Механизм был добавлен и активирован по-сути явочно.
Со времени первого анонса от 3 июня никакого описания и документации
так и не появилось. Про шаманство с аппрувом от нужной группы для
подписи oot модуля становится известно из личных переписок.

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

Re: [d-kernel] Ядра без подписи

[Gleb Fotengauer-Malinovskiy]

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

Re: [d-kernel] Ядра без подписи

[Konstantin Lepikhov]

Hi Gleb!

On 09/15/2026, at 05:15:30 PM you wrote:

<skip>
> > Собственно, это запрос и есть - иметь возможность вернуть поведение
> > сборочницы в первоначальное состояние.
> 
> Какой должен быть интерфейс?
> 
> В какой степени и как именно сборочница должна не давать вам и другим
> мейнтейнерам ядер забыть подписать модули, если modsign всё же
> используется?  Почему (кроме отсутствия документации) мейнтейнер ядра
> может хотеть отказаться от modsign совсем?  Через какой интерфейс?
Если мантейнер хочет просто собрать ядро в сизиф со сторонними модулями,
без заморочек с lockdown и получением грантов/сертификатов, он это может
сделать прямо сейчас без лишних телодвижений? Без скрытых аппрувов из
неизвестных групп?

<skip>
> Что поделать, вводить kernel lockdown нужно было срочно, реализация всё
> ещё не устраивает (что значит, что документацию писать может быть рано),
> а желающих писать документацию тоже не нашлось.
Глеб, давай не перекладывать проблему с больной головы на здоровую. Кому
потребовался lockdown? Вангую, что не мантейнеру ядер rockchip, а некому
сотруднику ООО в рамках НИОКР/гранта/коммерческого проекта. Тогда причем
тут эти отмазки про "нехватку времени", уважайте чужой труд и примите
факт, что altlinux team не ограничивается кадровым составом Базальта.

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


-- 
WBR et al.

Re: [d-kernel] Ядра без подписи

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Tue, Sep 15, 2026 at 04:28:39PM +0200, Konstantin Lepikhov wrote:
> Hi Gleb!
> 
> On 09/15/2026, at 05:15:30 PM you wrote:
> 
> <skip>
> > > Собственно, это запрос и есть - иметь возможность вернуть поведение
> > > сборочницы в первоначальное состояние.
> > 
> > Какой должен быть интерфейс?
> > 
> > В какой степени и как именно сборочница должна не давать вам и другим
> > мейнтейнерам ядер забыть подписать модули, если modsign всё же
> > используется?  Почему (кроме отсутствия документации) мейнтейнер ядра
> > может хотеть отказаться от modsign совсем?  Через какой интерфейс?
> Если мантейнер хочет просто собрать ядро в сизиф со сторонними модулями,
> без заморочек с lockdown и получением грантов/сертификатов, он это может
> сделать прямо сейчас без лишних телодвижений?

Да.

> Без скрытых аппрувов из неизвестных групп?

Да, без явных (других у нас нет) аппрувов от хорошо известных групп.

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

Вопрос не в том, кому потребовался lockdown (он потребовался потому что
это требование к подписи сертификатов у Microsoft, которое нужно для
Secure Boot, которое нужно отнюдь не только компании), вопрос в том, какие
ядра в Сизифе и бранчах будут содержать сертификат и какие модули будет
подписывать сборочница.  Я убеждён, что подписывать нужно все ядерные OOT
модули для всех ядер и это мнение не имеет совершенно никакого отношения к
lockdown.

-- 
glebfm

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

Re: [d-kernel] Ядра без подписи

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>
> Кому: alexei@taf.ru, "ALT Linux kernel packages development" <devel-kernel@lists.altlinux.org>
> Отправленные: Вторник, 15 Сентябрь 2026 г 22:15:30
> Тема: Re: [d-kernel] Ядра без подписи

> 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'илке как минимум очень сильно не хватает
>> > > документации.
>> > 
>> > Я согласен, не хватает.  К сожалению, реализация и внедрение подписей
>> > произошло практически без ценного вклада этих самых собирателей ядер.
>> > К счастью, всё ещё можно сформулировать запрос с вашей стороны,
>> > поменять реализацию на подходящую и задокументировать её.
>> 
>> Собственно, это запрос и есть - иметь возможность вернуть поведение
>> сборочницы в первоначальное состояние.
> 
> Какой должен быть интерфейс?

Что мешает это делать через отдельную команду сборочницы при сохранении нынешней логики?
Механизм аппрува от группы оказался неустойчивым для "гонки состояний". Все началось с
того, что участник групп @maint и @modsign выдал свой аппрув именно как @maint.

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

См. выше про отдельную команду.

Re: [d-kernel] Ядра без подписи

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2026-09-15 17:15:30 +0300, Gleb Fotengauer-Malinovskiy wrote:

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

Так дела не делаются.

Лично меня в свое время один умный человек научил интересному и
эффективному способу: начинать разработку с написания man page.
Оно в любом случае понадобится, и при этом практически заменяет
ТЗ для одиночного разработчика или небольшой группы.

Попробуй - времени оно занимает немного, а уже формализованные
хотелки и в реализации проще.


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

Re: [d-kernel] Ядра без подписи

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2026-09-15 18:15:17 +0300, Gleb Fotengauer-Malinovskiy wrote:


 >> Кому потребовался lockdown?
 > Вопрос не в том, кому потребовался lockdown (он потребовался
 > потому что это требование к подписи сертификатов у Microsoft,
 > которое нужно для Secure Boot, которое нужно отнюдь не
 > только компании)

Там, где реально требуется secure boot, можно и на владельца
оборудования спихнуть задачу по добавлению сертификата.

Но это ж придется инструкцию писать...


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