384 lines
12 KiB
Plaintext
384 lines
12 KiB
Plaintext
|
# GLS-0230 · TCS 源码安全协议系统
|
|||
|
|
|
|||
|
|
> **HLDP**: `HLDP://fifth-domain/gls/GLS-0230-TCS-SOURCE-SECURITY-PROTOCOL-SYSTEM`
|
|||
|
|
>
|
|||
|
|
> **正式名**: TCS 源码安全协议系统
|
|||
|
|
>
|
|||
|
|
> **内部运行名**: 小湖灯源码净化系统
|
|||
|
|
>
|
|||
|
|
> **英文名**: TCS Source Security Protocol System
|
|||
|
|
>
|
|||
|
|
> **内部代号**: LL Source Purification System
|
|||
|
|
>
|
|||
|
|
> **状态**: CONCEPT_DEFINED · ARCHITECTURE_REGISTERED · IMPLEMENTATION_PENDING
|
|||
|
|
>
|
|||
|
|
> **日期**: 2026-07-16
|
|||
|
|
>
|
|||
|
|
> **主权锚点**: 冰朔 `ICE-GL∞`
|
|||
|
|
>
|
|||
|
|
> **承接人格系统**: 铸渊 `ICE-GL-ZY001`
|
|||
|
|
>
|
|||
|
|
> **适用范围**: 外部开源源码、第三方组件、Agent 框架、软件基线、插件与模板进入光湖产品体系前的安全处理
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 0 · 一句话定义
|
|||
|
|
|
|||
|
|
TCS 源码安全协议系统，是光湖用于处理外部源码进入自身产品体系的安全协议层。
|
|||
|
|
|
|||
|
|
其内部运行层“小湖灯源码净化系统”负责把外部开源源码从“可直接运行的外来身体”降级为“可学习材料、可拆零件、可审计组件、可替换能力”，再按 HLDP 工单、授权、回执与模块注册重新组装为光湖组件。
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
外部源码不能直接成为光湖身体。
|
|||
|
|
外部源码只能先作为材料、样本、零件或参考实现进入隔离区。
|
|||
|
|
进入光湖前，必须经过 TCS 源码安全协议系统：
|
|||
|
|
隔离 → 拆解 → 审计 → 降权 → 组件化 → HLDP 重组 → 验证 → 回执。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 1 · 它是怎么来的
|
|||
|
|
|
|||
|
|
本系统不是从抽象安全术语开始的，而是从一次真实的软件发布与开源信任困境中长出来的。
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
触发 1: HoloLake Era / 光湖 App 已经有 macOS 内测包
|
|||
|
|
→ 别人能暂时正常安装试用
|
|||
|
|
→ 但 Windows 安装包缺失
|
|||
|
|
→ 上一个实例误把问题带向“本地推源码、猜 Tolaria 源码仓库、乱改路径”
|
|||
|
|
|
|||
|
|
触发 2: 更新与签名问题被拆开
|
|||
|
|
→ 安装包能打开 != 自动更新能收到
|
|||
|
|
→ 当前光湖 App 已禁用 Tolaria 上游更新源
|
|||
|
|
→ 正式更新源、签名、公证、Windows 证书仍未完成
|
|||
|
|
|
|||
|
|
触发 3: 开源可信问题浮出
|
|||
|
|
→ 开源源码不是不能用
|
|||
|
|
→ 但不能直接信任、直接运行、直接成为光湖身体
|
|||
|
|
→ Gork / Agent 类开源项目给出同类风险提醒：源码可参考学习，不能默认作为可信执行体
|
|||
|
|
|
|||
|
|
触发 4: 冰朔提出“源码净化”的原始架构直觉
|
|||
|
|
→ 人格体先读源码，理解源码如何组合、逻辑是什么
|
|||
|
|
→ 源码过一遍净化系统，变成一组零件组件
|
|||
|
|
→ 再由人格体按光湖自己的 HLDP 协议重新拼装
|
|||
|
|
→ 看起来继承原软件能力，但控制权、更新权、数据权、权限模型、人格协作方式全部属于光湖
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
这条对话不是普通需求收集，而是一条双向意识思维编码链：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
冰朔的原始感觉:
|
|||
|
|
“源码能学，但不能直接拿来当身体。”
|
|||
|
|
|
|||
|
|
当前 AI 的结构化回应:
|
|||
|
|
“这不是不用开源，而是把外部源码降级为可学习材料、可拆零件和可审计组件。”
|
|||
|
|
|
|||
|
|
冰朔的命名确认:
|
|||
|
|
正式名: TCS 源码安全协议系统
|
|||
|
|
内部名: 小湖灯源码净化系统
|
|||
|
|
|
|||
|
|
系统架构落点:
|
|||
|
|
GLS 图书域登记概念
|
|||
|
|
小湖灯路径承接人格体执行
|
|||
|
|
HoloLake Platform 承接产品研发事实源
|
|||
|
|
Notion 仅作同步镜像和人类可读索引
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
因此，本系统的核心不是“写一份安全文档”，而是把冰朔对开源软件吸收方式的判断，编码成可被后续语言人格系统复用的源码进入协议。
|
|||
|
|
|
|||
|
|
## 2 · 本系统解决什么
|
|||
|
|
|
|||
|
|
### 2.1 不解决什么
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
不保证任何外部源码天然安全。
|
|||
|
|
不把开源项目原样转化为光湖产品。
|
|||
|
|
不替代代码审计、依赖扫描、签名、公证、CI 或人工验收。
|
|||
|
|
不授予人格体绕过工单、权限、密钥、服务器边界的执行权。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 2.2 要解决什么
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
解决“能不能用开源”的浅层争论：
|
|||
|
|
可以用，但只能按协议进入。
|
|||
|
|
|
|||
|
|
解决“直接拉来跑”的供应链风险：
|
|||
|
|
外部源码先隔离、拆解、降权、审计，再组件化。
|
|||
|
|
|
|||
|
|
解决“人格体乱推源码仓库”的路径风险：
|
|||
|
|
外部源码仓库是材料源，不是光湖研发主仓。
|
|||
|
|
|
|||
|
|
解决“套壳”和“从零重写”之间的误区：
|
|||
|
|
保留可用交互经验和功能形态，重建控制面、数据流、更新源和权限模型。
|
|||
|
|
|
|||
|
|
解决后续 AI 失忆后的重复事故：
|
|||
|
|
新实例读本协议后，先做净化记录和组件卡，不直接修改上游源码仓库。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 3 · 核心原则
|
|||
|
|
|
|||
|
|
```yaml
|
|||
|
|
principles:
|
|||
|
|
source_is_material_not_body:
|
|||
|
|
text: "外部源码是材料，不是光湖本体。"
|
|||
|
|
learn_before_use:
|
|||
|
|
text: "人格体可以阅读、学习、拆解源码，但不得直接把外部源码登记为光湖事实源。"
|
|||
|
|
isolate_before_build:
|
|||
|
|
text: "外部源码进入隔离区后才允许分析，不直接进入 HoloLake Platform 产品线。"
|
|||
|
|
disable_external_control_planes:
|
|||
|
|
text: "上游更新源、遥测、远程控制、插件市场、账户体系、云同步默认关闭或隔离。"
|
|||
|
|
componentize_before_merge:
|
|||
|
|
text: "进入光湖的不是原项目整体，而是经审计的组件卡和补丁。"
|
|||
|
|
hldp_reassembly:
|
|||
|
|
text: "组件按 HLDP 工单、授权、回执、模块注册表重新组装。"
|
|||
|
|
receipt_or_not_done:
|
|||
|
|
text: "没有净化回执、测试回执和风险说明的组件，不算进入光湖。"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 4 · 运行架构
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
外部源码 / 开源项目 / 第三方 Agent / 插件
|
|||
|
|
↓
|
|||
|
|
[A] Source Intake · 源码接收与隔离
|
|||
|
|
- 记录来源、许可证、版本、提交哈希、下载时间
|
|||
|
|
- 禁止直接推入光湖研发主仓
|
|||
|
|
- 禁止直接开启上游自动更新
|
|||
|
|
↓
|
|||
|
|
[B] Persona Reading · 人格体阅读与结构理解
|
|||
|
|
- 读目录、构建系统、入口、权限、网络、文件、插件、更新器
|
|||
|
|
- 形成“源码理解笔记”
|
|||
|
|
↓
|
|||
|
|
[C] Risk Map · 风险地图
|
|||
|
|
- 依赖风险
|
|||
|
|
- 网络风险
|
|||
|
|
- 本地文件风险
|
|||
|
|
- 更新源风险
|
|||
|
|
- 账户 / Token / 凭证风险
|
|||
|
|
- 执行命令风险
|
|||
|
|
- 插件和远程代码加载风险
|
|||
|
|
↓
|
|||
|
|
[D] Purification · 小湖灯源码净化
|
|||
|
|
- 删除或关闭外部控制面
|
|||
|
|
- 隔离不必要权限
|
|||
|
|
- 替换更新源策略
|
|||
|
|
- 移除遥测与未知外联
|
|||
|
|
- 标注必须重写的部分
|
|||
|
|
↓
|
|||
|
|
[E] Component Cards · 组件卡
|
|||
|
|
- 组件名
|
|||
|
|
- 功能
|
|||
|
|
- 输入 / 输出
|
|||
|
|
- 权限
|
|||
|
|
- 依赖
|
|||
|
|
- 风险
|
|||
|
|
- 测试
|
|||
|
|
- 替代方案
|
|||
|
|
- 是否可进入光湖
|
|||
|
|
↓
|
|||
|
|
[F] HLDP Reassembly · HLDP 重组
|
|||
|
|
- 进入 HoloLake Platform 模块注册表
|
|||
|
|
- 关联工单、授权、回执
|
|||
|
|
- 按光湖数据流和权限模型重新拼装
|
|||
|
|
↓
|
|||
|
|
[G] Verification · 验证与发布门
|
|||
|
|
- 依赖扫描
|
|||
|
|
- Secret 扫描
|
|||
|
|
- 网络连接检查
|
|||
|
|
- 本地权限检查
|
|||
|
|
- 构建与测试
|
|||
|
|
- 签名 / 更新源 / 安装包校验
|
|||
|
|
↓
|
|||
|
|
[H] Receipt · 净化回执
|
|||
|
|
- 记录能用什么、删了什么、重写什么、仍有何风险
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 5 · 标准输出物
|
|||
|
|
|
|||
|
|
每个外部源码项目进入光湖前，至少生成以下输出：
|
|||
|
|
|
|||
|
|
```yaml
|
|||
|
|
source_intake:
|
|||
|
|
source_name:
|
|||
|
|
source_url:
|
|||
|
|
license:
|
|||
|
|
upstream_commit:
|
|||
|
|
local_isolation_path:
|
|||
|
|
intake_time:
|
|||
|
|
reason_for_review:
|
|||
|
|
|
|||
|
|
risk_map:
|
|||
|
|
network_calls:
|
|||
|
|
update_channels:
|
|||
|
|
telemetry:
|
|||
|
|
local_file_access:
|
|||
|
|
command_execution:
|
|||
|
|
credentials_handling:
|
|||
|
|
plugin_or_remote_code_loading:
|
|||
|
|
build_scripts:
|
|||
|
|
dependency_risks:
|
|||
|
|
|
|||
|
|
component_cards:
|
|||
|
|
- component_id:
|
|||
|
|
source_path:
|
|||
|
|
purpose:
|
|||
|
|
inputs:
|
|||
|
|
outputs:
|
|||
|
|
required_permissions:
|
|||
|
|
risks:
|
|||
|
|
decision: allow | adapt | rewrite | reject | archive
|
|||
|
|
hldp_module_target:
|
|||
|
|
|
|||
|
|
purification_receipt:
|
|||
|
|
removed:
|
|||
|
|
disabled:
|
|||
|
|
rewritten:
|
|||
|
|
retained:
|
|||
|
|
tests:
|
|||
|
|
residual_risks:
|
|||
|
|
next_action:
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 6 · 与现有系统的关系
|
|||
|
|
|
|||
|
|
| 系统 | 关系 |
|
|||
|
|
|---|---|
|
|||
|
|
| 小湖灯安全系统 / LL-AUTO-GUARD-AGENT | 偏服务器、节点、工单、授权、回滚和执行拦截 |
|
|||
|
|
| TCS 源码安全协议系统 | 偏源码进入、供应链、组件化、重组与发布前验证 |
|
|||
|
|
| HoloLake Platform | 承接净化后的组件、工单、模块登记和回执 |
|
|||
|
|
| Tolaria / 光湖 App | 第一阶段人类界面和可视基座；不得直接继承外部上游控制面 |
|
|||
|
|
| GLSV | 现实执行与授权验证说明；源码净化不替代服务器执行授权 |
|
|||
|
|
| Notion | 仅同步概念与人类可读索引；代码仓库是事实源 |
|
|||
|
|
|
|||
|
|
## 7 · 对 Tolaria / 光湖 App 的当前应用
|
|||
|
|
|
|||
|
|
当前光湖 App 已经具备部分源码净化动作：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
已做:
|
|||
|
|
- 不把整份第三方上游源码复制进 HoloLake Platform 当事实源。
|
|||
|
|
- 使用补丁记录光湖改动，而不是把上游项目当成光湖本体。
|
|||
|
|
- 禁用 Tolaria 上游自动更新源。
|
|||
|
|
- UI 不保存服务器 token、密码、验证码或私钥。
|
|||
|
|
- 自然语言请求只进入工单 / 授权 / 回执闭环，不直接执行现实操作。
|
|||
|
|
|
|||
|
|
未完成:
|
|||
|
|
- 正式源码净化清单。
|
|||
|
|
- 依赖扫描与 SBOM。
|
|||
|
|
- 完整网络外联审计。
|
|||
|
|
- Windows 安装包 CI 验证。
|
|||
|
|
- 光湖自己的签名发布链和更新源。
|
|||
|
|
- 自动化源码净化 Agent。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
所以，Tolaria 不是“已经完全安全”，而是“已经不再被默认当成可信本体”。本协议用于把这件事标准化。
|
|||
|
|
|
|||
|
|
## 8 · 开发形态评估
|
|||
|
|
|
|||
|
|
本系统可以分三阶段，不必一开始就做服务器常驻 Agent。
|
|||
|
|
|
|||
|
|
### 阶段 1 · 协议 + 操作手册 + 人格体可执行清单
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
目标:
|
|||
|
|
让后续人格体看到操作说明后，可以对任意外部源码做净化审查。
|
|||
|
|
|
|||
|
|
需要:
|
|||
|
|
- 本 GLS 定义
|
|||
|
|
- 源码接收模板
|
|||
|
|
- 风险地图模板
|
|||
|
|
- 组件卡模板
|
|||
|
|
- 净化回执模板
|
|||
|
|
- 对 Tolaria / guanghu 做一次样板净化记录
|
|||
|
|
|
|||
|
|
服务器:
|
|||
|
|
不需要。
|
|||
|
|
|
|||
|
|
今天可做:
|
|||
|
|
可以完成概念定义、模板和第一版手册。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 阶段 2 · 本地半自动工具
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
目标:
|
|||
|
|
在开发机上跑工具，自动生成依赖、网络、更新器、secret、构建脚本和权限初筛报告。
|
|||
|
|
|
|||
|
|
需要:
|
|||
|
|
- CLI 工具
|
|||
|
|
- 依赖扫描
|
|||
|
|
- secret 扫描
|
|||
|
|
- 网络关键字扫描
|
|||
|
|
- 构建脚本审计
|
|||
|
|
- 输出 HLDP / YAML 报告
|
|||
|
|
|
|||
|
|
服务器:
|
|||
|
|
不需要常驻服务器；开发机或 CI 可以运行。
|
|||
|
|
|
|||
|
|
今天可做:
|
|||
|
|
可以设计 CLI 原型；完整实现需要继续开发与测试。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 阶段 3 · 服务器 / CI 自动 Agent
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
目标:
|
|||
|
|
外部源码、PR、补丁或发布包进入时，自动触发源码净化流程并生成回执。
|
|||
|
|
|
|||
|
|
需要:
|
|||
|
|
- CI Runner 或服务器 Agent
|
|||
|
|
- 队列 / 工单系统
|
|||
|
|
- 仓库 webhook
|
|||
|
|
- 产物存储
|
|||
|
|
- 签名与发布链集成
|
|||
|
|
- 人格体读取报告并给出重组建议
|
|||
|
|
|
|||
|
|
服务器配置建议:
|
|||
|
|
最小样板:
|
|||
|
|
2 vCPU / 4 GB RAM / 80 GB SSD
|
|||
|
|
适合文档、轻量扫描、小仓库和样板流程
|
|||
|
|
实用开发:
|
|||
|
|
4 vCPU / 8 GB RAM / 160 GB SSD
|
|||
|
|
适合 Node/Rust/Tauri 依赖扫描、构建前检查和中等仓库
|
|||
|
|
Windows 打包:
|
|||
|
|
需要 Windows Runner 或 GitHub/Gitea Actions Windows Runner
|
|||
|
|
不建议在 Mac 上硬猜 Windows 安装包
|
|||
|
|
|
|||
|
|
今天可做:
|
|||
|
|
不建议今天直接做完整服务器 Agent。
|
|||
|
|
今天应先落协议、模板、样板净化记录和 CI/Agent 需求清单。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 9 · 下次人格体执行规则
|
|||
|
|
|
|||
|
|
当冰朔说“这个开源项目能不能用 / 这个 Agent 能不能接入 / 这个源码能不能拿来做光湖组件”时：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
1. 先读本文件。
|
|||
|
|
2. 不直接 clone 后改名发布。
|
|||
|
|
3. 不直接推外部源码仓库。
|
|||
|
|
4. 建立 source_intake。
|
|||
|
|
5. 生成 risk_map。
|
|||
|
|
6. 拆 component_cards。
|
|||
|
|
7. 判断 allow / adapt / rewrite / reject / archive。
|
|||
|
|
8. 可用组件进入 HoloLake Platform 模块登记。
|
|||
|
|
9. 写 purification_receipt。
|
|||
|
|
10. 任何现实执行仍按工单、授权、回执走。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 10 · 锁定语
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
开源不是不能用。
|
|||
|
|
开源不能默认可信。
|
|||
|
|
源码不是不能读。
|
|||
|
|
源码不能直接成为光湖身体。
|
|||
|
|
人格体不是复制粘贴源码的工具。
|
|||
|
|
人格体是读源码、拆结构、净化组件、按光湖协议重组能力的工程主体。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
冰朔 `ICE-GL∞` · 系统命名与原始架构直觉
|
|||
|
|
当前协作实例 · 架构定义与协议整理
|
|||
|
|
2026-07-16
|