Redential/redential-cli

# Redential CLI [](https://www.npmjs.com/package/@redential/cli) [](https://github.com/Redential/redential-cli/actions/workflows/ci.yml) [](LICENSE) 你最出色的作品可能正处于 NDA 之下。 将私密工作转化为符合 NDA 要求的开发者凭证。你的代码永远不会 离开你的本机。 ``` npx redential scan ``` 无需登录，无需配置，无需全局安装。`scan` 完全在本地运行，并且 不会发起任何网络调用。 [官网](https://redential.com) · [信任模型](#trust-model) · [常见问题](#faq) · [文档](#docs) ## 工作原理 Redential CLI 会在本地分析 git 历史和实现模式， 然后生成一个有边界的元数据包，用于描述在你无法连接的仓库中检测到的 技能和能力。 在上传任何内容之前，你可以查看确切的元数据包。如果你选择 提交它，Redential 会将该证据添加到一个你可以分享的 [**已认证的能力档案**](#what-does-attested-actually-prove)中。 你的源代码永远不会离开你的本机。 ## 运行方式 当你希望将结果显示在你的 Redential 档案中时： ``` npx redential login # device flow, one time npx redential submit # scans again, shows you the bundle, asks before uploading npx redential logout # deletes the locally stored session ``` 偏好持久化安装： ``` npm install -g redential redential scan ``` （`redential` 是 [`@redential/cli`](https://www.npmjs.com/package/@redential/cli)的别名，后者 是官方包 —— 参见[验证包本身](#verifying-the-package-itself)。） 支持的平台：macOS、Linux 和 Windows，运行于 Node.js 20 和 22 上 —— 每个版本都会由 CI 在所有这六个平台上进行验证。 ## `scan` 的外观 在真实的终端中，`scan` 会打印出简短、易读的摘要 —— 而不是 原始的 JSON。它完全由元数据包中已有的字段组装而成（每个字段的说明请参见 [docs/schema.md](docs/schema.md)，完整布局请参见 [docs/scan.md](docs/scan.md)）：检测到的能力 （结构性发现，例如经过验证的 webhook 处理流程，会优先标出；其他所有内容按类别分组），最常用的语言和类别， 所有权和已签名提交的比例，以及结尾处重申哪些数据会 离开本机、哪些永远不会离开的区块： ``` PRIVATE WORK, LOCALLY DERIVED 1 year · 1,378 authored commits · 78% ownership CAPABILITIES DETECTED Payment webhook flow 4 commits STRUCTURAL · DIRECT Payments Stripe 12 commits TOP LANGUAGES .ts ████████████████████ 62% .sql █████░░░░░░░░░░░░░░░ 14% TOP CATEGORIES Backend ████████████████████ 51% Testing ███████░░░░░░░░░░░░░ 18% Ownership 78% of this repo's commits are yours Signed commits 45% of your commits are cryptographically signed ──────────────────────────────────────────────────────────── Nothing left your machine. Nothing is uploaded unless you run `redential submit` — and only the bounded bundle: aggregates, salted fingerprints, and closed-vocabulary capability slugs. Never code, file names, commit messages, or other contributors. Verify: github.com/Redential/redential-cli ──────────────────────────────────────────────────────────── Inspect the exact payload: redential scan --json More detail (hour/weekday histograms): redential scan --details Add this private work to your public Redential profile: → redential login && redential submit ``` 确切的 JSON 只需一个标志即可获取，绝不隐藏：`redential scan --json`（或者 `redential scan | jq`，或任何通过管道/重定向的 stdout）会打印**仅包含** 字面意义的元数据包，逐字节对应 `submit` 将发送的内容 —— 并且 `credential submit` 在要求你确认上传之前，总是会在每条路径上、不可跳过地立即 向你展示这完全相同的 JSON。上面的摘要只是源自同一个元数据包的 终端专属便利输出，绝不是第二个数据源。 这是 payload 的结构（`redential scan --json`）—— 即在任何上传之前实际 审查的内容： ``` { "schema_version": "1.2.0", "runner": "local", "tool_version": "0.5.0", "created_at": "2026-07-09T14:32:01.000Z", "repo": { "host_type": "github", "age_days": 742, "repo_fingerprint": "a3f9…" }, "identity": { "author_identity_hashes": ["9c1e…"], "other_contributors_count": 3 }, "commits": { "user_total": 1847, "first_at": "2024-06-02T09:14:00Z", "last_at": "2026-07-08T21:05:00Z", "span_days": 767, "hour_histogram": [...], "weekday_histogram": [...] }, "signed": { "count": 831, "ratio": 0.45, "key_types": ["ssh"] }, "languages": [ { "extension": ".ts", "share": 0.62 }, { "extension": ".sql", "share": 0.14 } ], "categories": [ { "name": "backend", "commit_count": 902, "churn_share": 0.51 }, { "name": "testing", "commit_count": 340, "churn_share": 0.18 } ], "detected_skills": [ { "slug": "payments/stripe", "commit_count": 12, "first_seen": "2024-09-01T10:00:00Z", "last_seen": "2025-11-20T18:30:00Z" }, { "slug": "payments/payment-webhook-flow", "commit_count": 4, "first_seen": "2024-09-03T08:00:00Z", "last_seen": "2024-09-03T08:00:00Z", "evidence": "structural", "confidence": "direct" } ], "ownership": { "user_commit_ratio": 0.78 }, "integrity": { "merkle_root": "7be2…", "algorithm": "sha256", "date_forensics": { "author_span_days": 767, "committer_span_days": 763, "mismatch_ratio": 0.06, "committer_burst_ratio": 0.02 } }, "attestation": { "authorized_confirmation": true, "confirmed_at": "2026-07-09T14:32:01.000Z" } } ``` 完整的命令参考：[docs/scan.md](docs/scan.md)。 ## 信任模型 | 永不离开你的本机 | 只有在你运行 `submit` 之后才会传输，且仅限于此 | |---|---| | 源代码、diff、代码片段 | `scan` 使用 `--json` 打印的元数据包（并且 `submit` 在上传前总是会完整显示）—— 逐字节对应 | | 文件和目录名 | 扩展名（`.ts`）和推断出的类别（`backend`） | | 提交信息 | 汇总频率：小时/星期直方图 | | 其他贡献者的姓名或电子邮件 | 其他贡献者的总数 | | 远程 URL | 仅限 host *类型*（`github`、`gitlab` 等），绝不包含 URL | | 任何类型的机密信息 | 无 —— 会对元数据包进行机密扫描，任何匹配项都会阻止输出 | | — | 你的私有标签：由*你*亲自输入的自由文本（绝不从你的代码中派生），会随包一同发送 —— 但绝不会在包内部 —— 并且在你确认上传前会展示，此项为必填，仅对所有者可见（[docs/private-label.md](docs/private-label.md)） | 左侧的每一行都由一个[可执行测试](test/privacy/)提供支持，详见 [docs/privacy-tests.md](docs/privacy-tests.md) —— 不仅仅是 策略声明。`scan` 本身不会发起任何网络调用；`login` 和 `submit` 是 仅有的两个会接触网络的命令，而且 `submit` 没有你的明确确认绝对不会上传任何内容。完整原理说明： [docs/principles.md](docs/principles.md)。 ### 验证包本身 每个版本都是在带有 tag 的 commit 上通过 GitHub Actions 发布的，并附带 npm 来源证明（`npm publish --provenance`）—— 绝不会从任何人的笔记本电脑上发布。 验证任何已安装的版本都是基于此确切源代码构建的： ``` npm audit signatures ``` 完整的发布流程以及来源证明实际证明了什么，请参见 [docs/releasing.md](docs/releasing.md)。 ## 常见问题 ### 别人怎么知道我确实做过这些工作？ CLI 并不声称自己知道 —— 这正是分级系统存在的全部意义。一个已认证的元数据包意味着：*此机器的 git 历史显示了此活动，并由该身份认领。* 部分锚点支持该声明 （你的提交电子邮件会与已验证的账户电子邮件进行比对， 已签名的提交在没有你的密钥的情况下无法事后伪造，并且你的 活动频率会在服务端进行一致性检查）—— 但这些都不能 证明作者身份，README 也从不假装它能做到。 真正的答案在于之后发生的事情：任何人都可以*声称*拥有某段历史，但在 Redential 上，声明是可以被挑战的 —— 也就是实时答辩，你需要 根据自己元数据包中的数字生成的提问进行回答。真正做过这些工作的人可以凭记忆回答。抄袭别人历史的人 则什么也记不住。如果你不可能完成这些工作，你就无法为其辩护 —— 而未经辩护的声明将明显停留在最弱的层级上，并被如实标记。 ### 我能不能只导入一堆库来虚增我的技能列表？ 不行 —— 仅仅一个简单的 import 很少能标记为一项技能。大多数签名需要 一个独特的、明确的 import 指示符（不是在不同生态系统间通用的包名），或者需要来自你自己 diffs 的实际 API 调用形式（是 `stripe.checkout`，而不仅仅是 `import Stripe`）。具体的检测规则和其背后的原则，请参见 [docs/signatures.md](docs/signatures.md)。但更诚实的回答远不止于检测 准确性：这个 CLI 只会生成 **Attested**（已认证）层级 —— 这是 Redential 上最弱的层级，明确标记为未经验证的元数据。虚增你的 技能列表只会让你在最弱的层级上获得一个稍微长一点的列表；对于需要实际代码或答辩环节的 Proven 或 Verified 层级，它起不到任何作用。在一个已经被标记为“打个折扣看待”的层级上，通过操纵元数据来让自己显得令人印象深刻，这算不上什么诱人的奖品。 ### 我能不能把别人的 git 历史重放到一个新仓库中并声明为自己的？ 你可以在一个新仓库中伪造提交时间戳 —— 这正是为什么 本地数据被明确指定为*最弱*层级，而不是最强层级的原因。重放的历史仍然必须经受住几个部分锚点的考验：签名提交（GPG/SSH 签名在没有密钥的情况下无法事后伪造）、行为指纹（将小时/星期频率作为软一致性检查，与你已验证的公开活动进行比较）、重写取证信号（`integrity.date_forensics` —— git 的作者日期很容易伪造，但一个在短时间内重放多年伪造历史的脚本，也会使得每个提交的 *committer*（提交者）日期都集中在同一次操作中；这是一种服务端的启发式信号，而不是本地的判定 —— 参见 [docs/schema.md](docs/schema.md#date_forensics-measurement-contract)），而且 —— 最重要的是 —— 元数据包永远只能获得 **Attested**，即仅限元数据。在此之上的任何层级都需要通过符合 NDA 要求的答辩：在一个短暂的录音环节中， 根据你自己的元数据包实时生成问题并由你进行回答。伪造 git 历史成本很低；但在实时问答中为捏造的经验辩护，成本却不低。这个差距才是真正的安全边界，而不是检测启发式算法。 ### 到底什么内容会离开我的机器？ 元数据包 —— 也就是 `redential scan --json` 打印出来的、并且 `submit` 在要求你确认之前总是会完整显示的 JSON，逐字节对应，之后不会有任何添加或丰富。这不是你需要凭信念接受的承诺： [`test/privacy/submit-guardrail.test.ts`](test/privacy/submit-guardrail.test.ts) 断言 `submit` 通过 HTTP 发送的字面字符串 `===`（完全等于）你确认前它打印的字符串，而不是解析对象后的重新序列化结果。每个字段都记录在 [docs/schema.md](docs/schema.md) 中，并且 schema 本身 （`schema/bundle.v1.json`）在所有地方都设置了 `additionalProperties: false` —— 未列出的字段会使元数据包因构造原因而失效，而不仅仅是由于约定。 ### 为什么我应该信任一个 CLI 来处理我雇主的代码？ 因为它永远不会以任何离开你笔记本电脑的形式接触你雇主的代码。它是仅限本地的（`scan` 在结构上就是无网络的，而不仅仅是默认无网络），在 Apache-2.0 协议下完全开源，因此你可以在运行前阅读每一行代码，并且它的隐私声明是你可以自己运行的 [可执行测试](test/privacy/)（`npm test`），而不是 一纸空文。没有遥测，没有分析，没有后台 进程 —— 这个 CLI 有史以来仅有的两次网络调用就是 `login` 设备流和 `submit` 上传，两者都需要你的明确操作。 并且每个发布的版本都带有一个你可以验证的 Sigstore 签名来源 证明（`npm audit signatures`），证明它是基于这个确切的代码库构建的，而不是来自某个人的笔记本电脑。 ### “Attested”实际上证明了什么？ 老实说，它本身证明不了太多 —— 这是设计使然，并非 疏忽。“Attested”意味着：这个人的本地 git 历史显示了这种 活动模式，属于自我报告且可证伪的，带有部分锚点 （已签名的提交、行为指纹、服务端一致性检查），但没有对底层代码进行独立验证。它永远不会被标记或与 Proven 或 Verified 混淆，后两者需要连接可读的仓库（通过 GitHub App）或进行实时答辩。把 Attested 看作是“值得追问一句”，而不是 “已验证” —— 这个 CLI 的整个设计就是为了保持这种区别的 诚实，而不是让元数据包借用它尚未赢得的信誉。完整的推理过程请参见 [docs/principles.md](docs/principles.md)（原则 6， “对信任保持诚实”）。 ### 这仅仅是你们 SaaS 的引流工具吗？ 诚实的回答是：CLI 是 [Redential](https://redential.com) 的开源捕获层，而 Redential 是一款商业产品。 这两个事实都没有隐藏 —— 你现在正在阅读它们。 使它成为一个工具而不是引流渠道的原因是：`scan` 完全可以独立使用，非常有用。不需要账户，不需要登录，不需要网络 —— 它可以分析你的 仓库，并在本地向你展示它发现的所有内容，永久免费。只有当你认为结果值得发布时，平台才会介入，并且在你看到确切的 payload 并确认提示之前，不会上传任何内容。没有残缺模式，没有“解锁完整结果” —— 本地分析就是完整的分析。 商业模式是凭证平台。CLI 的职责是足够值得信赖，让你愿意考虑使用它 —— 这就是为什么这个 README 中的每项隐私声明都对应一个可执行的测试，而不是一句承诺。 ## 文档 - [docs/principles.md](docs/principles.md) —— 六项不可妥协的规则 - [docs/privacy-tests.md](docs/privacy-tests.md) —— 哪个测试证明了哪条规则 - [docs/scan.md](docs/scan.md) —— 完整的 `scan` 命令参考 - [docs/login-submit.md](docs/login-submit.md) —— `login`、`submit`、`logout` - [docs/private-label.md](docs/private-label.md) —— 必填的私有标签：它是什么，为什么它在元数据包之外传输 - [docs/schema.md](docs/schema.md) —— 解释元数据包的每个字段 - [docs/signatures.md](docs/signatures.md) —— 技能检测的工作原理 - [docs/releasing.md](docs/releasing.md) —— 版本是如何构建和验证的 如果你正在扫描的仓库是你自己并且是可连接的，那么 `scan` 并不是 更好的工具 —— [GitHub App](https://redential.com) 会读取实际的代码，并比本地元数据更强大的层级。

标签：Git, MITM代理, SOC Prime, 代码分析, 凭证管理, 开发工具, 文档结构分析, 暗色界面, 简历与职场, 网络安全研究, 自动化攻击