看来会成为一年一顿的冷饭

1. node 生产环境一样要打包混淆压缩，部署源码是错误的做法
2. node 编译产物和 java 编译产物在防止泄漏源码这件事上强度差不多
3. 有直接登录生产服务器权限的人想干什么都行，你可能需要的是堡垒机

> 前一段时间，有一个小红书的博主，向大家展示自己向 Kubernetes 提交一行文档错误修复的 PR ，并获得批准的过程。那时候，不少人指责博主这么做是在浪费开源软件维护者的时间。

首先论迹不论心，我觉得那个博主没有问题，反倒是指责她羞辱她的人多有问题。

> 有一种观点认为，提交这一类 PR 的人，并不是真心愿意参与开源项目，只是期盼未来出现形如 HNS 或者 STRK 这样的加密货币空投，发放给在开源社区有过贡献的人，从而让自己也获取数百美元的空投加密货币，带来经济利益

值得警惕的是低质量 PR 的 flood ，而不是「细小 PR 」，因为前者会影响社区的正常运行，后者不会。至于 flood ，哪怕没有空投也会有别的，因为世界很大开源很小。

可能会是 T 恤：
- https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama
- https://blog.domenic.me/hacktoberfest/

可能会是 AI：
- https://navendu.me/posts/ai-generated-spam-prs/

可能会是一份教程里的「求职技巧」：
- https://x.com/feross/status/1757463614532071545

> 如果有加密货币空投这个因素需要考虑的话，那么作为具有一定数量的 star 的开源软件维护者，是否需要在 PR 审核的策略上，做出一些调整，把这些并非真正参与开源项目，而是博取针对开源贡献者的加密货币空投的人，来过滤掉？

空投、T 恤、求职加分都是被外部加上去的，跟开源无关，开源社区在它自己的范围内保持公平就行：遇到 flood 那就拒绝所有低质量 PR 和「细小 PR 」，遇到本社区的老面孔使劲刷这类 PR 那就拒绝并批评，其它的就按照对待本社区新人的正常流程来。至于贡献者是被什么驱动，那是别人的自由。

> 但是这也没有一个有效的策略，可能需要对这个人以及这个 GitHub 账号进行深入的背景调查，才能得出这个人对这个开源项目的忠诚程度。

我觉得这整句话都太怪了，给某个开源项目 PR 为什么要对它忠诚？随机找到个以后也不会再接触的一次性轮子，使用之后改一改 typo 修一修小 bug ，这样的 PR 很自然而然啊。还是那句话，论迹不论心。

NIST https://web.archive.org/web/20240626172116/https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
实现 https://github.com/Mbed-TLS/mbedtls/blob/development/tf-psa-crypto/drivers/builtin/include/mbedtls/ctr_drbg.h
安全性 https://en.wikipedia.org/wiki/NIST_SP_800-90A#CTR_DRBG

出门在外身份都是自己给的，我就觉得你是专家我也是专家，你是你们厂的专家，我是我们村的专家

你的问题

做成小书或视频放在网上不就行了吗？有搜索引擎有 AI ，还能有难以入门的普通技能？手把手教学的成本高大概是因为沟通成本高，沟通成本高是因为需要手把手教学的人一般没什么学习的内驱力，什么都等着喂。

> 还要要求原始的代码够简单, 不说能完全让人读懂, 但至少能粗略审核保证没有主观恶意或漏洞/后门

这是优点，但我认为和要讨论的浏览器提供的特性没有太大关系，因为这样的特性应当是通用的，而且我对未经训练的人士能审计出精心构造的漏洞持怀疑态度。这个特性需要确保应用在被专业机构审计后，用户一定可以原封不动地拿到审计过的版本，浏览器网页欠缺这个保障。

> 如果有认识 chrome 或 ladybird 浏览器的大佬, 可以提一下这个想法

它们是开源项目，你可以自己去提 proposal 。但我建议先了解 WEI 风波期间对它的那些激烈批评，了解它为什么广受批评：浏览器是一个“通用”的运行环境，你当然可以借助这个特性保护用户的安全，但别人也可以借助这个特性剥削用户。我认为 Chromium 数年内是没机会再（往所有平台）加入这类特性了，ladybird 的定位则让它天然抵制这类特性。我坚持我的观点：不要在**浏览器网页**中解决这些问题，既不要试图在现在用各种思路实现（也不可能实现），也不要期待未来会增加这样的特性。

@iqoo #4 SRI 或者说目前浏览器网页的所有方案都满足不了 OP 的需求，毕竟只是 Subresource ，也就是你提到的第三方站点，OP 设想中应用则是连自己的站点也无法信任

- https://gist.github.com/jschiefner/95a22d7f4803e7ad32a95b0f3aa655dc
- https://github.com/SideStore/SideStore

@K8dcnPEZ6V8b8Z6 #12 还有 Google 和 AdGuard ，不过还是很稀少，尤其是在 Android 这么重要的操作系统添加支持两年后依然如此

@cccer #19 它很好，但感觉支持它的服务器比支持 DoQ 这个过渡方案的还稀少，尽管 Android 已经添加支持两年了