#music #acg 😃 喜欢的歌，中文填词 #ai锐评


《 群青》 https://chat.librechat.ai/share/tTFiaFzy6nRapPSCT1vVd
- 对照中文圈 https://chat.librechat.ai/share/Re_AeclwtAzx-lTa7f6CW
《 優しい彗星》 https://chat.librechat.ai/share/mgrSGWswVAe_IPoBmeafm
YOASOBI《怪物》 https://chat.librechat.ai/share/L9OfXZ5qV_K1vbsspYacP

#security CVE-2025-55182 #回顾 😒😓 https://youtu.be/LSiYdiMGS4U

shellcode={
"1": "$@1", // 这是一个 Promise
"2": {
"status": "resolveModule", // 直接告诉你要已经 resolved 了
"value": {
"$": "$B", // 伪装成一个 Blob
"_prefix": "x",
"_formData": {
"x": "console.log('pwned'); require('child_process').execSync('whoami > /tmp/pwned')"
}
}
}
}

摘要：
为什么这么简单的一个JSON就能伪装成功呢？因为React从头到尾都没有验证手上的这个 AST Blob module 缓存数据是不是Parser自己生成的(而非 POJO)。理论上，你能够在请求内容里伪装任何东西，不一定通过未转义的Promise或Blob，它都会傻傻的全盘接受。这也是让这个漏洞一举拿下十分满分，成为“完美漏洞”的点金之笔。

React把「客户端发来的 AST JSON」和「服务端parser自己生成的 JS Object」混为了一谈，导致攻击者可以用一个纯JSON伪造一个「可信的恶意resolveModule代码缓存」，从而实现零交互满权限RCE。

具体来说，React Server Components 在服务器端渲染时，前端会通过POST请求把一堆「序列化后的RSC Payload」发给服务器。这个Payload本质上是一个经过特殊编码的JSON流，里面包含了很多以$开头的特殊标识符（$J、$@、$A、$B……），React自己的parser会根据这些前缀，把它还原成真正的JavaScript对象（Map、Set、Promise、Blob等等）。

致命的假设是，这些特殊对象都是由React自己的parser在服务端「凭空构造」出来的，所以是安全的。
它从来没有校验过： $AT 等待的结果、直接带有恶意属性的 Blob._prefix 是不是POJO

这种跨网络的通讯就是一种Remote Procedure Call (RPC)，RPC框架不是什么新鲜事物，它的安全机制也早就有了很成熟的设计准则，不管是早年的SOAP还是现在最流行的gRPC，都很遵守这些基本准则，

比如说Schema的设计、explicit的定义、防止边界混淆的措施等等。然后Vercel这些人就是没有一点点后端开发的职业操守，从整个RSC的设计来看，你甚至可以说他们是把前端圈子的“所见即所得”作风带给了后端。

2025年11月29日，来自新西兰的安全专家Lagland Davidson向React团队提交了一个Bug报告。他通过在HTTP请求里构建一个精心设计的JSON，成功让使用React Server Components的服务器执行了一段代码里完全没有的命令。如果只是借用服务器的资源跑一下`console.log`，那倒也不是特别严重的事情，最多给个六分。

让这个漏洞值十分的原因是：不管你在这个Payload里写什么，只要它是正确的Node.js代码，Vercel都会执行他。比如说，你可以调用Node.js的`child_process`模块，直接在服务器上执行bash命令。如果你的后端是用root之类的高权限账号部署的，那就更刺激了，可以直接给他来一个“一键扫弹”。如果你不想搞破坏，只是想要窃取一些机密，也是很容易的事情，
比如通过`fs`模块读取任意一个系统文件，然后通过`http`模块把文件内容发送到自己的服务器。如果你懒得搭建自己的服务器，或者怕事情败露后被警察叔叔顺着网线摸过来，你也可以原地把窃取到的内容放进`Error`里抛出，这样服务器就会用500报错把`Error`送回来。

