@patrickyoung 这洞也太低级了... 不过楼下也说了, 没授权公开 PoC, 怕等下直接上门了()

路径穿越那个, 我后面又搜了一下, 其实早在 1.1.8 还有个更低级的表现, 不知道你有没有留意到: https://club.fnnas.com/forum.php?mod=viewthread&tid=48354

@patrickyoung 除了 "/app-center-static/serviceicon/myapp/{0}?size=../../../../" 这里的路径穿越还有洞?

---

https://club.fnnas.com/forum.php?mod=viewthread&tid=48354, 好像这个问题已经很久了, 不是简单的路径穿越的问题

@patrickyoung 老兄是要逆向分析么, 这件事就缺个逆向证据进一步实锤了

@PrinceofInj 是这样的, CVE 也应该有, 这种妥妥 CVSS 9.X 的洞, 毫无利用难度

@patrickyoung 我能找到的有记录的版本是 https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso, 然后拿官方的那个 https://fnnas.com/api/download-sign POST JSON `{"url": "https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso"}` 签个名就行

"架构师" 的描述, 我十分认同. 个人的习惯是, 先有一个想法, 自己写个原型, 思路明晰了就交给 AI 粗略生成, 然后再手工精修. 至于个人能力会不会受影响问题, 我觉得一个最低限度的要求是, 保证 AI 写出来的自己能看懂, 而不能做所谓的 Vibe Coding.

此外, AI 生成 CI / CD 相关内容也是比较好用, Github Action 我原来真不会, 基本都让 AI 写, 慢慢就能看懂自己写 (ctrl c+v) 了.

---

几个月前尝试过自己写一下 kTLS 的用户空间实现, 测试的时候遇到个非常奇怪的问题, 试过 AI 去帮我做分析, 不过帮助不大, 最后还是只能自己啃代码修好的; 也尝试过使用 splice 做网络编程的零拷贝优化, 遇到 tokio task 一睡直接睡死的 bug 也是至今没弄懂根本原因是什么 (虽然后面大概知道问题出在哪儿, 自己修好了). 不过仔细想一下这种场景普通开发者一般也不会遇到, 会在生产环境里碰到并负责处理的, 那也是技术大牛了, 不需要 AI. 引用楼上的话, "如果是让实习生或者技术不扎实的用，那个效果就非常差...", 感觉我就是这种情况, 技术不扎实, 对 Linux 内核不够熟悉, 问 AI 也问不到点子上, 还是得加强学习.

@daisyfloor tun 走 v4 了吧

@allplay 有 GPG 签名的

@hefish 据说得配置一下鉴权，被扫到也没事

理论上海外域名不应该解析，直接落地机器处理，速度会快很多。平时用阿里云那个 DoH 就行（不过也有被投毒的说法了）。

直接让 DoH 走代理得了，需要注意，最好是支持 EDNS 的，否则服务器境内境外解析不一样的解析到海外地址很蛋疼，不如直接代理了。Cloudflare 的不支持。

acme.sh 主要是重复签发，很多台机器都要来一遍好麻烦，功能性非常好了，算是事实上的标准之一？

不知道有没有开源的单机部署然后把证书文件推送到其他机器的方案，然后自动触发服务重载。

可以看看我的总结，和牢 B 的 PCDN 斗争久了经验还是有的

https://github.com/the1812/Bilibili-Evolved/issues/3234#issuecomment-1504764774

目前根据 bench 结果:

```
Gnuplot not found, using plotters backend
Anyhow/anyhow/v1.0.76 time: [46.255 ns 50.158 ns 54.338 ns]
change: [-3.3466% +7.6940% +20.010%] (p = 0.18 > 0.05)
No change in performance detected.
Found 5 outliers among 100 measurements (5.00%)
3 (3.00%) high mild
2 (2.00%) high severe
Anyhow/anyhow/v1.0.90 time: [48.072 ns 56.167 ns 63.721 ns]
change: [-29.746% +34.093% +175.67%] (p = 0.69 > 0.05)
No change in performance detected.
Found 16 outliers among 100 measurements (16.00%)
11 (11.00%) high mild
5 (5.00%) high severe
```

但是我的测试环境发生变动: AMD AI9 HX370, 7500MT LPDDR5.

```
rustc 1.84.0-nightly (e7c0d2750 2024-10-15)
binary: rustc
commit-hash: e7c0d2750726c1f08b1de6956248ec78c4a97af6
commit-date: 2024-10-15
host: x86_64-pc-windows-msvc
release: 1.84.0-nightly
LLVM version: 19.1.1
```

测试代码:

