feat(build, stapel): sign files matched by a glob pattern

.agents/skills/werf-to-delivery-kit/SKILL.md

@@ -332,7 +332,7 @@ import:
 
 - Формат подписи фиксирован: отсоединённый PKCS#7 (CMS) `SignedData`, SHA-256, RSASSA-PKCS1-v1_5, без подписываемых атрибутов, со встроенным leaf-сертификатом (intermediates не встраиваются) — как у `systemd-keyutil pkcs7` / `openssl smime -sign -binary -noattr -outform der`. Ключ только RSA. Если старая сборка делала то же самое — переписывать на `sign:`; иначе (в т.ч. потребителю нужна встроенная цепочка) — стоп-условие.
 - Все `sign:` одного запуска delivery-kit используют **одну** пару ключ/сертификат. Сверить, каким ключом подписывается каждый файл; если в конфиге сейчас разные ключи для разных файлов — остановиться и согласовать с пользователем, не объединять ключи и не менять CI.
-- `path` — абсолютный путь к обычному файлу (не каталог), каждый `path` один раз. Позиция: без `before`/`after` — в конце образа (по умолчанию, предпочтительно); `before|after: install|setup` — на границе стадии, тогда `.p7s` виден следующим стадиям. `before` и `after` вместе — ошибка.
+- `path` — абсолютный путь к обычному файлу (не каталог) либо, если содержит `*`, абсолютный glob-шаблон (`*` в пределах сегмента, `**` через сегменты; остальные символы, включая `?[{`, буквальные — экранирование не нужно; delivery-kit > v3.12.0-dk.2), раскрываемый по файловой системе образа на стадии подписи: шаблон начинается с буквального каталога ниже `/`, каждый подошедший обычный файл получает свой `<file>.p7s`, ниже базового каталога симлинки не сопоставляются и не разыменовываются, пустое раскрытие — ошибка сборки. Шаблон — единственный способ подписать набор файлов, известный только после сборки (модули ядра после `make modules_install`: `path: /out/lib/modules/**/*.ko`). Каждый файл — один раз (литерал и шаблон, покрывающие один файл на одной позиции, — ошибка). Позиция: без `before`/`after` — в конце образа (по умолчанию, предпочтительно); `before|after: install|setup` — на границе стадии, тогда `.p7s` виден следующим стадиям. `before` и `after` вместе — ошибка.
 - Проверку подписи, которая раньше шла сразу после подписания, не удалять — перенести: стадия, которая производит файл, своей подписи не видит. Файл из `install` → `after: install`, проверка в `beforeSetup`/`setup`; файл из `beforeSetup` → `before: setup`, проверка в `setup`; файл из `setup` (последняя shell-стадия) → подпись без `before`/`after`, проверка в отдельном образе, который импортирует файл и `.p7s`. Если сохранить проверку так не получается — стоп-условие. Если проверке нужен `openssl` — пакет в `spec:` os-pm.
 - Зависимые образы, которые импортировали подписанный файл, импортируют и `<path>.p7s`.
 - Удалить вход в Vault и вызовы подписи из shell. `secrets:` с `VAULT_*`/JWT, `mount:` с клиентом Vault (`d8`, `vault`), запрос сертификата из shell и соответствующие `secrets.allowEnvVariables`/`mount.allowFromPaths` в `werf-giterminism.yaml` удалять только после проверки всех их использований: если они нужны другому образу или проверке подписи (например, CA-сертификат) — оставить.
@@ -427,4 +427,4 @@ head -1 <путь-к-каталогу>
 - Нет нужного OS-пакета/образа в файле базовых образов → **прекратить** переписывание, сообщить пользователю: запросить пакет у команды container-base. Для менеджеров языковых экосистем (yarn, pnpm, uv, poetry) сначала применить `manager:` (§3).
 - Не удаётся заменить сетевую shell-команду ни одной директивой (`git:`/`packages:`/`vex:`/`sign:`) → не оставлять её в shell "как есть" и не изобретать обходы, а зафиксировать проблему и спросить пользователя (типовые случаи — fuzz и svace, см. §4).
 - Пакет из pm не работает (`symbol lookup error`, нет манифеста в registry) → это дефект container-base, не конфига: сообщить пользователю, не тащить бинарь/библиотеку из другого базового образа через `import`.
-- Подпись в shell не сводится к отсоединённому PKCS#7 RSA/SHA-256 рядом с файлом (подпись встраивается в сам файл — Authenticode/`pesign`, `sbsign`, подпись модулей ядра; голая подпись без CMS; не-RSA ключ; подписываемые атрибуты) → `sign:` её не заменяет: не переписывать этот образ и не изобретать обходы, зафиксировать и сообщить пользователю.
+- Подпись в shell не сводится к отсоединённому PKCS#7 RSA/SHA-256 рядом с файлом (подпись встраивается в сам файл — Authenticode/`pesign`, `sbsign`; голая подпись без CMS; не-RSA ключ; подписываемые атрибуты) → `sign:` её не заменяет: не переписывать этот образ и не изобретать обходы, зафиксировать и сообщить пользователю. Подпись модулей ядра — исключение: `scripts/sign-file -s <p7s> sha256 <x509> <ko>` дописывает к модулю именно отсоединённый PKCS#7 (`-s` берёт готовую подпись, `<x509>` при этом не читается), поэтому она сводится к `sign:` с glob (`after: install`) и `sign-file -s` + `rm *.p7s` в `beforeSetup`.

docs/_data/werf_yaml.yml