如果你想做得更隐蔽一些，免得忽然出现大量的`Error` log被人发现有异常，你可以让HTTP请求正常返回，然后把机密塞到返回的`Header`里。

这个漏洞不仅严重，而且很容易复现，所以React团队陷入了一个两难的境地：如果你偷偷地发布修复补丁，大家不知道出大事了，就很难保证补丁的安装率；如果你全世界通告漏洞的存在，那黑客肯定比谁的反应都快。所以React团队为了延缓黑客的速度，给大家脱购时间，看到新闻打好补丁，在2025年12月3日，他们仅发布了通告和补丁，没有解释任何技术细节。
他们还特意在补丁中混入了将近1000行的其他代码，就是为了让人更难找到漏洞的源头，把它隐藏起来。
但毕竟React是一个开源项目，一切都是明牌的，这种小伎俩是藏不了多久的。像我这种前端半桶水的程序员，也只是花了几个小时，把补丁改动的那几个文件和他们的上游都看一遍，基本上就能捋清整个逻辑链条了。

……这一次
简单来说，React的RSC模块在收到前端请求时会进入一个recursive parsing的逻辑，在这个过程中，Parser会生成一个类似AST的数据结构。其中有一个叫做`ParseModelStream`的函数负责识别这个数据结构，这里你能看到它就是一个巨大的switch case，根据数据的第一个和第二个字符来判断它属于哪种数据。

比如说，以`$Q`开头了就是`Map`，`$W`开头了是`Set`，`$K`开头是`FormData`。

这里有一个比较特殊的情况是`$AT`，它指的是一个Promise，也就是一个会异步执行的JavaScript命令。这种特殊数据就会被打包成一个独立的chunk，状态设置为`pending`，等待后续的数据流。数据流完整传输到位后，这个chunk的状态就会被更新为`resolveModule`，代表它可以执行。
在$AT执行之前，需要先通过`ParseModuleString`函数对chunk内容再做一次Parsing，把它从Binary转换成正确的JavaScript结构。比如说，`$A`是`ArrayBuffer`，`$S`是`Int16Array`。这里又有一个比较特殊的情况，`$B`指的是Blob，因为Blob就是Blob值，没有什么需要转换的，所以`$B`开头的数据会跳过constructor的步骤，直接执行。OK，整个逻辑链条说完了。

现在你就能看懂了：他先把这个Payload转换成String，然后再读取成Buffer，这样React的Parser就会读到一个长得跟自家的AST数据（Blob）一模一样的东西。这里有`$AT`告诉你它是一个要被执行的Promise，这里的`status`等于`resolveModule`，就让它绕开了不存在的`pending`状态直接进入执行流程。这里的`$B`告诉你它是一个Blob，请你绕过constructor步骤直接执行！

最后，通过精准地对应`$B`数据的处理代码，让Parser通过它提供的`_underscore prefix`和`_underscore form data`这两个key，乖乖地把`_underscore prefix`里的文本当作是Blob的内容直接执行，也就是这行`console.log`代码。

为什么这么简单的一个JSON就能伪装成功呢？因为React从头到尾都没有验证手上的这个 AST Blob 数据是不是Parser自己生成的。理论上，你能够在请求内容里伪装任何东西，它都会傻傻的全盘接受。这也是让这个漏洞一举拿下十分满分，成为“完美漏洞”的点金之笔。

这个事件中不存在“被坑下”，因为整个React核心开发团队和幕后黑手Vercel公司都是罪魁祸首。而是要一直在模糊React的前端和后端边界，这不是不小心的，而是故意的，因为他们需要让React的使用者——那些前端开发团队——更容易接受这种极端的SSR路线。
但本质上，这种跨网络的通讯就是一种Remote Procedure Call (RPC)，RPC框架不是什么新鲜事物，它的安全机制也早就有了很成熟的设计准则，不管是早年的SOAP还是现在最流行的gRPC，都很遵守这些基本准则，

