Происхождение сборки и проверка пакета

Целостность, подпись и происхождение сборки часто называют одним словом «проверка». Они отвечают на разные вопросы. В этом уроке свяжем байты, источник и процесс в авторской карточке, сохраняя предел каждого основания.

evidence-contract.fixture.json в «Контуре выпуска» не является настоящей аттестацией. В нём нет выдуманных сертификатов, Sigstore-записей или контрольных сумм реестра. Все криптографические операции и команды npm остаются невыполненными.

Разные основания одного решения

Integrity позволяет сопоставить полученные байты с ожидаемым отпечатком. Подпись связывает заявление с определённым ключом или идентичностью при выбранной схеме. Provenance описывает происхождение артефакта и связь с процессом сборки. Содержательное ревью оценивает, что делает код. Успешный результат одной проверки не создаёт автоматически успешный результат остальных.

В нашем fixture есть четыре карточки с question, expected_evidence и status. Для integrity ожидается фактический архив и его проверяемое значение. Для provenance — настоящее свидетельство выбранной публикации и условия его проверки. Для ревью — просмотр соответствующего исходника и результата. Пока все значения pending/not_run, и это не исправляется подробным описанием формата.

Возьмём сценарий: архив точно совпал с integrity, но в нём добавлен нежелательный postinstall. Проверка байтов сработала правильно: она подтверждает соответствие ожидаемому архиву. Проблема находится в доверии к содержанию и разрешении выполнения. Нельзя обвинять механизм хеша в том, что он не оценил поведение; это другой вопрос нашей карты.

Другой сценарий: provenance корректно связывает пакет с разрешённым workflow. Если исходная ревизия содержит вредоносное изменение, происхождение может быть подлинным. Это помогает расследованию, но не делает изменение приемлемым. Карточка должна сохранять связь с содержательным решением, а не давать общий зелёный статус «всё безопасно».

Документация npm описывает условия генерации provenance. Они зависят от способа публикации, провайдера и доступности репозитория. Нельзя выводить наличие аттестации только из названия trusted publishing. В нашей карточке условие источника описано, а результат отсутствует. Для реальной операции потребуется проверить соответствующий артефакт и актуальный способ верификации.

Предмет проверки и версия политики

У каждого основания есть subject: что именно проверяется. Наблюдение исходной ветки не равно проверке архива, который отправлен в реестр. Хеш локального README не равен integrity зависимости. Версия политики allowScripts не доказывает, какой процесс её фактически применил. Сохраняем идентификатор предмета рядом со статусом.

В release-record.fixture.json поля source_revision и artifact_digest неизвестны. Это намеренное ограничение: сборки не было, поэтому нет реальных байтов результата. Мы можем описать ожидаемую структуру записи и критерий заполнения. Но вымышленные значения не должны выглядеть как прошедшая криптографическая проверка.

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

Ожидаемый результат — четыре разных основания и договор записи выпуска. Они помогают объяснить отказ: например, источник подлинный, но содержательное ревью не завершено. Последний урок применит такую дисциплину к подозрительному обновлению и восстановлению без уничтожения доказательств.

Не копируйте из официального примера длинную подпись и не приписывайте её своей сборке. Значения относятся к конкретному предмету и процессу, а не служат универсальным украшением JSON. В лаборатории для отсутствующих криптографических сведений используется null и объяснение. Это яснее, чем правдоподобная последовательность символов, которая ничего не подтверждает.

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

Основание	Вопрос, который оно решает
Integrity	Совпадают ли полученные байты с ожидаемым значением, не оценивая полезность кода внутри архива.
Подпись	Какое заявление связано с выбранной идентичностью или ключом при определённой проверяемой схеме доверия.
Provenance	Какой источник и процесс связаны с артефактом, если настоящее свидетельство получено и проверено.
Ревью	Что делает соответствующее содержание и допустимы ли его действия в конкретных стадиях проекта.

Сопоставление основания и предмета

В evidence-contract у каждого вопроса есть subject. Попробуйте заменить предмет integrity с архива пакета на локальный исходник. Механизм сравнения байтов может оставаться корректным, но вывод теперь относится к другому объекту. Именно такая незаметная подмена часто скрывается за словом verified. Карточка должна сохранять точный предмет и статус.

Для provenance предмет также важен: один опубликованный пакет и другая пересборка той же ветки не обязательно имеют одинаковые байты. Источник может совпасть, а окружение либо внешние данные отличиться. Свидетельство происхождения помогает понять связь, но не даёт права считать все будущие результаты тождественными. Поэтому артефакт получает собственный идентификатор.

Если настоящее свидетельство не получено, null — правильное значение. Авторская подпись fixture не подтверждает реестр. В тексте объясняется, какое основание могло бы появиться, но не изображается его успешная проверка. Это особенно важно при создании большого количества уроков: правдоподобный пример должен оставаться явно учебным, когда он описывает криптографический результат.

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

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

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

Полный основной артефакт evidence-contract.fixture.json выбранного состояния:

{
  "fictional": true,
  "not_attestation": true,
  "checks": [
    {
      "question": "integrity",
      "subject": "actual archive not obtained",
      "expected_evidence": "real archive and trusted expected value",
      "status": "not_run"
    },
    {
      "question": "signature",
      "subject": "real statement not obtained",
      "expected_evidence": "actual signature and policy",
      "status": "not_run"
    },
    {
      "question": "provenance",
      "subject": "published package not produced",
      "expected_evidence": "actual attestation and verified conditions",
      "status": "not_run"
    },
    {
      "question": "content_review",
      "subject": "real package code unavailable",
      "expected_evidence": "review of corresponding code",
      "status": "pending"
    }
  ]
}

Все исходники серии: папка lesson-09 содержит полный самостоятельный снимок, собственный проект и авторские модели. Исполнение примеров, npm, установки, аудит, тесты, CI, настройки и публикация не выполнялись.

Первичные источники: provenance, oidc.