## 提案
### 破冰
将 "Mod 区管理规定与细则"中"原创Mod发布"中的第二项规定
`不得对游戏本体（非配置文件数据）进行修改`
更改为：
`不得在用户不知情或未经用户允许的情况下，对游戏本体（非配置文件数据）进行修改`
### 规范
在当下，CoreMod以及包含CoreMod的模组应当与完全转换模组同样被视为一种独立的类别，并使用特定于此的标准、规范以及合规性要求。
具体标准、规范有待商讨
## 理由
### Context
在Mikohime Java升级套件开创性地将`侵入式修改`这一概念正式引入Starsector Modding社区后，越来越多的modder意识到自己可以类似的方式做到更多的东西。
~~（至于以前为什么没有你别问，抱怨的全被踩头了）~~
`侵入式修改`技术使得我们能够轻易做到原版游戏所不能够做到的事情，并且在当下已经有了许多使用这一技术的模组：
FastRander 通过滥用类路径机制与桥接方法修改原版类
PatchLib 通过使用自附加Agent动态转换原版类
MixinLib & PEI 通过使用PreMain Agent转换原版类
而这无不说明`侵入式修改`技术正在进入更多modder的视野中
并且，是的，我们总有一天是会需要它的。
但现在有一个小小的问题
### 不可能三角
> 无文件修改、持久化、正确的早期入口点
目前我们已知的所有`侵入式修改`技术都不可能在不修改游戏文件的同时持久化并能够获取正确的（足够早的）初始化时机。
他们不可兼得。
或许有些观众并不清楚这是一种什么样的情况，就是说，如果我解决了这个不可能三角，我基本上可以直接写一份CVE报告。
持久化的最佳方法是修改启动文件，但那样不合规（并且其他的思路比这个更加的不合规）。
无文件修改要求在原版模组框架内启动，这导致无法获取正确的入口点。
无文件修改且正确的入口点？这个是滚木，根本不可能做到。
所以是的，我们没招了。
### 一个足够合理的例子
作为国内黑魔法潮流的响应者，MixinLib采取了一种处在规则边缘的安装方式——
模组Jar同时作为Agent Jar存在，在目录中附带安装脚本的同时明确指引用户正确安装。
MixinLib（自动地、不受用户意志干涉地）修改了游戏本体的文件吗？并没有。
MixinLib修改了游戏吗？从结果上看，是的。
那谁修改了文件？用户。
用户将在这一过程中逐渐理解自己这么做的风险，而模组也能够完美的运转，双赢。
### 风险
我们清楚的知道，每一条规定都不是无来由的，每一条规定背后必然存在一些我们所不知晓的事情。
显然，禁止对游戏修改这一规定暗示着潜在的恶意行为者群体，但我们有必要意识到一件事——
恶意行为者并不会因为规定存在而停止行动，但有合规意愿的开发者会因此受限。
另外目前已经有无数种方法绕过游戏的原生限制，并且A圣脑子抽了没禁止Runtime.Exec。
~~（所以在这种情况下我并不认为安全性是什么有足够说服力的东西，en那边有人上传用户数据好几个月才被人发现，我已经打算不指望什么了。）~~
我们本质上只是希望能够在一个更宽松的技术指标下编写`侵入式修改`模组(CoreMod)，并在一个更加明确且更具指导性的标准下发布它。
## END
在最后的最后，感谢您阅读本人的提案，这份提案可能不完整且充满漏洞，但这正是正式讨论这一问题的绝佳时机，在此本人欢迎各位对此进行讨论、反驳与补充。
| 
发表于 