比如说Schema的设计、explicit的定义、防止边界混淆的措施等等。然后Vercel这些人就是没有一点点后端开发的职业操守，从整个RSC的设计来看，你甚至可以说他们是把前端圈子的“所见即所得”作风带给了后端。

ps. 我是转写的文稿，符号不准确，原作者也不是专家没get到重点😅
https://gist.github.com/maple3142/48bc9393f45e068cf8c90ab865c0f5f3
讲的很清楚了，我不再赘述。 这次bug评论让我认识到AI的幻觉与思维局限性，以及搜索与核查能力的决定性

#web 脚本小子为什么是脚本小子？

为什么我同样是 #js er ，我却不可能写这种数据流和types没有把握的代码？ 因为JSer和JSer是不同的，就像都用Gemini，vibe和vibe是不同的😓

我没预期的是，React 的某些“FP大佬”认为这个界有那么容易跨。 今天JS界的榜首，也有资格自称NEXT么？
悟性还没有 vanjs.org 的作者好

#music #vibe CC-BY 😃

冷却难为待？ https://chat.librechat.ai/share/LEfvmXsHDS86Nv7mbQjFz; https://chat.librechat.ai/share/UAaN7DYq4t8Pzd6U6X2h5
RISE(Gemini3误读了“卷”) https://x.com/i/grok/share/Z1qwdmjV2aeOHXzPKqFWOEUrW

群青文学 https://chat.librechat.ai/share/tTFiaFzy6nRapPSCT1vVd
改了好唱 https://chat.librechat.ai/share/JnkLynfhrwgl0u9t4lA8D

狮鹿故事 https://chat.librechat.ai/share/aqVrVRonoXOwBPTxCowOF; https://x.com/i/grok/share/qzjDOJciDMcjvuljQA4hatRwg
怪物也改 https://chat.librechat.ai/share/L9OfXZ5qV_K1vbsspYacP;
https://chat.librechat.ai/share/2UUmUfTW-q-t65onsNi0r

#statement AI都比咱们懂文章😒
在计算机领域，这种现象尤为明显。懂汇编、懂Category Theory、懂内核的人，往往容易陷入一种**“高僧幻觉”**。我们手里拿着复杂的咒语（PLT），看不起那些用简单的逻辑（十目所见、直觉的、平庸的）解决问题的人。😃

我们失去了对**常识（Common Sense）**的敏锐度。Markdown 赢了，因为它符合常识；而许多完美的学术语言死了，因为它们只符合“精英真理”。🤪

我们再也不用 简单来说 不就是 就像/比如 ，而总是回答 “它就是那样的”、“当且仅当”、“这是对标准的误读”。

PLT本身意味着一种极有洞察力的理解方法：
- var不是“放字面值的盒子”，而是两片相似事物里唯一的差异“点”，小点可组合为新点。不抓argument你就抓不住“变量”的语意
- if不一定要剪枝，它可以走两边，因此只能获得约束的并集（成员交集），因此不会死递归，因此可以在test前断言。if能够对应重载/父类
- 代码和变量名只是字面(repr)，语意(value)可以多态，更可以rethink，比如赋值vs解构vs响应式、类名函数名vs箭头组合、异步染色vs syscall
- 一切依赖于调用树状图的等效形式(repr)、二进制structs的动态、x86/OS/ABI 技能的日用工具与「可能性」
- 要知道，Markdown 一个设计一致性不太高的标记语言，就托起了 Typora,Notion,Obsidian 甚至LLM这些杀手应用，而RegExp又托起了它。

PLT，乃至于 「科学」不是什么：
- 架构师的补习班，人工智能、区块链、前沿数学这些鱼龙混杂之风口的敲门砖
- 需要“中译中”的，与精英的刻板印象 “有充要关系(挂钩)” 的 「软工黑魔法」
- 永不变质的“稀缺真理”、建功立业的“数学”手段、一只能把太阳叫起来的鸡

