Создайте пакет решения о размещении заголовка. Издательство подпишет его, а типография проверит по независимо выбранному исходнику и вводу.
Используйте Native и Bash. В новом каталоге сохраните house-style.lspx, heading.json, prepare-limits.json и evaluation-limits.json из руководства по записям решений. Храните закрытые ключи отдельно от передаваемых файлов.
Подготовьте обе стороны
Получатель независимо проверяет правило и ввод [2, false]. В этом упражнении обе роли выполняются локально. Собственный запуск получателя даёт идентификаторы правила и вычислителя для его политики.
lispex rule run --source house-style.lspx --input heading.json \
--prepare-limits prepare-limits.json \
--eval-limits evaluation-limits.json --out publisher-decision
lispex key generate --out-dir publisher-key
lispex key inspect --public-key publisher-key/public.spki.der
lispex rule run --source house-style.lspx --input heading.json \
--prepare-limits prepare-limits.json \
--eval-limits evaluation-limits.json --out reviewed-decision
lispex rule policy create --dir reviewed-decision \
--public-key publisher-key/public.spki.der \
--consumer-label "Print receiver" --out recipient-policy.jsonВсе команды завершаются с кодом 0. Два запуска печатают решение allow и создают каталоги решений с пятью файлами каждый. Генерация ключа создаёт private.pkcs8.der и public.spki.der и сообщает generated. Проверка ключа сообщает valid. Создание политики записывает recipient-policy.json без стандартного вывода.
При реальном обмене типография получает открытый ключ через выбранный канал проверки. Она выбирает исходник, ввод и исполняемый файл независимо от поступившего пакета.
Проверьте сохранённые файлы
Запуск издательства создаёт в publisher-decision файлы prepared.lpxembed, canonical-input.lpxvalue, result.lpxembed, receipt-core.lpxreceipt и summary.json. Сохраните рядом исходник и ввод.
lispex rule inspect --dir publisher-decision
lispex rule verify --dir publisher-decision
lispex rule replay --dir publisher-decision
lispex decision policy check --policy recipient-policy.jsonВсе четыре команды завершаются с кодом 0 и печатают JSON. Ниже приведены выбранные поля вывода.
| Команда | Поле | Полученное значение |
|---|---|---|
rule inspect | decision, executed | allow, false |
rule verify | status, executed | verified, false |
rule replay | status, fresh_instance | agreed, true |
decision policy check | status | valid |
Просмотр читает сохранённые записи. Проверка сверяет состав файлов и связи между записями. Повторное выполнение создаёт новый экземпляр вычислителя и сравнивает результат и переносимое ядро записи. Ядро содержит правило, ввод, лимиты ресурсов, вычислитель и результат.
Передайте и повторите решение
lispex decision issue --dir publisher-decision \
--private-key publisher-key/private.pkcs8.der \
--issuer-label "Publisher A" --out heading.lpxdecision
lispex decision inspect --bundle heading.lpxdecision
lispex decision authenticate --bundle heading.lpxdecision \
--policy recipient-policy.json
lispex decision replay --bundle heading.lpxdecision \
--policy recipient-policy.jsonВсе четыре команды завершаются с кодом 0 и печатают JSON. Выпуск создаёт heading.lpxdecision и сообщает issued. Просмотр сообщает allow в поле decision и false в поле executed. Аутентификация сообщает true для signature_valid и policy_admitted, а также привязку запроса exact. Повторное выполнение сообщает agreed и true в поле fresh_instance.
Получив результат, приложение решает, размещать ли заголовок. Храните точные исходник, ввод, пакет и политику получателя в записи задания. Закрытый ключ остаётся у издательства.
Выпустите Ваучер из образа правила
В отдельном каталоге выполните упражнение с Ваучером. Оно подготавливает print-handoff.lspx, input.checked.json, policy.json и ключ издателя. Ввод содержит четыре результата проверки и редакцию окончательного файла edition-final.
Оставьте в ISSUER_KEY_URI абсолютный путь к закрытому ключу издателя. Выполните следующие команды в каталоге Ваучера, выбирая новые выходные пути.
lispex image encode --source print-handoff.lspx --out print-handoff.lspx.png
lispex image inspect --image print-handoff.lspx.png
lispex vouch source-id --source-image print-handoff.lspx.png
lispex vouch issue --source-image print-handoff.lspx.png \
--input input.checked.json --profile csk.checked-profile/v1 \
--key-handle "$ISSUER_KEY_URI" --out-dir image-issued --emit-bundle
lispex vouch gate --bundle image-issued/vouch-input-bundle.json \
--trust-policy policy.json --source-image print-handoff.lspx.png \
--input input.checked.json --profile csk.checked-profile/v1 \
--require-decision approve --report-out image-gate.jsonВсе пять команд завершаются с кодом 0. Кодирование создаёт print-handoff.lspx.png и печатает сводку образа. Просмотр снова печатает сводку. source-id выводит тот же идентификатор исходника, что и для текстового файла.
Выпуск и проверка gate ничего не печатают. В image-issued появляются issue-report.json, payload.json, envelope.dsse.json и vouch-input-bundle.json. Отчёт выпуска содержит issued-native. Следующие поля взяты из image-gate.json.
| Поле | Полученное значение |
|---|---|
authentication.status | authenticated |
comparison.current_vs_signed | agree |
reexecution.status | execution-agreed |
gate.observed_decision | approve |
gate.status | granted |
Ваучер начинает работу со своего правила и проверяемого ввода. Получатель выбирает собственную политику и независимо передаёт образ исходника и ввод. После новой проверки gate приложение разрешает печать.
Для конкретного задания следуйте руководству о действиях приложения. Оно подписывает все девять значений, добавляя идентификатор запроса, исполнителя, действие и срок действия. Храните пакет запроса отдельно от учебного пакета с пятью значениями.
Просмотрите готовое рабочее пространство
Native также предоставляет workspace status для фиксированного примера examples/refund-workspace в репозитории. Из корня репозитория создайте отдельный пустой каталог для проверки расположения результатов.
mkdir -p ../workspace-status-work
lispex workspace status --dir examples/refund-workspace \
--work-dir ../workspace-status-workОбе команды завершаются с кодом 0. Команда состояния печатает JSON со значением manifest-match в workspace_integrity. Массив candidate_invocations пуст, все восемь мест для результатов отмечены как absent.
Команда один раз преобразует каждый корень из --dir и --work-dir в реальный путь, затем открывает его. Ссылки внутри корней и ссылки, появившиеся в разрешённом пути до открытия, отклоняются. JSON состояния не содержит абсолютных путей корней.
Значение present-unchecked означает, что по указанному пути есть файл или каталог. Аутентифицируйте запись и выполните новую проверку gate для запроса перед разрешением действия в приложении.
Эта команда принимает фиксированные манифест и состав файлов готового примера. Новый каталог вёрстки вызывает workspace-manifest-invalid и код завершения 3. Для файлов вёрстки выше используйте показанные здесь rule verify, аутентификацию и повторное выполнение решения, а также проверку gate Ваучера.