[Unofficial] [Plugin] dsh-pack — Portable, signed and verifiable DSH Agent Artifacts with OCI-distributed Evidence

[WHY-Daydream]

Important

Unofficial / Community Project

dsh-pack is an independently developed and maintained third-party project.
It is not an official DeepSeek or DeepSeek Harness project, and is not
affiliated with or endorsed by DeepSeek.

Please review the project information, source code, trust model and
installation instructions independently before use.

dsh-pack

dsh-pack is a community plugin for building portable, reproducible and
verifiable DSH Agent Artifacts, with OCI-based image and Evidence distribution.

It started as a small experiment around reproducible DSH Profile snapshots,
but gradually evolved into an application-level Agent Artifact / supply-chain
layer for DSH.

The current release is:

v0.6.1 — Latest DSH compatibility fix

---

What problem does it solve?

DSH Profiles are naturally composable and editable on a local machine.

But once an Agent/Profile needs to move between developers, CI, servers or
registries, several questions appear:

• How do I reproduce the same runnable profile on another machine?
• How do I vendor local file: / link: dependencies?
• How do I know that the artifact I received is the same one that was built?
• Who signed it?
• What source and dependencies were used to build it?
• What capabilities does it declare?
• What capabilities were actually observed at runtime?
• Can I distribute it through an OCI Registry?
• Can I attach Evidence without changing the Agent Artifact itself?
• Can a Registry or cache accidentally become a source of Trust?
• Can Trust be evaluated before package lifecycle execution or materialization?

dsh-pack tries to make these boundaries explicit.

---

Evolution

v0.1   Snapshot
  ↓
v0.2   Portable
  ↓
v0.3   Trusted
  ↓
v0.4   Runnable Agent Image
  ↓
v0.4.1 OCI Distribution
  ↓
v0.4.2 Distribution Governance
  ↓
v0.5   Verifiable Agent Artifact
  ↓
v0.6   Distributed Verifiable Evidence
  ↓
v0.6.1 Current DSH Compatibility

[liyangbing]

把 artifact identity 和 trust policy 绑定起来

这里列出的区分很重要：configHash、contentHash、lock、cache、registry 和 OCI digest 解决的不是同一个问题。要让 Agent artifact 可复现和可治理，发布物必须绑定到可验证的内容身份，而不能只依赖 registry tag 或当前 profile 配置。

建议在进入可安装/可运行状态前固定这些证据：
1. OCI image digest、插件 tarball integrity、完整 Git commit、DSH/Node/pnpm/OS 矩阵和 SBOM 指向同一份构建输入。
2. 分别记录 profile manifest、Bundle patch、lockfile、依赖闭包和运行时注册的 tools/skills；配置 hash 不能替代代码内容 hash。
3. 在 materialize 前验证签名、发布者身份、digest 和策略；签名通过不等于拥有最小权限，也不等于运行时兼容。
4. 在隔离 profile 中做 cold boot、工具调用、网络/文件/进程效果和卸载回滚测试；失败时不能污染生产 profile 或凭据。
5. 对缓存命中、registry 更新、依赖重新解析和跨平台 native artifact 做 negative tests，确保“可复现”不被 mutable latest 或隐式 prepare 脚本破坏。

我整理了两份独立社区手册，分别覆盖插件打包/安装的可复现边界与供应链审计：First plugin lab 和 Community Plugin Audit。它们不是官方 DeepSeek 信任根，也不代表对 dsh-pack 的认证或背书；最终应以精确 artifact、签名策略和实际运行矩阵为准。

[WHY-Daydream]

感谢这组建议，这和 dsh-pack 目前的 identity/trust 分层非常契合。当前实现刻意区分了 configHash、DSH contentHash、OCI blob digest、OCI manifest digest，并保持 Lock ≠ Trust、VALID ≠ TRUSTED、Registry ≠ Trust Authority。运行路径上也要求 OCI integrity → DSH integrity → Signature → Trust 在 materialize 前完成。

我比较认同下一步应该补的是 evidence/attestation，而不是把这些 identity 合并成一个 hash，也不是把 trust policy 嵌入 artifact。更倾向于让 provenance 明确绑定 contentHash，记录 Git commit、lockfile/dependency closure、DSH/Node/pnpm/OS/arch 和 SBOM；再通过 isolated cold boot 生成单独的 runtime capability/acceptance attestation，记录实际注册的 tools/skills/services 以及 filesystem/network/process/rollback 检查。