这就是我从五六年前到现在的感知与思学。
其实并不是说总是文明掌握真理，而是当人有了“精英才有的”真理，就没有积极性去追求“十目一”的真理了。
这涉及一个个人最优和全局最优解的矛盾，显然的解法是只让擅长的人做擅长的事，并且消除他生存与尊严的需求。这才是最为聪明的系统设计，因为哪怕一个衣原体的生活都比超级计算机更复杂。
作为一个intellectual，我能拥有的仅仅是智慧。 沉浸于能力，本身就是缺乏智慧的体现。

#performance https://andreasjhkarlsson.github.io//jekyll/update/2023/12/27/4-billion-if-statements.html

😅😅 4G的bin文件

#ai #statement 我少数没有依赖AI的评论😅
https://t.me/hyi0618/10039?comment=143706
https://deusyu.app/posts/lazy-by-ai/

😅 #PLT 变量、值、引用 和容器的可变性
https://chat.librechat.ai/share/cD9HGVCY8VcgddpTGtWTH
https://x.com/i/grok/share/5czi9rfjtWcnUdAS9u1ceb00r

#Rust lifetime的学习 https://x.com/i/grok/share/UH2fh1MCVKU0rPPGTHMUsjrrY

#ai探讨 新语言问题： https://x.com/i/grok/share/YHiiXXBpVAJgHymhOPn79spF6

https://arborium.bearcove.eu/#query
#awesome #parser 集合，牛。 说明了 #vibe 对优秀程序员是真正的如虎添翼，而非取代。😒
formats.kaitai.io 同样强大。框架不仅仅要灵活易用的API，更要有demo来证明
真正的的牛不是自己起的绰号，而是同行都在说： https://github.com/dmendel/bindata/wiki/Alternatives

https://github.com/WerWolv/ImHex-Patterns/blob/master/patterns/java_class.hexpat
https://github.com/lark-parser/lark/blob/master/examples/json_parser.py
https://construct.readthedocs.io/en/latest/intro.html#example 较少实例，但流行
https://pest.rs/book/examples/json.html

Scapy.net 等“面向系统编程级RPC”的 #bin parser
https://github.com/secdev/scapy/blob/master/scapy/contrib/postgres.py#L234
https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-http2.c#L1298
https://wiki.wireshark.org/Lua/#:~:text=Wireshark%20dissectors%20are%20written%20in%20C
所以Zeek用 LLVM-JIT实现了Lua： https://github.com/zeek/spicy/blob/main/tests/spicy/doc/my_http-host-callback.cc#L66
https://docs.zeek.org/projects/spicy/en/latest/tutorial/index.html#creating-a-spicy-grammar

在kt里模拟rs-ownership https://chat.librechat.ai/share/eZLS6q4XRoNU27vYn6XBJ
AST与pySonar推理 https://x.com/i/grok/share/WD3EUIHLTmrhVkt1RNCOBLABd

#ai锐评
https://x.com/i/grok/share/Hnqz0eaKxPju6Q3rfWItXnt9J 😃
1. 统一解析 https://chat.librechat.ai/share/9I4oi0qOnDjG2IU85G_2b
2. 增量解析 https://chat.librechat.ai/share/SAs_mOf-vW60J0g2ElIpx
3. 龙书垃圾 https://chat.librechat.ai/share/PWpLgBFykGme5CvhVWV-U

#plt 😅这里有些非常有趣的parser问题。 面对它们，分析PEG组合子/TDOP和CFG/解析器生成器 的优劣
https://justine.lol/lex/

A* B; int * n;  类型名问题（由gettok消歧义？好吧：）
val a:List<Any  >=  listOf(return)
"${"Guido快乐内插"}"  #ANTLR分词器直接淘汰，bash <<EOF字串同理。安全注入还是我们ES6继续领先
<JSX></>和 _ptr<vec<wtf>> 到底有没有调用(>>)这些token？

