【免费下载链接】rune
the development environment for pros
Rune 是一款面向专业开发者的开源 IDE，它的最大卖点之一是安全：所有 Rune 实例组成一个端到端加密的私有对等网络，任何扩展都必须通过"进程隔离 + 加密通道 + 权限声明 + 签名信任"这 4 道防线才能触碰你的代码。本文带你逐层看懂这套安全设计。
为什么开源 IDE 需要认真的安全设计 🛡️
现代 IDE 越来越像一个操作系统：里面跑着语言服务器、第三方扩展、AI Agent，它们都能读文件、执行命令。这意味着两个经典风险：
- 传输风险：你的多台机器之间同步代码、终端会话时，数据会不会被截获？
- 代码风险：一个来路不明的扩展能否偷偷读取你的源码、窃取你的凭证？
Rune 的应对思路可以概括为一句话：网络层用端到端加密，本地层用最小权限。
防线一：端到端加密的私有设备网络
Rune 内置了一张私有、加密的"设备网"：你运行过 Rune 的每一台机器都可以加入同一个网络，任意两台机器之间可以直接打开对方的工作区，命令只有一行：
workspaceopen rune://<machine>/path/to/project关键设计点：
- 无需 SSH 服务、无需端口转发、无需公网地址。机器之间通过协调服务器互相发现，并自行打穿 NAT，在咖啡馆里就能连回家里的开发机。
- 加密网络基于 headscale 构建，只有你账号下的机器才有资格接入，其他设备永远无法混入。
- 免费账号支持 2 台机器，付费计划不限量；
network status、network peers等命令让你随时掌握网络状态。
官方文档中对这一层的完整说明见 learn/network.md。
防线二：扩展即独立进程，走加密本地通道 🔐
Rune 把扩展（Extension）当作不受信任的外部程序：
- 扩展是独立可执行进程，Rune 以子进程方式拉起，扩展崩溃不会拖垮编辑器；
- 每个工作区独享一套扩展进程，两个工作区之间不共享任何扩展状态；
- 扩展与宿主之间只有一条本机私有的通信通道，不暴露到网络上，机器上的其他程序也无法加入。
这条通道并不是"裸管道"。从测试代码和 xsandbox 工具的描述可以看到，通道与真实环境完全一致：自签名 TLS 证书 + 每次 RPC 级别的 token 认证。Rune 启动某个扩展时，才把连接凭证交给"那一个进程、那一个工作区"，凭证出了这个作用域就失效——不是 Rune 拉起的进程，连不进来。
传输与认证细节实现在 internal/extension/ 与 internal/extension/extensionv2/options.go，开发者甚至可以用 cmd/xsandbox/ 在无 IDE 环境下对 SDK 实现做协议一致性测试和基准测试。
防线三：权限模型——声明制 + 用户审批 🧑⚖️
拿到加密通道只是"进门"，扩展要真正动手还得过权限关。Rune 采用两层授权：
1. 声明制（Authorization）：扩展必须在启动时声明自己需要的能力（编辑器、文件系统、命令执行、语言服务器、存储……）。调用任何未声明的能力会被直接拒绝，没有灰色地带。
2. 用户审批（Approval）：对于已声明的敏感能力，你才是最终把关人。扩展第一次伸手时，Rune 会弹出提示，给你四个选项：
| 选项 | 含义 |
|---|---|
| Allow once | 仅本次会话放行 |
| Allow always | 记住决定，不再询问 |
| Deny once | 本次拒绝 |
| Deny always | 永久拒绝 |
命令执行类权限看得更严：Rune 不仅问"你能否执行命令"，还能根据实际要执行的命令内容逐次询问。
所有已记住的审批决定都可以随时审查和撤销，在控制台执行：
authorizer list # 查看所有已持久化的权限决定 authorizer revoke <permission> # 撤销某项授权，下次会重新询问审批逻辑核心在 internal/ide/grantor.go 与 internal/ide/ideauthorizer/ 目录；[internal/extension/grantor.go](https://link.gitcode.com/i/4357b7357f6c2443aabe472afb0504cd)定义了 Grantor 接口，即"允许或拒绝扩展访问资源"这一动作本身。
防线四：签名包与验证发布者（Verified Publishers）✅
再严的审批流程，也挡不住"你点了 Always"之后的风险。Rune 的答案是软件签名信任链：
- 官方安装的包都是签名分发的，Rune 内置信任密钥环（trust keyring），并在启动时从 API 刷新；
- 通过 pkgtrust 模块，Rune 能判断某个扩展入口是否来自经验证的发布者签名的包，未签名的扩展会被标记为"无法证明身份"；
- 验证发布者可以配置为跳过权限弹窗（默认开启），而未验证的扩展永远会先弹窗：
authorizer: auto_authorize_verified: true # 验证发布者免审批（默认 true） auto_authorize_commands: true # 命令执行免审批（仅限验证发布者）换句话说：签名 = 信任的快速通道；没有签名 = 每一次都要过你这一关。完整信任模型说明见 develop/extensions.md。
加分项：AI Agent 也在沙箱里 🤖
Rune Agent（内置 AI 编程代理，源码见 cmd/rune-agent/）执行模型驱动的工具调用（改文件、跑 shell 命令）时，同样受用户配置的权限模式约束，默认会先询问再执行。
值得注意的是，SECURITY.md 明确把"沙箱或权限绕过"——例如通过 prompt 注入升级权限、工具调用逃逸出沙箱——列为在范围内的安全漏洞，并承诺协调披露（90 天窗口）。安全团队还预留了专用邮箱 security@unstable.build 接收漏洞报告。
想深入源码？从这里开始
| 模块 | 说明 |
|---|---|
| internal/extension/ | 扩展宿主：权限资源、Grantor 接口 |
| internal/ide/ideauthorizer/ | gRPC 中间件层的认证与鉴权 |
| internal/ide/idepkg/pkgtrust/ | 签名包信任密钥环与验证逻辑 |
| cmd/xsandbox/ | 扩展协议沙箱测试工具（TLS + token 认证全流程） |
| auth/ | OAuth2 令牌源、密钥与角色定义 |
| SECURITY.md | 安全政策与漏洞报告渠道 |
总结
Rune 的 4 道防线层层递进，构成一条完整的安全链：
- 网络层：端到端加密的 headscale 私有网络，设备间直达；
- 进程层：扩展即独立进程，本机加密通道 + 逐 RPC token 认证；
- 权限层：能力声明制 + 用户四选项审批，可随时
authorizer revoke收回； - 信任层：签名包与验证发布者，未签名者永远过不了人工审批。
对普通用户而言，你几乎不需要配置任何东西——防线默认就是开着的；而对安全敏感的重度用户，authorizer命令和签名信任模型给了你随时收紧缰绳的手段。
【免费下载链接】rune
the development environment for pros
相关推荐
ClawGUI安全设计解析：执行沙箱、网络限制与工具权限如何构建防线
ClawGUI安全设计解析：执行沙箱、网络限制与工具权限如何构建防线 ClawGUI 是一个一站式构建、评估与部署 GUI Agent 的开源框架，覆盖在线强化
WebVM安全加固：沙箱隔离与权限控制
WebVM安全加固：沙箱隔离与权限控制 引言：浏览器虚拟化的安全挑战 在传统Web应用中，JavaScript运行在严格沙箱环境中，无法直接执行原生代码或访问系
虚拟化WebAssembly前端PortBender重定向模式实战：SMB中继攻击的完整解决方案
PortBender重定向模式实战：SMB中继攻击的完整解决方案 PortBender是一款功能强大的TCP端口重定向工具，专为红队操作员设计，能够将目标TCP
网络安全
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