之后 trust.yaml 可以要求某个 immutable artifact identity 必须同时满足指定 signer、provenance、runtime matrix 和 attestation，形成 “policy evaluates evidence bound to artifact identity” 的模型。

你提到的 configHash 不能替代代码内容身份、native artifact / prepare script / mutable cache 的 negative tests 我也认同，准备补进后续测试矩阵。

也感谢你给的两份 handbook，我会对照其中的 isolated profile、published tarball integrity、before/after composition 和 cleanup evidence 再检查当前边界。

[Gniy7Ga]

提示：本帖介绍的项目或社群并非 DeepSeek 或 DeepSeek Harness 官方运营，请大家自行甄别信息与链接，并注意账号、隐私和资产安全。

如需在本社区发布第三方项目介绍，请在标题或正文开头显著注明“非官方 / Unofficial”，并避免使用可能让人误认为官方的表述。

[WHY-Daydream]

感谢提醒，已经修改标题，并在正文开头显著标注了“非官方 / Unofficial”，同时补充说明 dsh-pack 是独立开发和维护的第三方社区项目，并非 DeepSeek 或 DeepSeek Harness 官方项目。
后续发布相关第三方项目时，我也会注意明确标注非官方身份，避免产生误解。

[WHY-Daydream]

Update — v0.6.0 released

A fairly large update since the original post.

dsh-pack has evolved from portable/signed DSH runtime snapshots into a
verifiable Agent Artifact + distributed Evidence model.

The two major milestones since this discussion was opened are:

v0.5 — Verifiable Agent Artifact

Added:

• signed Build Provenance
• CycloneDX SBOM
• Declared Capability Manifest
• Runtime Attestation
• Trust Policy v2
• Evidence issuer trust
• adversarial supply-chain testing

v0.6 — Distributed Verifiable Evidence

Added:

• OCI Evidence publication / discovery
• OCI Referrers + standard fallback
• remote Evidence cache
• remote Trust integration
• real GHCR interoperability
• real ORAS interoperability
• adversarial Registry / pagination / cache testing

One principle I tried hard to preserve through the design is:

Registry ≠ Trust Authority

Remote Evidence may be discovered, downloaded and cryptographically valid,
but executable authorization is still evaluated using the current local
Trust Policy before materialization.

Release:
https://github.com/WHY-Daydream/dsh-pack/releases/tag/v0.6.0

I'd especially appreciate feedback on whether the Artifact / Evidence split
feels like a useful abstraction for DSH, and whether any part of this should
eventually become an upstream capability seam.

[WHY-Daydream]

Update — v0.6.1 released

dsh-pack has continued evolving since the original post.

v0.5 — Verifiable Agent Artifact

Added:

• signed Build Provenance
• CycloneDX SBOM
• Declared Capability Manifest
• Runtime Attestation
• Trust Policy v2
• Evidence issuer trust
• adversarial supply-chain testing

v0.6 — Distributed Verifiable Evidence

Added:

• OCI Evidence publication / discovery
• OCI Referrers + standard fallback
• remote Evidence cache
• remote Trust integration
• real GHCR interoperability
• real ORAS interoperability
• adversarial Registry / pagination / cache testing

The main design principle remains:

Registry ≠ Trust Authority

Remote Evidence can be discovered and transported through OCI registries,
but executable authorization is still evaluated using the current local
Trust Policy before materialization.

v0.6.1 — Latest DSH compatibility fix

v0.6.1 is a compatibility patch for current DSH 0.1.x prerelease lines.

It fixes npm semver prerelease matching for @deepseek-ai/dsh-app-boot
and was validated through a compatibility acceptance matrix including:

• DSH 0.1.0-rc.6
• DSH 0.1.1-rc.2
• DSH 0.1.2-rc.1
• current 0.1.3-alpha.1 source API compatibility
• real dsh plugin add
• /pack registration
• pack → verify → install golden path
• full regression suite

Current release:

https://github.com/WHY-Daydream/dsh-pack/releases/tag/v0.6.1

npm:

https://www.npmjs.com/package/@why-daydream/dsh-pack

I'd still be very interested in feedback on:

• whether the Agent Artifact / Evidence split fits DSH well
• whether any of these abstractions should become upstream capability seams
• whether distributed Evidence is useful for shared / enterprise DSH environments