fifth-domain/gls/GLS-0230-TCS-SOURCE-SECURITY-PROTOCOL-SYSTEM.hdlp

384 lines
12 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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