@@ -941,8 +941,8 @@ sections:
           - name: path
             value: "string"
             description:
-              en: "The absolute path of the file to sign; the detached PKCS#7 signature is written next to it as `<path>.p7s`"
-              ru: "Абсолютный путь к подписываемому файлу; отсоединённая подпись PKCS#7 записывается рядом как `<path>.p7s`"
+              en: "The absolute path of the file to sign, or an absolute glob pattern matching the files to sign; the detached PKCS#7 signature of each file is written next to it as `<path>.p7s`"
+              ru: "Абсолютный путь к подписываемому файлу либо абсолютный glob-шаблон подписываемых файлов; отсоединённая подпись PKCS#7 каждого файла записывается рядом как `<path>.p7s`"
           - name: before
             value: "string"
             description:

docs/pages_en/usage/build/stapel/imports.md

@@ -113,7 +113,15 @@ sign:
   after: install
 ```
 
-Entries at the same signing position must not use another entry's `<path>.p7s` as an input. For example, `path: /out/x` and `path: /out/x.p7s` at the same position are a configuration error, regardless of their order in the list. To sign a generated signature, put the second entry at a later signing position.
+A `path` containing `*` is a glob pattern, expanded against the image filesystem when the signing stage runs: every regular file it matches gets its own `<file>.p7s`. `*` matches within one path segment and `**` across segments; every other character, `?`, `[` and `{` included, stands for itself, so a literal path such as `/out/file[1].bin` needs no escaping (a file with `*` in its name cannot be signed). The pattern must start with a literal directory below `/` (`/out/**/*.ko`, not `/**/*.ko`). Below that directory symlinks are neither matched nor followed, so a file is signed under its real path only; a hard link is a regular file under another name and is signed under each. A pattern that matches nothing fails the build — a declared signature is a requirement of the image, not a hint. This is how a set of files known only after the build is signed, such as the kernel modules `make modules_install` produces:
+
+```yaml
+sign:
+- path: /out/lib/modules/**/*.ko
+  after: install
+```
+
+Entries at the same signing position must not use another entry's `<path>.p7s` as an input. For example, `path: /out/x` and `path: /out/x.p7s` at the same position are a configuration error, regardless of their order in the list. The same holds for the files a pattern expands to, and a file reached through two entries is an error as well; both are detected when the pattern is expanded. To sign a generated signature, put the second entry at a later signing position.
 
 werf reads the file out of the image built so far, signs it on the build host and adds `<path>.p7s` as a new layer. The signature is a detached PKCS#7 (CMS) `SignedData` over the file content — SHA-256, RSASSA-PKCS1-v1_5, no authenticated attributes, the signing certificate embedded — the same shape `systemd-keyutil pkcs7` produces, so systemd and the Linux kernel accept it as a dm-verity root hash signature. The key therefore has to be RSA.
 

docs/pages_ru/usage/build/stapel/imports.md

@@ -113,7 +113,15 @@ sign:
   after: install
 ```
 
-Записи с одинаковой позицией подписания не могут использовать `<path>.p7s` другой записи как входной файл. Например, `path: /out/x` и `path: /out/x.p7s` на одной позиции — ошибка конфигурации независимо от их порядка в списке. Чтобы подписать созданную подпись, задайте второй записи более позднюю позицию подписания.
+`path`, содержащий `*`, — glob-шаблон: он раскрывается по файловой системе образа в момент выполнения стадии подписания, и каждый подошедший обычный файл получает свой `<file>.p7s`. `*` соответствует части одного сегмента пути, `**` — любому числу сегментов; все остальные символы, включая `?`, `[` и `{`, обозначают сами себя, поэтому буквальный путь вроде `/out/file[1].bin` не требует экранирования (файл с `*` в имени подписать нельзя). Шаблон должен начинаться с буквального каталога ниже `/` (`/out/**/*.ko`, но не `/**/*.ko`). Ниже этого каталога символические ссылки не сопоставляются и не разыменовываются, поэтому файл подписывается только под своим настоящим путём; жёсткая ссылка — это обычный файл под другим именем, он подписывается под каждым. Шаблон, которому не соответствует ни один файл, останавливает сборку — объявленная подпись является требованием к образу, а не пожеланием. Так подписывается набор файлов, который известен только после сборки, например модули ядра, которые создаёт `make modules_install`:
+
+```yaml
+sign:
+- path: /out/lib/modules/**/*.ko
+  after: install
+```
+
+Записи с одинаковой позицией подписания не могут использовать `<path>.p7s` другой записи как входной файл. Например, `path: /out/x` и `path: /out/x.p7s` на одной позиции — ошибка конфигурации независимо от их порядка в списке. То же относится к файлам, в которые раскрывается шаблон; файл, достижимый через две записи, — тоже ошибка. И то и другое обнаруживается при раскрытии шаблона. Чтобы подписать созданную подпись, задайте второй записи более позднюю позицию подписания.
 
 werf читает файл из собранного к этому моменту образа, подписывает его на сборочном хосте и добавляет `<path>.p7s` новым слоем. Подпись — отсоединённый PKCS#7 (CMS) `SignedData` над содержимым файла: SHA-256, RSASSA-PKCS1-v1_5, без аутентифицированных атрибутов, со встроенным сертификатом подписанта — ровно та форма, которую производит `systemd-keyutil pkcs7`, поэтому systemd и ядро Linux принимают её как подпись dm-verity root hash. Ключ, соответственно, должен быть RSA.