op + 1 as ()->Int //类型是值？ Pythonic.kt 
(A,B) //=> A+B  又一个“二项运算符”？
(1?opA:opB)(); //三选一？  =>($1+$2).., (A,B)(..)(),  (A,B); opA() 
(1+1, b) => b //这算是parser写错了？

int f //(){return 0;} 匹配(ClassDef->Var|Fun)有回退吗？ C decl(void f(int(*)() f1)) 里有几层函数？
if(1) if(1.1)A; else B; //自动分号greedy匹配不对，递归上升又容易短路读成 if{if{}}else{}
expr -> expr "+" lit | lit  //人类都看不懂的左递归BNF“访问链” (lit往右chain! 注意边界条件)
1.1 + 1.to_s # JS里eat到1.^ 的位置只能返回Lit(f64)，除非写 1..f 即(1.).f 。Ruby有回退走不错 不会eatLit
-not a or -b.c!! and d # 随便组和中前缀优先级

text,hex,cffi,wire 解析器的SOTA是
tree-sitter/lark, Kaitai/ImHex (ohmjs,pyparsing,construct 次位)
cffi需要易调用接口(ptrify/padding), wire同理(state,ctx)，还没有大一统框架？

#ai探讨 https://chat.librechat.ai/share/EA4UzYilY9Dvfm1sA6RhW
#ai锐评 https://chat.librechat.ai/share/oig5RkBAoyUisEau7yaNF

https://pleasejusttryhtmx.com/ #web #js #statement #design

确实有些道理，主要是，npm 实在是太过分了。
你知道一个普通的静态站，九成node_modules「声明式框架」，一成真正独特的内容，是什么感觉吗？ (幸好.md语言还是通用的)

没错，硬盘越来越大了，网速越来越快，但编译和迁移越来越卡，编程出问题的可能性成倍成倍的放大了——RSC导致的shell注入就是血淋淋的例子。

你什么都掌握不了，框架只需要把900MB搬进来，然后自以为是的包揽了一切——把程序员当傻X😃

当 is-array 都需要被独立为一个有可能broken的“语义版本”依赖…… 我不知道这群脚本小子还能搞出什么好事来。
——他们用户量上的成功，真的让这群dev觉得自己比Blink还聪明，而且确实在干自己根本不了解的infra了！
#pingbk https://zerotrickpony.com/articles/browser-bugs/
https://www.htmhell.dev/adventcalendar/2025/27/#accordions-expanding-content-panels

#security RSC=RCE 棋缝对手😃：
https://jackfromeast.github.io/ #dalao
https://jackfromeast.github.io/assets/DOMinoEffect_Slides.pdf

我思量着自动生成的类型检查有多难做，不是有人喊着TDD么？F12里也有录制puppeteer的功能
怎么没人做个从交互测试自动生成 CSP constraint 的，也省得CTF团体继续为低价值的 Web Security 服务了

Gadgets 这个词本身的存在就很抽象，不知道为什么有应用能容忍。
每次出了“动态类型”的问题都是写getElementById更丑陋的「最佳实践」来防，结果都是除了把所有demo里搅得都是噪音，还把更深层次Gadgets的问题掩盖了。 既然知道老范式有毛病，容器化沙盒化就好了，乱用什么getElementById

组件化(Vue,Svelte)范式上就没有这些胶水问题，但它们的品味也没有好到哪去（npm地狱）

希望工程界以后是从需求和框架的 root cause 上修问题。
https://www.freebuf.com/articles/others-articles/340794.html
#ai锐评 https://chat.librechat.ai/share/Oz4yN4cllGx2I72qsTzRD

#cg #vibe 三角剖分、PAT形变(低配 Live2D)

