计划的插件侧装更改(正在寻求用户的反馈)

最近的 Streamlink 8.4.0 版本修复了 HLS/DASH 中的本地文件读取问题,我希望解决一些长期存在的有关插件侧装的安全问题。因此,我写下这篇文章,希望在做出任何决定之前收集用户的反馈。是的,我完全意识到这可能有点过度。# 理由插件侧装允许在不直接修改 Streamlink 的 Python 分发(即 streamlink Python 包)的情况下,对插件系统进行简单的扩展。Streamlink 从 Livestreamer(ef86768ac852, 8d2d1fb360ae)继承了插件侧装功能,当它被分支时。当前插件侧装实现的问题在于,Streamlink 会按设计自动执行其侧装路径中的所有 Python 模块,以查找要添加或覆盖的插件。默认情况下,侧装是启用的,除非通过 --no-plugin-sideloading 显式禁用。在用户的主目录中有一个默认侧装路径(取决于操作系统 - 在 Linux 中位于 $XDG_DATA_HOME),但还有一个 --plugin-dir 和已弃用的 --plugin-dirs 选项,允许设置任意路径以从中加载插件。这些选项当然可以在配置文件中设置。在 Streamlink 6.6.0(2024-02-16)中,默认/主流插件实现了懒加载。在这里,我们可以在构建时静态分析插件模块,并解析声明式 URL 匹配器和插件参数数据,然后生成一个 JSON 文件,然后在运行时读取此文件,以查找预先构建的 URL 匹配器数据,并从输入 URL 加载所需的插件模块,同时忽略所有其他插件。这加快了启动时间并减少了整体内存使用。对于第三方插件,这种方法不起作用,因为我们需要在每次启动时都静态分析插件模块,这很慢。它还容易出错,尽管我们的解析器非常宽容,因为我们不知道第三方插件开发者在自己的实现中做了什么。默认/主流插件对声明式数据有严格的规则,因此总是"符合解析器要求"。因此,唯一的选择是在找到输入 URL 的匹配插件时在侧装路径中执行所有 Python 模块。结果是,即使我们在插件侧装路径中的加载模块不是有效的插件时也会引发错误,但我们已经执行了该模块,这可能是危险的,因为它可能包含恶意代码。这创建了一个权限提升向量,其中简单的文件系统写入权限(例如,通过不同的受限服务或同步云文件夹)会自动提升为完全代码执行,一旦用户启动 Streamlink。# 仅执行可信代码解决问题的办法是仅执行可信代码,但这本身也是一个问题。