由于成果已经一步步完善, 我们已经可以看到成功的预兆, 我在此贴更新项目的进展.

好久不见，甚是想念，这里是 Creeper19472 ，除了正事啥都会干的行为艺术家（大嘘）。

首先是几乎所有人应该都忘记了的有关之前提到的某新视觉小说的开发进展——那就是没有进展，至于为什么懂得都懂（划掉）。在过去的一个月中我投入了大部分精力于另外一个项目中，也就是我在此处将要主要介绍的：CFMS (Classified File Management System)，直译为“已分类机密文档管理系统”。（我在这里发这个应该没逝吧）

该项目的断续开发前后约持续了两年的时间，并最终过渡到今年六月初开始重新构建的新的主要版本——内部代号“时间线的文学家”，不要问我为什么取这个名字因为我乐意

该项目的主要目的是为苦力怕团队的内部管理提供一套基本完整的解决方案。为了让并不是那么熟悉信息技术的其他成员使用这套系统，一个相对用户友好的客户端就显得尤为必要——这在之前的两个主要版本中未能得到实现，但如今我们有了另一位相当可靠的开发者来完成它。

特色功能

在我们的当前开发计划中，以下功能将在第一个正式版本发布时即得到支持：

• 文件夹和文件的增删改查（废话）
• 自定义用户组
• 内部清理工作使用的计划任务
• 防范锁定
• 真实文件名混淆

以及我希望在这里着重介绍的一些特色功能：

1. 定时授权与自定义的访问规则。事实上，目前的开发版本已经支持对用户授予指定时长的权限和用户组——我们在设计时借鉴了许多 MediaWiki 的架构设计，例如一个权限并不被独立定义而存在：它在被“引用”时便成为一个可感的实体，在失去“引用”后便自动地不再存在。我们做到的一点是，通过编写 json 格式的自定义规则来允许拥有指定权限或用户组的用户访问特定的文件——而这还可以被加以诸如“与”和“或”的门电路逻辑。为了弥补自定义规则不能限制有效期限的不足，我们也设置了“附加访问”的记录项——它可使指定的用户和用户组实现对文件的直接访问。
2. 审计日志。尽管该功能仍在计划阶段，但我们已确认它将至少支持即将提到的这些功能，即记录用户执行操作的时间和结果，以及一些对追踪有用的信息。
3. 策略（没有“组”）。我们设计了一些控制服务端行为和预防滥用的内部策略，希望它们能够在维护系统稳定性上起到作用。

我们取消了原有的分级式权限设计（这种设计通过一个整数来标识用户的权限大小），转而通过用户组的方式进行替代——这可能有助于使得权限的分配更加灵活多变。

缺陷

很遗憾，虽然作为一个保密系统的首要任务是确保安全性，但我们的工作计划决定了开发过程中功能实现优先于安全实现，也就是说在相当长的一段时间内它可能并不那么安全——至少在公网环境下仍存在致命的隐患。

在加密传输上，我们仍在采用RSA+AES的原型机式组合——使用4096位的非对称式密钥，但在可见的未来中这将很可能很快不再安全。另外，我们并未实现一套合适的密钥交换与身份验证机制，即容易遭到中间人攻击——在这方面，X25519密钥交换算法可能更为合适。

此外，仍有许多功能等待重构，效率优化工作仍待进行——在采用基于FTP的“一任务一文件”的设计的情况下，文件传输对于文件夹上传并不那么友好——特别是在结构复杂而文件数庞大的情况下。另外，为了确保目录隔离，在执行传输时还将复制原文件到临时目录——当单文件达到可怖的数GB式，这显得尤为愚蠢。尽管我们正使用创建硬连接的方式减少复制行为产生的IO开销，但它提高了运行CFMS的门槛——创建硬连接的权限通常仅由系统管理员所持有。

数据库注入同样是一个令人头疼的问题。我们选择了从零开始构建操作数据库的行为，这相较于经过了无数检验的已有框架而言将是先天性的缺陷。我们希望收到对此类漏洞的反馈。

参与

尽管CFMS目前仍在以较高的频率进行更新，但前后端都仅由一人进行开发仍会造成较大的压力。欢迎所有人为CFMS的功能和技术细节提出建议，我们也准备了一份面向开发者的服务端文档：此处。它不很完善，但我们同样缺少时间来完善它。

如果您有对现有问题或功能的 Workaround 和 Solution, 欢迎提交可供改进系统结构的 Pull Request 至我们的仓库。我们将尽快查看新的 Issue 和 PR ，期待着有着更多人共同参与开发。

服务端项目地址：点此。

客户端项目地址：点此。

唯一一个问题在于
如果开发安卓移植的话，势必会让mod文件内包含原版文件
这是个问题
我的做法是删除校验代码，做到加不加原版文件都可以直接运行我的mod（当然这是建立在我对原版文件大幅度删改后的结果）