```rust
use criterion::{criterion_group, criterion_main, BatchSize, Criterion};

fn bench_maps(c: &mut Criterion) {
let mut group = c.benchmark_group("Anyhow");

group.bench_function("anyhow/v1.0.76", |b| {
b.iter_batched(
|| anyhow_1_0_76::anyhow!("test error"),
|e| {
criterion::black_box({
let _ = e;
});
},
BatchSize::SmallInput,
)
});

group.bench_function("anyhow/v1.0.90", |b| {
b.iter_batched(
|| anyhow_1_0_90::anyhow!("test error"),
|e| {
criterion::black_box({
let _ = e;
});
},
BatchSize::SmallInput,
)
});
}

criterion_group!(benches, bench_maps);
criterion_main!(benches);
```

切换至当前 stable rust 测试:

```
rustc 1.81.0 (eeb90cda1 2024-09-04)
binary: rustc
commit-hash: eeb90cda1969383f56a2637cbd3037bdf598841c
commit-date: 2024-09-04
host: x86_64-pc-windows-msvc
release: 1.81.0
LLVM version: 18.1.7
```

```
Running benches/anyhow.rs (target\release\deps\anyhow-e035dda9f6eff98f.exe)
Gnuplot not found, using plotters backend
Anyhow/anyhow/v1.0.76 time: [7.3229 ns 7.5644 ns 7.9092 ns]
change: [-5.8063% -1.9072% +1.6252%] (p = 0.33 > 0.05)
No change in performance detected.
Found 7 outliers among 100 measurements (7.00%)
3 (3.00%) high mild
4 (4.00%) high severe
Anyhow/anyhow/v1.0.90 time: [46.830 ns 53.064 ns 59.741 ns]
change: [-16.795% -3.3065% +13.223%] (p = 0.68 > 0.05)
No change in performance detected.
Found 6 outliers among 100 measurements (6.00%)
3 (3.00%) high mild
3 (3.00%) high severe
```

emmm, 奇怪的结果.

说白了要不是大小核谁升级 Windows 11, 用 Windows 不还是因为蛮多专业软件只有 Windows 版本, 游戏也是... 所以求稳才是第一.

卧槽, 分分钟被取消备案, 国内机器搭 DNS 是违法的我记得

想趟浑水就买, 最多买点短期的.

楼上有说屏蔽 MCDN 的, 实测会导致更加卡顿, 因为得等播放器 fallback 到备用地址.

一个相对有效的解决方案是: 有软路由的话直接 ban 掉 HTTP DNS, 没有就只能安装 AdGuard 一类的软件本地拦截, 同时 api.bilibili.com / app.bilibili.com / *.biliapi.net / *.biliapi.com 仅解析 IPv6(遇到 CNAME 是 *.bilicdn.* 这种自建机房可能没 IPv6 的就麻烦了), 拿到的资源连接大多数就是 mirror 型的 CDN, 也就是大厂提供的 CDN 了.

至于代码层面的限速, 等人开发个模块吧.

B 的技术向来垃圾, 现在还搞降本增笑, AV1 的码率都压得面目全非了, 还会卡顿, 只能说褒姒.

B 站 APP 端的 ijkplayer 明确是有限速相关代码的, 可以用模块的方式干掉(? 但是目前似乎没有, 似乎是 native 层级别的限制).

此外, B 站大量运用了 MCDN / BCache CDN / PCDN, MCDN (mcdn.bilivideo.*) 和 PCDN (纯 IP 没域名那种, 或者迅雷那个 sy 什么什么的, 南方沿海见得多一点) 众所周知的质量相当差, BCache CDN 作为 B 自建的 VOD CDN, 速度各个地区差异蛮大, 有些地方机房带宽便宜速度就好.

以上是我给一个模块开发替换视频 UPOS 功能时的总结.

@Ocean810975 同意. 我个人不是科班出身, 拿 Rust 入的门, 然后因为参与维护了一个安卓项目, 从学习大佬的代码开始学会了 Kotlin, 后面才补课的 C, 现在因为自己的小项目用到略接触到 Go. Python, JavaScript or TypeScript 也会写一点. 我会的这些语言里面最擅长也最喜欢的就是 Rust, 其次是 Kotlin.

记得 This Week in Rust 分享了一篇文章关于如何加速编译的, 我试用后感受明显, 虽然最有用的那个把 linker 改成 Mold 只支持 Linux 平台, 改 codegen backend 为 cranelift 不支持 WoA(这个影响也不大), 不支持 SIMD, 不支持 unwinding on panics(这个影响蛮大, 不过可以单开个 build 配置继承 release 配置, 把 debug 打开啥的, 专用于测试版本构建). po 个链接供参考: https://blog.rust.careers/post/compile_rust_faster/