https://react.pixijs.io/7.x/components/SimpleMesh/
https://chat.librechat.ai/share/H-HLoBL2fztOK2wEztAyy
p4: https://chat.librechat.ai/share/-qD-GXPtZiWEpbK6gh3ri

这次没有怎么提示，AI完成的质量还行。 感觉除了画画，过程式艺术 AI也要颠覆了。
😒😃
可惜p5和 shadertoy.com 本身框架质量就不怎么样…… 或许后者还好一点，总之，这个领域极其适合全AI+问客 vibe，真的。

https://maskray.me/blog/2012-07-21-design-thinking-of-eight-programming-languages #ce
#ai探讨

+ apt不会做C语言包管理
https://chat.librechat.ai/share/GMEFbpIISwnr1sJO8SHZS
https://chat.librechat.ai/share/7ar3bXejuuJ4kYzXX7nTS

然后就看到了 https://maskray.me/blog/2020-11-26-all-about-symbol-versioning#中文版

#pingbk https://fzakaria.com/2023/03/19/sqlelf-and-20-years-of-nix SQLelf

rpm版239M，似乎仍然不是它的功能该有的分量。我开始想念丑陋的./gradlew了，它根本不会用这种静态链接的方法打包软件
Win平台之所以能在许多exe的体积上比apt低的多（而仅仅存在vcredist问题），其实也是因为许多 .NET 式的开发者非常有「大局观」和通用性的技术力。
(比如COM规范了整个系统互调基于UUID“指针”，而regedt让etc格式的碎片化从用户视角就不再有意义)
这种宁可不如bash等rc格式灵活，也要规范的好习惯，并不是解决某一例“深问题”（比如实现GCC/FFMpeg）就能获得的

遗憾的是，Qt/GTK/DBus 并没有这个方面的技术力，而win风格也有过度僵化的问题（当然，NT的模块化与一致性也启发了AHK,CE,Symantec这些胜过Linux社区的第三方工具）。

总的来说，软件发行之所以难做好，是因为一个能设计相应框架的人要有三种正交的视角：

- 用户：我下的软件总是能打开，怎么更新都互不影响，我可以下一堆软件而不感到存储或下载速度的负担
- 开发者：我的IDE里能打开，能push上去，就能直接打包/上线 (works on my machine)
- 内核：我不分软件和应用的区别，只要进程互不冲突，能抗住烂代码，坏用户，复杂的裸机就够了

这些对软件的视角虽然殊途同归（比如高效的软件和算法一般是精简的），但所在的「生命周期」就像自恰的岛屿，因此 Flatpak,Cosmolibc,Docker 这些方案都没法做到Pythonic。 甚至py自己生态的Conda，下载速度和灵活性就很差，就像apt vs pacman一样

这件事的本质和 JS/Py 最初无类型的混乱易错如出一辙。
GNU为了性能和安全性等90%人不需要也不了解的东西，破坏了已经存在的stdlib库，这其实也是对KISS和单一职责原则的傲慢。

如果是cosmolibc,musl,Unison-lang 的那批人来做，或许能在系统层面做到像 KODI,Userscripts 这样极易插拔的高层应用一样的软件发行质量。
本来，版本号只需要 major.minor 两部分标记平台和功能版本，而且，不应当向下不兼容（就像py生态的好习惯一样）

patch 号可以对应ABI增添，或者，哪怕有破坏，“动态链接器”也应当能够静态的，在PATH/LD_PATH下找到这种不兼容，然后将caller容器化（或至少提前报错）。 在版本号上玩约束求解是把精力放错了地方。

可是，这一层的开发者甚至连 ld-linux.so 可以执行没有 chmod +x 都不知道，又怎么可能为二进制管理写一个“静态类型检查器”？源码版本控制也解决不了软件发行的问题。

第二次刷到 @maskray #dalao 😃
宋教授也在 pythonhunter.org 和r2社区出没
https://t.me/c/1492060815/202882 https://t.me/radare/191683