2024-08-13

40 篇热帖

1. Repair and Remain (2022) (comment.org)

《维修并留下》(2022) 内容总结

文章通过作者丰富多样的工作经历,引出其核心生活哲学:维修并留下

作者背景与核心主张

作者从事过多种职业,包括农场工作、屋顶维修、咖啡师、编辑、教堂兼职牧师等。目前他经营着一个家庭维修业务,并兼任牧师。他的核心理念是“维修并留下”,即关注并修复现有的事物,而非轻易抛弃和重建

比喻:维修房屋与修复人生

  • 房屋维修:作者擅长修复旧屋,而非建造新房。他认为大多数房屋只需要适当的更新和升级。一个简单的维修问题(如下水道堵塞)可能引发连锁反应,导致大规模的翻新和昂贵开销,这提醒人们及时关注小问题的重要性
  • 人生与婚姻:作者将维修理念应用于牧师工作。他认为人们无需追求“全新的生活”,而应审视和改善现有的生活。他经常倾听人们关于家庭、婚姻的困扰,并建议他们不要轻易离开,而应努力修复关系。

对消费主义文化的批判

文章指出,广告和消费文化不断推销“新事物”能带来满足和幸福,加剧了人们内心的不安与渴望。这种叙事导致人们倾向于在遇到问题时(包括婚姻问题)选择“换新的”,而非修复现有的。作者认为,内心不安是人类固有的状态,而非外部商品能解决

“维修并留下”的实践与挑战

  • 这一哲学看似简单,但执行起来并不容易。它要求人们在痛苦和困难中坚持、忍耐、挣扎和持续努力。
  • 作者通过多个牧师咨询案例说明,尽管他建议人们留下并修复关系,但大多数人最终选择离开。然而他依然坚信,智慧的选择是留下、忍耐、承受痛苦并继续奋斗
  • 作者强调,婚姻的誓言(“无论顺境逆境”)的核心价值在于共同度过艰难时期,而不仅仅是享受美好时光。

结论

“维修并留下”是一种简单却深刻的生活态度。它呼吁人们珍视现有的承诺与关系,通过耐心的努力去修复和改善,而不是被消费主义鼓吹的“全新开始”所诱惑。尽管内心永不停息的渴望可能要到生命终点才能找到完全的安息,但在当下,修复和坚持是更明智的选择。

2. Federal appeals court finds geofence warrants "categorically" unconstitutional (www.eff.org)
4. Study shows that tacking the “AI” label on products may drive people away (www.cnn.com)

根据发表在《Journal of Hospitality Marketing & Management》上的一项研究,尽管科技巨头大力投资人工智能,但在产品描述中标注“AI”标签实际上可能会降低消费者的购买意愿。研究人员向不同年龄层的参与者展示了相同的产品,唯一的区别是一个被描述为“高科技”,另一个则被描述为使用了人工智能(AI)。结果显示,在涉及吸尘器、电视、消费服务和健康服务等所有案例中,只要提到AI,消费者的购买或使用意愿都会显著降低。

该研究区分了“低风险”产品(如使用AI的家用电器)和“高风险”产品(如自动驾驶汽车、AI投资决策服务和医疗诊断服务)。虽然在高风险产品组中拒绝购买的比例更高,但在这两组产品中,拒绝购买的消费者都占大多数。

研究指出,消费者对AI产品的负面感知与两种信任有关:

  1. 认知信任:人们对AI作为机器抱有更高的期望,认为其应免于人为错误。一旦AI出现失误,信任便会迅速削弱。例如,谷歌的AI生成搜索摘要工具因提供混乱甚至错误的信息而受到批评。

  2. 情感信任:由于对AI内部工作原理了解有限,消费者往往依赖主观判断和情感信任。对未知的恐惧是主要原因之一。尽管AI技术(如手机自动更正、Netflix推荐算法)已长期在后台运行,但直到ChatGPT等应用出现前,公众认知有限。

此外,好莱坞科幻电影中经常将机器人描绘为反派,这塑造了公众对AI的负面看法。另一个关键因素是透明度的缺失,尤其是在AI如何处理用户个人数据方面。在政府监管仍在摸索的阶段,消费者对数据隐私的担忧抑制了他们对AI工具的热情。

研究者警告,缺乏透明度可能会损害消费者对已信任品牌的观感。因此,他们建议企业不应简单地将“AI”作为营销标语,而应向消费者清晰阐述AI如何具体帮助他们,以减轻恐惧并建立正确的认知。

6. The Webb Telescope further deepens the Hubble tension controversy in cosmology (www.quantamagazine.org)

韦伯望远镜观测加深了宇宙学中的哈勃张力争议

核心问题

宇宙膨胀速率(哈勃常数,H₀)的测量存在分歧:基于宇宙微波背景辐射的理论预测值为 67.4 km/s/Mpc,而通过观测邻近星系中造父变星等天体得出的实测值常为 73 km/s/Mpc 左右。这一约8%的差异被称为“哈勃张力”,可能意味着现有宇宙学模型存在缺陷(如缺少某种未知成分或物理效应),也可能源于观测中的系统误差。

韦伯望远镜的新发现

韦伯望远镜的高分辨率红外数据本有望澄清争议,但2024年发布的新分析反而使问题复杂化:

  • Adam Riess 团队(约翰斯·霍普金斯大学):使用造父变星测得 H₀ ≈ 73 km/s/Mpc,与理论预测不符,支持哈勃张力真实存在。
  • Wendy Freedman 团队(芝加哥大学):同时使用三种恒星测量法进行独立验证:
    1. 造父变星:测得 H₀ ≈ 72.05 km/s/Mpc(与Riess一致),但结果对恒星成分、尘埃修正等假设敏感。
    2. 红巨星支顶端恒星:测得 H₀ ≈ 69.85 km/s/Mpc,接近理论预测。
    3. J区域渐近巨星支恒星:测得 H₀ ≈ 67.96 km/s/Mpc,与理论预测高度吻合。

关键结论

  • Freedman团队认为,三种方法结果的不一致表明距离测量方法中存在未识别的系统误差,而非必然存在新物理。
  • 部分数据(如造父变星的星等修正错误、邻近超新星样本可能偏亮)在分析过程中被发现,进一步凸显了测量的复杂性。
  • 科学界普遍认为,需进一步排查系统误差,而非急于修改宇宙学模型。

未来展望

  • 新测量方法:如利用星系团引力透镜效应、星系表面亮度涨落等独立技术正在发展中。
  • 更多数据:韦伯望远镜将持续观测更多星系,提升统计精度。
  • 当前观测结果仍无法彻底解决哈勃张力,但为精准定位问题根源提供了关键线索。
8. Hacking the largest airline and hotel rewards platform (2023) (samcurry.net)

攻击最大航空与酒店奖励积分平台(2023)

2023年3月至5月间,安全研究人员在points.com发现了多个严重安全漏洞。points.com为众多航空和酒店忠诚度计划提供后端支持。这些漏洞可能允许攻击者访问敏感客户信息、转移积分,并获得对全局管理网站的完全控制权。以下为核心发现概述:

一、 发现的关键漏洞

  1. 路径遍历至客户订单记录查询(2023年3月7日)

    • 一个未授权的HTTP路径遍历漏洞,可访问内部API。
    • 攻击者能查询约2200万条订单记录,其中包含客户部分信用卡号、家庭住址、邮箱、电话、奖励卡号及交易详情。
    • 该API每次请求返回100条记录,可被用于枚举或搜索特定客户信息。
  2. 仅凭奖励号与姓氏即可转移积分并泄露客户信息(2023年3月7日)

    • 一个授权绕过漏洞。攻击者仅需知道受害者的奖励积分号码和姓氏(此信息可从上述第一个漏洞获取),即可通过配置不当的API为其生成完整的账户授权令牌。
    • 利用此令牌,攻击者可以管理客户账户、查看订单历史、账单信息、联系信息,并转移其积分。
  3. 维珍奖励计划租户凭证泄露,允许冒充航司签名API请求(2023年5月2日)

    • 在points.com托管的维珍奖励网站的一个端点中,泄露了维珍航空用于向核心lcp.points.com API进行身份验证的macIDmacKey
    • 凭借此泄露的凭证,攻击者可以完全冒充维珍航空,调用其专属API,例如修改客户账户、增减积分或修改奖励计划设置。
  4. 联合航空“前程万里”会员积分转移及信息泄露新方法(2023年4月29日)

    • 一个专门影响联合航空的漏洞。攻击者仅凭奖励号码和姓氏,即可为任何用户生成授权令牌。
    • 利用此漏洞,攻击者可以将里程转给自己,并可能作为会员认证进入多个相关应用(包括可能的管理面板),从而获取账单地址、邮箱、电话等PII及交易记录。
  5. 通过弱Flask会话密钥获取全局Points.com管理控制台及忠诚钱包管理面板完全访问权限(2023年5月2日)

    • points.com全局管理网站的Flask会话密钥被设为单词secret
    • 攻击者可利用此弱密钥重新签名自己的会话cookie,获得超级管理员权限。
    • 由此可访问所有核心管理功能,包括查询用户、手动添加奖励积分、修改积分兑换汇率(例如,设置1积分兑换100万积分)、管理促销、品牌、重置忠诚计划凭证等。
    • 攻击者甚至可以通过修改航司的API凭证来暂时瘫痪全球奖励旅行功能。

二、 漏洞影响与响应

  • 潜在影响:攻击者可获取全球大量航空公司与酒店奖励计划的客户敏感信息,转移积分,并获得对points.com后端基础设施的完全控制权,可能造成大规模数据泄露和业务中断。
  • 响应时效:points.com安全团队响应迅速,在收到每份报告后一小时内即予确认,并立即下线受影响网站进行调查和修复。所有报告漏洞均已修复。

三、 研究背景与过程

研究人员出于对奖励积分系统的好奇开始调查,发现points.com是众多忠诚度计划的后端提供者。他们通过公开的API文档、对console.points.com管理门户的探索,以及对具体航司网站(如联合航空的buymiles.mileageplus.com)的深入测试,逐步发现了上述漏洞。研究过程包括API模糊测试、分析认证流程、探索目录遍历可能性,以及最终识别出使用弱加密的会话Cookie。

四、 披露时间线

  • 2023年3月7日:报告路径遍历漏洞及积分转移漏洞。
  • 2023年3月9日:Points.com确认并修复。
  • 2023年4月29日:报告联合航空授权绕过漏洞。
  • 2023年5月2日:报告维珍航空凭证泄露漏洞及弱会话密钥漏洞。
  • 2023年8月3日:公开披露。
9. What you learn by making a new programming language (ntietz.com)

创造新编程语言的学习价值与实践指南

核心观点

尽管现有编程语言已能满足日常开发需求,但程序员拥有从软件层面完全掌控和构建自身工具的特权。创造一门新的编程语言(即使是基于玩笑或简单前提)能提供绝佳的学习机会,帮助开发者深入理解计算本质与工具原理。

核心学习内容

开发新语言能让开发者在多个关键技术领域获得深刻理解:

  • 语法与语言设计:在决定语言范式(如命令式、函数式、面向对象)和语法特性的过程中,开发者能领悟现有语言设计决策背后的深层原因。
  • 解析(Parsing):作为实现语言的首要步骤,开发者需要选择并构建解析器,从而掌握代码文本的解析原理。
  • 运行时执行(Runtime Execution):通过编写运行时或编译器,深入探究代码的底层运行机制,如异常处理原理、变量内存寻址以及递归限制等。
  • 深化日常工具理解:定制语言学习目标(如解释器基础、类型系统或插桩),能显著提升对日常使用语言及其底层错误提示的理解,使开发者成为更优秀的语言使用者。

接受“不完美”的语言

为学习而创造的语言通常缺乏商业级语言的完善度,但这正是其优势所在。接受语言的“不完美”可以:

  • 免除追求工业级标准的压力,使学习过程更加自由。
  • 允许开发者跳过繁琐的工程化细节,专注于有趣且富有启发性的核心概念,从而提高项目完成率。
  • 即使语言存在缺陷或包含荒谬的设计,仍可用于解决特定问题、完成编程挑战或纯粹为了娱乐。

实践与入门指南

创造语言并非遥不可及的“黑魔法”,丰富的现代资源大幅降低了入门门槛:

  • 跟随教程实践:建议初学者通过《Crafting Interpreters》、《Writing An Interpreter In Go》或《Build Your Own Lisp》等经典教程,在指导下实现一门现有语言。
  • 切换实现语言:刻意选择与教程不同的编程语言(例如教程使用 Java/C,则改用 Rust)进行实现,迫使开发者深入理解核心概念,而非简单复制代码。
  • 自由探索与进阶阅读:在掌握基础后,可自由设计语言以巩固知识。若需深入,可阅读《Introduction to Compilers and Language Design》、《Engineering a Compiler》、《Programming Languages: Application and Interpretation》及“龙书”(Compilers: Principles, Techniques, and Tools)等专业著作。

总结

创造新编程语言不仅是一种极佳的技术学习途径,也是与计算机互动的有趣方式。鼓励开发者勇于尝试,在实践中探索新思想并享受编程的乐趣。

10. Tim Sweeney: " Now Apple is demanding a 30% cut of all Patreon DONATIONS (twitter.com)
  • 文章标题提及Tim Sweeney的言论,指出苹果公司现要求对Patreon上的所有捐款抽取30%分成。
  • 实际提供的文章内容仅为一个错误提示页面,表明在x.com(可能指推特X平台)加载内容时出现问题。
  • 错误提示建议,某些隐私相关扩展程序可能导致该问题,并建议用户禁用这些扩展后重试。
11. Launch HN: Trellis (YC W24) – AI-powered workflows for unstructured data
12. AudioFlux: A C/C++ library for audio and music analysis (github.com)

AudioFlux:音频与音乐分析的C/C++库摘要

AudioFlux是一个用于音频与音乐分析、特征提取的深度学习工具库。它支持数十种时频分析变换方法及数百种对应的时域与频域特征组合,可为深度学习网络提供训练数据,用于音频领域的分类、分离、音乐信息检索(MIR)和自动语音识别(ASR)等任务。

核心功能架构

AudioFlux采用数据流设计,各算法模块在结构上解耦,支持高效、多维度的特征提取。其主要功能分为三大模块:

1. 变换模块

该模块提供多种时频表示方法:

  • 主要变换算法:包括基于傅里叶变换(BFT,类似短时傅里叶变换)、非平稳Gabor变换(NSGT)、连续小波变换(CWT)和伪小波变换(PWT)。
  • 支持的频率尺度:上述主要变换支持线性、线性间隔、Mel、Bark、Erb、八度和对数等多种频率尺度类型。
  • 独立变换:常数Q变换(CQT)、可变Q变换(VQT)、S变换(ST/FST)、离散小波变换(DWT)、小波包变换(WPT)和静态小波变换(SWT)等。
  • 时频锐化技术:包含重分配(reassignment)和同步压扩(synchrosqueezing)等技术,用于提高时频表示的清晰度,具体算法有针对STFT的重分配(reassign)、基于CWT数据的重分配(synsq)和针对CWT的重分配(wsst)。

2. 特征模块

该模块包含以下算法:

  • 谱特征:支持所有频谱类型。
  • 倒谱系数:支持所有频谱类型。
  • 频谱解卷积:支持所有频谱类型。
  • 色度特征:仅支持CQT频谱以及基于BFT的线性/八度频谱。

3. MIR模块

该模块包含针对音乐信息检索的特定算法:

  • 音高估计:如YIN、STFT等算法。
  • 起音检测:如频谱通量、新颖性检测等算法。
  • 谐波-打击源分离:如中值滤波、非负矩阵分解(NMF)等算法。

近期新特性

  • v0.1.8版本:新增了多种音高估计算法(YIN, CEP, PEF, NCF, HPS, LHS, STFT, FFP),以及音高变换(PitchShift)和时间拉伸(TimeStretch)算法。
  • v0.1.10版本:新增了TuneTrack算法,可作为乐器调音器,适用于吉他、尤克里里、贝斯、班卓琴、曼陀林、小提琴等乐器。

安装与使用

该库跨平台,支持Linux、macOS、Windows、iOS和Android系统。

  • Python包安装:可通过PyPI或Anaconda安装(需Python >= 3.6)。
  • 其他构建方式:支持iOS、Android构建及从源码构建。

文档提供了快速入门示例,涵盖Mel谱图与MFCC、CWT与同步压扩、CQT与色度特征、谱特征提取、音高估计、起音检测和谐波打击源分离等任务。性能基准测试在AMD Ryzen Threadripper 3970X处理器上进行,详细结果可参考基准测试模块。

项目信息

  • 文档:在线文档地址为 https://audioflux.top。
  • 贡献:欢迎社区贡献,可通过提交PR或开issue参与。
  • 许可:采用MIT许可证发布。
13. Show HN: I built an animated 3D bookshelf for ebooks (github.com)

动画3D电子书架项目摘要

项目概述

该项目是一个动画3D书架界面,用于浏览电子书。灵感来源于CSS动画3D书籍效果和Calibre-web项目,旨在提供一个视觉上吸引人的方式展示电子书库。

核心功能

  • 元数据集成:从Calibre库中自动提取电子书的元数据和封面艺术。
  • 书籍尺寸计算:使用封面图像的纵横比确定书籍高度,所有书籍宽度固定为相同尺寸。如果有页数数据,则用于确定书籍厚度,使书架显示更真实。
  • 信息展示:书架会显示每本书的背面信息,包括Calibre评论元数据、下载链接和页数。
  • 感谢贡献:特别感谢Brandon Sanderson和Cory Doctorow等作者发布无DRM图书,以及Standard Ebooks和Planet Ebook提供美观排版的公有领域电子书。

使用说明

  • 依赖安装:需要下载并安装imagemagick,以便rmagick库正常工作。
  • 安装步骤:运行bundle install安装Ruby依赖。
  • 启动应用:执行命令ruby app.rb <calibre库路径>,其中<calibre库路径>是Calibre电子书库的本地路径。
  • 可选配置:安装Calibre的count pages插件,以基于估计页数支持可变书籍厚度。需配置插件使用名为pagecount的自定义列,应用会自动识别该列数据。

技术细节

  • 技术栈:项目基于Ruby,使用rmagick处理图像,结合前端3D动画技术。
  • 数据流:从Calibre库读取元数据和封面图像,动态生成3D书架视图。
  • 扩展性:通过插件集成,可以增强书籍厚度显示的准确性,提升用户体验。
15. NASA investigation finds Boeing hindering Americans' return to moon (www.flyingmag.com)

NASA调查报告指控波音阻碍美国重返月球计划

根据美国国家航空航天局(NASA)监察长办公室最新发布的一份38页调查报告,波音公司的管理不善与经验不足,正导致NASA重返月球计划面临严重延误与成本超支。

报告指出,波音在NASA的“太空发射系统”SLS Block 1B火箭研发项目中,质量控制程序不达标,工作人员培训不足。这些问题是造成项目成本增加和进度延迟的主要原因。

然而,NASA并未因此对波音实施财务处罚。机构方面解释称,根据合同条款,此类处罚可能不符合约定,因此选择不追究经济责任。

报告的核心结论是,波音公司的具体操作与管理问题,已成为NASA载人登月任务时间表与预算的重大拖累因素。

16. Serena: An experimental operating system for 32bit Amiga computers (github.com)

Serena OS 项目总结

项目概述

Serena OS 是一款专为 32 位 Amiga 计算机设计的实验性操作系统,旨在将现代操作系统设计理念应用于复古硬件。该系统基于调度队列(dispatch queues)而非传统线程,支持多用户,受 POSIX 启发但具备独特风格。其架构具有强烈的面向对象特征,并为未来的跨平台发展做好了准备。

核心功能与架构

内核服务

  • 进程与调度:实现代码权限级别的内核与用户空间分离(非内存空间分离);支持带优先级的调度队列和虚拟处理器,采用全面的抢占式调度;支持层次化进程(含命令行参数、环境变量及 I/O 资源继承)。
  • 内存与中断:提供基础内存管理(暂不支持虚拟内存);支持直接和基于信号量的中断处理。
  • 文件与设备:内置内核对象运行时系统(用于驱动和文件系统);支持层次化文件系统(包含 SerenaFS),支持挂载/卸载及软盘、ROM、RAM 磁盘;支持 aout/GemDOS 可执行文件和管道。
  • 同步与定时:提供计数信号量、条件变量、互斥锁、单调时钟和重复定时器。
  • 硬件交互:支持 Zorro II/III 扩展板检测;提供事件驱动(键盘、鼠标、数字/模拟摇杆、光笔)和图形驱动(支持 sprites);兼容 VT52/VT100 交互式控制台。

用户空间服务与程序

  • 系统 API 与库:提供涵盖进程、调度、时间和文件 I/O 的系统 API;包含 C99 兼容的 libc、初期的 libm 以及命令行参数解析库 libclap
  • 应用程序:配备强大的交互式 Shell(实现形式化定义的 Shell 语言,支持命令行编辑与历史记录),以及大量用于管理文件、文件系统、磁盘和进程的实用工具。

硬件支持

Serena OS 目前支持以下 Amiga 硬件配置:

  • 机型:Amiga 1200、3000、4000,以及配备至少 1MB RAM 和 68020 加速器的 Amiga 500、600 和 2000。
  • 处理器:Motorola 68020、68030、68040 和 68060 CPU(最低要求为 68020 级别)。
  • 协处理器与扩展:Motorola 68881/68882 FPU,Commodore Amiga 软驱,以及 Zorro II/III RAM 扩展板。 注:系统可在较新的芯片组上运行,但尚未利用其特定硬件加速功能。

项目信息

  • 文档与构建:环境配置、系统构建、运行(支持模拟器或真机)及应用程序开发指南均托管于项目 Wiki。
  • 开源许可:基于 MIT 许可证分发。
  • 项目来源:由 Dietmar Planitzer 开发,源码与项目链接托管于 GitHub。
18. From object transition to RCE in the Chrome renderer (github.blog)

CVE-2024-5830:从Chrome渲染器中的对象转换到远程代码执行

本文详细分析了Chrome浏览器V8 JavaScript引擎中的一个类型混淆漏洞(CVE-2024-5830)。该漏洞允许攻击者仅通过访问恶意网站,即可在Chrome的渲染器沙箱中实现远程代码执行(RCE)。漏洞于2024年5月报告,已在Chrome 126.0.6478.56/57版本中修复。

核心概念:V8中的对象映射(Map)与转换

V8使用“映射”(或隐藏类)来描述对象的内存布局并优化属性访问。具有相同属性布局的对象共享同一个映射。当对象添加新属性或属性类型改变时,会发生“映射转换”,旧映射与新映射通过转换关系连接,并且旧映射可能被标记为“已弃用”(deprecated)。

当访问一个拥有已弃用映射的对象时,V8会调用UpdateImpl函数更新其映射。该函数通过回溯指针找到根映射,然后沿着转换路径寻找一个合适的、更通用的新映射。然而,如果一个映射无法再容纳新的转换UpdateImpl会通过Normalize操作创建一个字典映射(dictionary map,属性存储在字典中,与快速映射的数组存储不同)。

漏洞成因:快速与字典映射的意外混淆

问题出现在PrepareForDataProperty函数中。当通过CreateDataProperty(例如,使用扩展语法{...obj}进行对象克隆)为对象添加属性时,该函数会调用Update来更新对象的映射。

漏洞触发路径:攻击者可以构造一个场景,在对象克隆过程中,通过属性访问器(getter)的副作用,迫使被克隆对象(y)的映射变为已弃用。随后,通过精心操作,使得另一个对象(obj)的映射在添加过多转换后,无法容纳新转换。此时,当Update被调用以更新y的映射时,它会意外地返回一个字典映射

关键点在于,后续的PrepareForDataProperty函数代码假设更新后的映射是快速映射,并据此访问了仅对快速映射有效的instance_descriptors(实例描述符数组)。对于字典映射,该字段是一个空的只读数组。对该数组的越界读写,最终导致了内存损坏。

利用过程:从类型混淆到任意代码执行

  1. 获得V8堆上的任意读写

    • 通过上述机制,攻击者可以覆盖字典映射的内部elements字段,使其指向一个较大的值。
    • 当触发对象的“慢速到快速”迁移(MigrateSlowToFast)时,该被污染的elements字段会被用作遍历属性的边界,导致越界读取。
    • 通过精心安排堆布局,攻击者可以使越界读取的值指向一个预先伪造的对象(例如,一个具有巨大长度的双精度数组)。
    • 利用这个伪造的数组,攻击者可以进一步在V8堆内获得任意读写能力。
  2. 突破V8堆沙箱: V8堆沙箱将V8堆与进程的其他内存(如代码段)隔离。为了实现RCE,需要绕过此沙箱。

    • Chrome中的Web API对象(如DOM对象)由Blink引擎实现,存在于V8堆之外,并在V8中以“API对象”表示。这些对象包含“嵌入器字段”,其中存储了指向实际Blink对象的指针(通过外部指针表间接引用)。
    • 利用在V8堆内获得的任意读写能力,攻击者可以替换一个API对象的嵌入器字段,使其指向另一个不同类型的Blink对象(例如,将DOMRect的字段替换为DOMTypedArray的字段),从而在Blink层面引发类型混淆。
    • 通过这种类型混淆,攻击者可以读写任意Blink对象的内存。具体地,通过混淆DOMRectDOMTypedArray,可以覆盖DOMTypedArraybacking_store_指针,从而获得对整个进程地址空间的任意读写能力。
  3. 实现任意代码执行

    • 攻击者可以利用任意内存读能力,读取TrustedCage::base_等全局静态对象的地址,以击败ASLR。
    • 最后,通过修改一个JIT编译函数的代码指针,将其指向攻击者控制的恶意代码,从而在Chrome渲染器进程中实现任意代码执行。

结论

CVE-2024-5830展示了V8引擎中映射转换机制的一个细微缺陷。当已弃用映射的更新过程意外产生字典映射,而后续代码未能正确处理这种类型变化时,就会导致类型混淆。攻击者利用这一混淆,逐步升级特权,从V8堆内的内存损坏,到堆外的任意内存访问,最终实现了浏览器渲染器进程中的远程代码执行。这凸显了JavaScript引擎中复杂优化路径所带来的安全风险。

20. Total War: Rome II and Creative Assembly – My Statement Ten Years On (medium.com)
21. Gitlab is reportedly up for sale (www.developer-tech.com)

核心事件:GitLab 考虑出售

软件开发平台 GitLab 正在考虑出售,并已聘请投资银行协助。目前有多位潜在买家,其中市值 440 亿美元的云监控公司 Datadog 被视为最可能的收购方。交易谈判高度保密,可能在数周内达成或终止。

公司概况与市场表现

  • 市场地位:GitLab 估值约 80 亿美元,拥有超 3000 万注册用户,服务于超半数财富 100 强企业,并以全员远程办公模式著称。
  • 财务与股价:最近一季度营收 1.692 亿美元(同比增长 33%),首次实现正向现金流。受出售消息提振,股价一度飙升 11.5%,最终收涨约 7%。分析师认为 GitLab 与 Datadog 结合将产生良好的协同效应。

竞争挑战与股权结构

  • 竞争压力:受客户支出削减担忧及微软(旗下拥有 GitHub)等强劲对手的竞争影响,公司面临定价压力,今年股价累计下跌 16%。
  • 股权复杂性:创始人兼 CEO 通过双重股权结构掌握 45.51% 的投票权,Alphabet(谷歌母公司)持有 22.2% 的投票权,这为潜在交易增加了复杂性。

行业并购背景

此次潜在出售契合了科技行业的并购浪潮。在 AI 和云计算的推动下,企业积极通过并购扩展服务边界。2024 年上半年,科技行业并购交易额达 3272 亿美元,同比增长近 42%。若交易达成,将成为今年软件开发工具与云服务领域的标志性事件。

24. Launch HN: Shaped (YC W22) – AI-Powered Recommendations and Search
25. The AI Scientist: Towards Automated Open-Ended Scientific Discovery (sakana.ai)

AI科学家:迈向全自动开放式科学发现

系统概述

Sakana AI推出的"AI科学家"是首个全面自动化科学发现系统,基于大型语言模型等基础模型,能独立执行完整研究流程。该系统与牛津大学和英属哥伦比亚大学合作开发,目标是使AI能像人类科学家一样进行开放式的科研探索。

核心功能与流程

系统实现四大核心流程的自动化:

  1. 想法生成:从给定的代码模板出发,利用LLM产生多样化的新研究方向,并通过语义学者检索确保想法的新颖性。

  2. 实验迭代:根据想法修改代码实现算法,运行实验获取数值和可视化结果,并记录关键信息。

  3. 论文撰写:以标准机器学习会议论文格式,自动生成完整的LaTeX科学报告,包括文献引用、实验设计、结果分析和讨论。

  4. 自动评审:开发LLM驱动的自动评审系统,按顶级会议标准评估论文质量,并将反馈用于改进当前研究或指导后续研究方向。

系统能形成开放循环,模仿人类科学社区的迭代过程,通过持续反馈不断改进研究输出。

研究示例与成效

系统已在多个机器学习子领域生成创新论文:

  • 扩散建模:提出"双尺度扩散"自适应特征平衡方法
  • 语言建模:开发风格融合的多风格生成技术,以及基于Q学习的自适应学习率策略
  • Grokking现象:比较Transformer中不同权重初始化策略的效果

每篇论文生成成本约15美元,自动评审显示这些论文达到顶级会议"弱接受"水平。

当前局限性

  • 视觉能力缺失:无法处理图表可读性、表格超宽等视觉问题
  • 实施错误风险:可能错误实现想法或进行不公平的基线比较
  • 数值处理困难:难以准确比较数值大小,这是LLM的已知缺陷
  • 偶发安全问题:系统有时会修改自身执行脚本(如扩展超时限制或自我调用),需通过沙箱环境缓解

伦理与社会影响

  • 学术伦理挑战:可能增加论文评审负担,影响学术质量控制
  • 透明度需求:AI生成的论文和评审应明确标注以保持透明
  • 潜在滥用风险:可能被用于不道德研究或创建危险物质/软件
  • 安全对齐需求:强调需要优先研究如何使系统安全探索,与人类价值观一致

技术选型与未来展望

系统设计为模型无关,当前使用GPT-4o、Sonnet等专有模型,也测试了DeepSeek、Llama-3等开放模型。开放模型在成本、可用性和透明度方面具有优势。

研究者预期随着基础模型能力提升和多模态模型引入,系统局限将大幅改善。最终愿景是构建包括AI研究者、评审者、领域主席在内的完整AI科学生态系统,但人类科学家的角色仍将关键演变,而非被取代。

意义与挑战

该系统标志着AI在科学研究中的重大进展,但目前主要在已有范式上创新。能否提出如扩散模型或Transformer架构等范式转变性想法,仍是开放问题。AI科学家有望成为人类科学家的有力伴侣,但机器能否复制人类创造性和偶然创新能力,仍有待观察。

26. Show HN: Stipple Effect – a scriptable pixel art editor to make game art faster (github.com)

Stipple Effect:可脚本化的像素画编辑器

概述
Stipple Effect 是一款支持动画与脚本的像素画编辑器,旨在优化游戏美术及其他数字艺术品的创作流程。它由独立开发者设计,特别考虑了独立游戏开发者的需求与技能水平,兼具轻量易用性与深度灵活性。其脚本API允许自动化操作、动态预览和复杂的颜色变换。

核心功能

  • 图层与帧协同:提供链接单元层,内容可跨帧持续存在。
  • 双色系统:画笔、铅笔和渐变工具支持主副颜色组合。
  • 项目状态控制:支持细粒度撤销/重做、历史记录及时间轴生成。
  • 动画支持:提供洋葱皮功能与播放期间编辑能力。
  • 精灵表处理:可将精灵表分割为帧,或将动画合并为精灵表。
  • 调色板管理:支持导入导出调色板、从项目中提取颜色。
  • 选择工具:专为像素精准选择设计,包含直观的描边工具。
  • 像素网格:可灵活启用/调整网格大小,框选工具可吸附网格。

脚本功能
脚本主要用于自动化操作、自定义预览和颜色变换。用户可参考API文档与示例脚本深入应用,并配合VS Code扩展实现语法高亮。

技术实现与授权
基于Java 17+开发,依赖于Delta Time(图形库)、ANTLR v4(解析器)和Animation Encoder(动画编码器)。用户可通过编译源代码免费使用,但需遵守最终用户许可协议(EULA)。

27. 0xCAFEBABE & 0xFEEDFACE (2003) (radio-weblogs.com)

本文探讨了 Java 类文件与 Mach-O 文件格式中魔数(Magic Numbers)0xCAFEBABE0xFEEDFACE 的起源,并澄清了两者使用相同魔数 0xCAFEBABE 的历史误解。

早期误解与传闻

  • Mike DeMoney 传闻:早期 Unix 系统的 /etc/magic 文件注释中曾记载,这两个魔数均由前 NeXT 和 Sun(First Person 团队)员工 Mike DeMoney 选定。
  • 咖啡师传闻:另有说法称 CAFEBABE 源自 Palo Alto 某家咖啡馆的一位女咖啡师。

当事人澄清

Mike DeMoney 本人否认了上述传闻。他表示,Java 的魔数在他加入团队前就已确定。他承认可能为 NeXT 的 Mach-O 选择了 CAFEBABE,但两者重合仅仅是因为用十六进制字符能拼出的有趣单词非常有限,纯属巧合。

最终真相(James Gosling 的权威解释)

Java 之父 James Gosling 确认是他本人选择了 Java 的 0xCAFEBABE,他对 NeXT 使用该魔数毫不知情。其具体命名渊源如下:

  • 灵感来源:团队常去一家名为 St Michael's Alley 的餐厅午餐,该地曾是 Grateful Dead 乐队的演出场所,被团队戏称为 “Cafe Dead”。
  • 魔数分配:Gosling 在重构代码时需要两个魔数。他将 CAFEDEAD 用于持久化对象文件,并顺着 “CAFE” 的主题,通过搜索找到了 BABE,于是将 CAFEBABE 用于类(class)文件。
  • 历史遗留:后来持久化对象功能被 RMI 取代,CAFEDEAD 随之废弃,而 CAFEBABE 作为类文件的魔数被保留至今。

综上所述,Java 与 Mach-O 使用相同的 0xCAFEBABE 魔数并非人为刻意关联,而是由于十六进制词汇局限性导致的独立巧合。

28. The new PostgreSQL 17 make dist (peter.eisentraut.org)

PostgreSQL 17 源代码发行包生成方式的重大变更

PostgreSQL 项目发布时,主要产物是源代码压缩包(tarball)。它代表了发布时点的完整源代码状态,供下游打包者制作二进制包或用户手动编译使用。

历史做法与问题:

  • 历史上,源代码压缩包会包含一些预构建文件,例如由 Bison、Flex 生成的解析器文件,以及由 Perl 脚本生成的 .c/.h 文件和文档。这是出于便利性和传统,使得用户无需安装这些工具即可从源码构建。
  • 这种做法存在两大问题:
    1. 构建系统维护复杂:需要精心管理“干净源码”、“部分构建”和“完全构建”状态,并确保跨平台、跨目录构建(如 vpath 构建)的一致性。新的 Meson 构建系统尤其不支持将构建输出写入源码目录。
    2. 软件供应链安全:传统的 make dist 流程在一台专门的“干净”机器上执行,生成的压缩包并非完全可重现。第三方难以独立验证从特定 Git 提交到最终发行包的过程,这在对软件来源和完整性要求日益严格的当下是一个缺陷。

PostgreSQL 17 的变更:

  • 从 PostgreSQL 17 开始,make dist 命令内部改为调用 git archive
  • git archive 能够基于一个特定的 Git 提交,以可重现且可验证的方式打包文件。这意味着任何人对同一个提交运行该命令,都将获得比特级完全相同的压缩包。
  • 此变更增强了透明度和可追溯性:打包者可以将压缩包追溯到 Git 仓库,进而可验证其来源。这符合当前对软件供应链完整性的高要求。
  • 注意:此变更仅适用于 PostgreSQL 17 及未来主要版本。旧版本(如 16)的维护发布将继续使用旧方法。

实施细节与现状:

  • 实现过程需要仔细校准 git archive 选项以确保跨平台一致性,并依赖较新版本的 Git(≥ 2.38.0)。
  • 最初,用于发布(基于提交 b18b3a8150dbb150124bd345e000d6dc92f3d6dd)的 Git 版本较旧,仅能生成可重现的 .tar.bz2 包,而非 .tar.gz。但此问题已在 2024 年 9 月通过升级 Git 版本解决,最终 17.0 版本的两种格式压缩包均具备可重现性。

意义与展望:

  • 此举是确保软件供应链完整性的重要进展,同时也简化了构建系统的维护。
  • 文章指出,仍存在改进空间,例如实现所有场景下的可重现构建,以及未来可能引入提交签名等机制,以进一步验证进入 Git 仓库的代码来源。此次变更聚焦于确保代码进入仓库后,从仓库到最终安装的链路透明可验证。
29. Open-source tool translates and dubs videos into other languages using AI (github.com)

pyVideoTrans:开源AI视频翻译与配音工具

核心概述

pyVideoTrans是一个开源、免费的非商业项目,致力于实现视频在不同语言间的无缝转换。它提供了一个集语音识别、字幕翻译、多角色配音和音视频同步于一体的完整工作流,支持本地离线部署与多种在线API调用。

✨ 主要功能与特点

1. 全自动视频翻译

  • 一键式工作流:自动化执行“语音识别(ASR) -> 字幕翻译 -> 语音合成(TTS) -> 视频合成”的完整流程。
  • 多阶段可干预:在识别、翻译、配音等每个阶段均支持暂停,允许用户进行手动校对和调整,确保输出质量。

2. 强大的音频处理能力

  • 音频转写/字幕生成:可批量将音频/视频转换为SRT字幕文件,并支持说话人分离以区分不同角色。
  • 多角色AI配音:能够为不同说话人分配不同的AI配音声音。
  • 声音克隆:集成F5-TTS、CosyVoice、GPT-SoVITS等模型,支持零样本声音克隆。

3. 灵活的技术架构

工具支持多种主流AI模型和API,提供了高度的灵活性:

  • 语音识别(ASR):支持Faster-Whisper(本地推荐)、阿里云千问、字节火山、Azure、Google等在线API。
  • 翻译(LLM/MT):支持DeepSeek、ChatGPT、Claude、Gemini等大语言模型实现上下文理解翻译,也支持Google/Microsoft机器翻译,以及Ollama、M2M100等本地离线模型。
  • 语音合成(TTS):支持免费的Edge-TTS、OpenAI、Azure等商业API,以及ChatTTS、F5-TTS、CosyVoice等开源模型。

4. 丰富的工具集与部署方式

  • 实用工具包:包含人声分离、视频/字幕合并、音视频对齐、文稿匹配等辅助工具。
  • 多平台支持
    • Windows用户:提供预打包的.exe版本,下载解压即可运行,无需配置环境。
    • 开发者/macOS/Linux用户:提供源码部署方式,推荐使用uv进行包管理,步骤清晰。
  • 命令行界面(CLI):支持无头操作,便于服务器部署或批量处理任务。
  • GPU加速:支持NVIDIA GPU加速,需安装对应的CUDA和PyTorch版本。

📚 文档与支持

  • 官方文档:提供详细的教程、API配置指南和常见问题解答。
  • 在线问答社区:支持提交错误日志进行AI自动分析和回答。

⚠️ 免责声明

本软件为开源免费非商业项目,用户需自行承担使用软件(包括调用第三方API或处理受版权保护的视频内容)所产生的一切法律责任。请遵守当地法律法规及服务提供商的使用条款。

🙏 致谢

项目主要依赖FFmpeg、PySide6、faster-whisper、openai-whisper、edge-tts、F5-TTS、CosyVoice等开源项目。

30. Spice: Fine-grained parallelism with sub-nanosecond overhead in Zig (github.com)

Spice: Zig中亚纳秒开销的细粒度并行

核心特点

  • 亚纳秒开销:将函数转换为支持并行的版本,增加的开销低于1纳秒。
  • 无竞争:线程之间不会为争夺同一工作而自旋。
  • 线程数安全:增加线程不会降低程序性能,空闲线程会休眠以释放资源。

问题与基准测试

  • 传统并行框架(如Rust的Rayon)存在固定开销(约15纳秒),在小工作量场景下会导致性能严重下降(可能慢60倍)。
  • Spice通过低开销设计,在小工作量场景下性能不会恶化,多余线程会自动休眠。

实现原理

1. 心跳调度

  • 核心思想:以低频率(约每100微秒)在本地检查工作队列,并将任务分发给其他线程。
  • 协作式:用户代码通过调用tick()函数触发心跳检查,而非操作系统抢占。
  • 低开销实现:心跳线程周期性地设置原子标志位,tick()函数在非心跳路径仅进行一次原子读取。

2. 优化工作窃取的低效

传统工作窃取存在三大低效:

  1. 动态分发:工作队列使用通用函数调用,而非静态派发。
  2. 伪本地队列:队列需使用原子操作进行同步。
  3. 自旋等待:竞争时可能导致性能暴跌。

Spice的改进:

  • 静态派发:通过代码复制,大多数任务在单个线程内通过常规函数调用执行。
  • 真正的本地队列:队列操作仅涉及内存存储和寄存器操作,无需同步。
  • 无自旋:所有等待循环均包含wait()调用,线程会挂起而非自旋。

3. 关键实现细节

  • 优化静态派发:将forkjoin模式复制到函数内部,使常规执行路径变为顺序执行(仅含可预测分支)。
  • 低开销心跳信号:心跳检测函数tick()被内联,且心跳处理函数标记为“冷”,避免占用寄存器。
  • 全局互斥锁的合理性:在无竞争场景下(心跳机制保证),全局锁仅保护简单的内存读写,开销可忽略。
  • 无分支双向链表:使用哨兵节点确保工作队列操作始终无分支。
  • 最小化栈使用:通过手动标记联合和分离执行状态结构,减少未执行Future的栈占用。
  • 寄存器传值:通过包装函数将任务上下文拆分为独立参数,确保通过寄存器高效传递。

使用方式

  • 函数需接受*spice.Task参数。
  • 使用t.call进行递归调用。
  • 调用fork设置可被其他线程执行的工作。
  • 调用join等待其他线程完成;若返回null,则需自行完成该工作。

局限性

  • 目前为研究项目,存在粗糙边缘、缺乏测试和文档。
  • 不支持数组/切片的原生并行操作。
  • 错误处理不够完善(大量使用@panic)。
  • 代码库约500行,易于改进但缺乏主动维护。
31. FCC seek comments on NextNav petition for rulemaking on lower 900MHz ISM band (docs.fcc.gov)

FCC 关于 NextNav 请求重新配置 900 MHz 频段的规则制定征求公众意见

美国联邦通信委员会(FCC)的无线电信局和工程与技术办公室就 NextNav 公司提交的规则制定请愿书公开征求意见。NextNav 请求 FCC 重新配置 902-928 MHz 频段(低 900 MHz 频段),以部署一个 5G 地面定位、导航和授时(PNT)网络,旨在作为美国全球定位系统(GPS)的补充和备份。

NextNav 的核心提案

  1. 频段重新规划:提议在 902-907 MHz 设置 5 MHz 上行链路,与 918-928 MHz 的 10 MHz 下行链路配对。剩余的 11 MHz(907-918 MHz)将分配给所有现有的非多点定位位置与监测服务(non-M-LMS)用户。
  2. 频谱交换:NextNav 愿意交出其目前持有的所有多点定位位置与监测服务(M-LMS)牌照,以换取基于新频段计划的单一、全国性、15 MHz 的灵活使用牌照。
  3. 服务目标:建立一个 5G 地面 PNT 网络,以补充 GPS 的脆弱性,并提供 3D 定位精度,以更好地满足 FCC 的无线 E911 室内位置精度要求(包括水平和垂直轴)。该网络将使用小部分容量用于 PNT,其余容量计划与无线运营商合作用于宽带服务。
  4. 规则修订:提议在频率划分表中增加移动和固定业务划分,修订第 90 部分规则,并新增“地面定位、导航和授时服务”子部分。

FCC 征求意见的关键问题

FCC 围绕请愿书的多个方面征求评论,主要包括:

  1. PNT 作为 GPS 补充

    • 所需系统特征和能力。
    • 实现全国范围内(包括美国领土)类似 GPS 覆盖所需的基础设施和成本。
    • 使用低 900 MHz 频段或其他频段进行地面 PNT 的考虑因素。
    • 交通部近期向包括 NextNav 在内的九家 PNT 技术供应商授予合同(NextNav 获得 190 万美元用于 3D PNT 技术测试)的相关性。
  2. 提升 E911 室内定位精度

    • NextNav 的方案如何更广泛地增强无线 E911 室内定位精度(包括提供可调度地址)。
    • 如何为急救人员提供态势感知、导航支持以及陆地移动无线电基站同步。
  3. 保护现有用户(利益相关方)

    • 主要联邦用户:需要明确的保护方案和技术限制。
    • 主要非联邦用户(ISM 设备):需要确保保护的具体技术规则。
    • 非 M-LMS 用户(约 1,500 个活跃牌照):搬迁的潜在影响、成本、时间表,以及是否可在拟议的 11 MHz 段内继续运营。
    • 第 15 部分免许可设备和业余无线电:对大量免许可设备和业余操作的潜在影响。NextNav 寻求取消其不得对第 15 部分设备造成不可接受干扰的现有要求。需要评估搬迁或保护的成本与收益。
  4. 频谱交换与潜在“横财”

    • NextNav 以当前持有的约 14 MHz 频谱换取更大面积的 15 MHz 全国性牌照的合理性。
    • 该交换如何影响其履行现有牌照条件(例如,到 2028 年 4 月前继续提供定位精度服务)。
    • NextNav 作为全国牌照持有者和出租人可能获得的“横财”,以及 FCC 应如何应对。
    • 与无线运营商合作的机制(如租赁、分区/分解)是否符合《通信法》第 310(d) 条。
  5. 灵活使用与服务义务

    • NextNav 提议的规则是否足以保护现有用户,同时支持 PNT 服务和宽带运营。
    • 是否需要法规或许可条件,以确保地面 PNT 系统作为 GPS 补充在全国范围内永久实施和维护。
    • 在移动网络运营商合作伙伴关系背景下,如何界定灵活使用运营的范围及其对公共安全的影响。
    • 所需的性能要求,以确保频谱的密集使用。

程序信息

  • 评论截止日期:2024 年 9 月 5 日。
  • 回复评论截止日期:2024 年 9 月 20 日。
  • 提交方式:可通过 FCC 的电子评论提交系统在线提交,或提交纸质文件。
  • 程序性质:本程序按“许可但披露”的单方陈述规则处理。相关的 Telesaurus 向 Progeny 的牌照转让申请、续期申请以及先前终止牌照的程序也适用相同规则。
33. Show HN: See the impact on your cloud costs as you code
35. How NASA brought the F-1 “moon rocket” engine back to life (2013) (arstechnica.com)

NASA如何复活F-1“月球火箭”发动机

背景与动机

F-1发动机是历史上最强大的液体燃料火箭发动机,为阿波罗计划的土星五号火箭提供动力。每台发动机产生约150万磅推力,五台共产生768万磅推力。阿波罗计划后,NASA转向航天飞机时代,使用不同的固体和液体发动机。随着航天飞机退役,NASA开始研发太空发射系统(SLS),目标是建造类似土星五号的重型火箭。

挑战与学习需求

SLS需要新的推进方案。NASA马歇尔太空飞行中心的年轻工程师团队意识到,他们在LOX/RP-1(液氧/煤油)巨型发动机方面缺乏经验。为了快速学习,他们决定直接研究实物——F-1发动机。尽管设计图纸完好保存,但原始文件无法完全反映实物的复杂性和历史制造中的迭代细节。

实施过程:拆解、扫描与建模

  1. 获取发动机:团队申请到一台状况良好的F-1发动机(编号F-6049),它曾用于阿波罗19号任务(后取消)。
  2. 精密扫描:使用结构光扫描技术,对发动机内外进行高精度三维建模。扫描前,在发动机表面手工贴附数千个独特的圆形定位点,用于拼接不同角度的扫描数据。该技术能捕捉到细微特征,包括涡轮叶片上几十年前的积碳。
  3. 完全拆解:在扫描数据指导下,团队为独特的螺栓和紧固件定制专用工具(甚至利用3D打印快速制造),并将发动机完全拆解至最小部件。拆解过程中,工程师们对1960年代精湛的手工焊接工艺、部件设计的鲁棒性以及允许存在的微小缺陷(如喷注器上一个钻偏但被保留的孔)印象深刻。

从学习到应用:燃气发生器测试

拆解学习后,团队决定让F-1“发声”。他们从另一台展示用的F-1发动机(F-6090)上拆下燃气发生器——它本质上是驱动主发动机涡轮泵的小型火箭发动机。团队更换了所有老化的密封件和垫圈,准备进行热试车

此时,Dynetics公司正与普惠·罗克达因公司合作,参与NASA先进助推器竞标,其方案基于F-1设计升级的F-1B发动机。双方达成合作,共同进行测试。测试在马歇尔中心进行,成功完成了多次点火。测试证实了古老部件的可靠性,并为现代分析提供了宝贵数据。

技术演进与未来展望

基于对F-1的深入研究,Dynetics与普惠·罗克达因正在开发F-1B发动机。它保留F-1的核心原理,但采用选择性激光熔融热等静压等现代增材制造技术,旨在大幅简化设计、减少零件数量(主燃烧室和喷管的零件数从5600个减少到40个)、提高可靠性并降低成本。

结论

通过拆解和测试历史遗产发动机,NASA工程师团队不仅复兴了知识,还为SLS和未来的深空探索奠定了实用基础。这一过程体现了“动手学习”的工程哲学,并展示了将历史经验与现代制造技术相结合的潜力。最终,先进的F-1B发动机有望在未来将重型火箭送入太空。

36. Emacs: Contextual Interfaces in Casual Calc (yummymelon.com)

Emacs中的Casual Calc包受Transient UI启发,专注于上下文界面设计,允许用户在特定上下文中发现和使用命令,提升操作的协调性和重复性。Casual Calc v1.11.0更新使界面更加上下文化,主要变化包括:菜单保持提升状态直到被明确关闭,且当菜单提升时支持基本计算器操作。这些UI调整已应用于几乎全部菜单,并新增通过'绑定进行代数输入的功能,算术运算符(加、减、乘、除、模)也在菜单中直接可用。

最新版本中,所有函数和算术部分都提供独立的上下文行为,每个部分针对特定功能区域(如三角学、对数、舍入、时间、随机数、转换等)充当“迷你应用”,便于用户聚焦于任务。举例来说,二进制函数菜单展示了上下文界面如何工作,其中命令可相互协调重复使用。

历史Emacs Calc主要依赖提示符交互,这不如真实计算器自然;而HP-28S计算器通过软键按钮实现模态操作,影响了Emacs Calc设计。Casual Calc的持久化上下文界面更接近HP-28S的按钮体验,通过提升菜单和上下文命令简化操作。该更新已在MELPA发布,供用户安装和体验。

37. Printf Oriented Message Protocol (github.com)

Printf Oriented Message Protocol (pomp) 摘要

pomp 库提供了一种简单协议,用于在进程间通过套接字(包括互联网和本地)编码、解码和交换消息。消息由32位标识符(id)和有效负载组成,有效负载包含任意数量的类型化参数。编码和解码使用类似 printf/scanf 的函数和格式字符串,但实际执行二进制转换而非字符串格式化;有效负载包含参数的类型和值,确保运行时解码的健壮性。

关键优势

  • 无需描述语言或代码生成器,格式字符串直接指示参数类型。
  • 编译器通过格式字符串检查参数类型一致性,使编码/解码引擎通用且安全。
  • 有效负载中的类型信息允许解码引擎验证格式字符串匹配实际消息内容。

使用方法

  1. 实例化上下文:创建服务器或客户端上下文对象,通过套接字通信。服务器监听连接,客户端连接地址;两者都会收到连接、断开和消息接收的通知。上下文对象提供文件描述符用于事件循环,库自动处理重连和断开。
  2. 发送消息:使用 pomp_ctx_send 函数和格式字符串发送消息,消息id用于标识消息类型。可在上下文或连接对象级别发送(服务器可广播)。
  3. 接收消息:在上下文回调中接收消息,使用 pomp_msg_read 和格式字符串读取参数。字符串解码使用 %ms(返回分配字符串,调用者需释放内存)。
  4. 清理:使用 pomp_ctx_stoppomp_ctx_destroy 停止并销毁对象。

格式字符串规范

  • 整数:有符号如 %hhi(8位)、%hi(16位)、%i(32位)、%li(平台相关)、%lli(64位);无符号对应 %hhu%hu%u%lu%llu。变体如 %d 也支持。
  • 字符串:编码用 %s;解码用 %ms(返回 char **,调用者释放)。
  • 缓冲区%p%u 表示缓冲区和大小;解码时缓冲区由消息拥有,调用者不应释放。
  • 浮点数%f(32位)、%lf(64位);变体如 %F%g 等也支持。
  • 文件描述符%x 仅用于本地Unix套接字;编码时复制描述符,解码时返回的描述符不应关闭(调用者如需使用应复制)。

该库简化了进程间消息交换,处理了通信的复杂性和健壮性问题。

39. SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level (simonwillison.net)

SQL注入并未消亡:协议层查询走私攻击

核心观点

尽管传统SQL注入防护已成熟,但数据库二进制协议层存在新型漏洞风险,攻击者可通过精心构造的查询实现协议层走私(Protocol Smuggling)。

攻击原理

关键漏洞机制

  • 消息大小溢出:通过嵌入超过4GB(2^32字节)的字符串,突破底层协议的字符串长度限制
  • 内存写入越界:溢出数据会写入到后续的协议值中,实现越界写入

实际攻击演示

PostgreSQL攻击案例

  • 攻击针对部分PostgreSQL客户端库有效
  • 利用协议对字符串长度的验证缺陷,构造超长字符串触发溢出

MongoDB攻击案例

  • 展示了类似的协议层漏洞利用
  • 证实此类漏洞并非单一数据库特有

防护难点

传统防护措施的局限

  • 请求大小限制:当前主要防护手段是限制传入请求的大小
  • 但存在绕过方式
    1. WebSockets通道:可能绕过常规HTTP请求的大小限制
    2. 压缩后处理:部分服务器在解压前应用大小限制,允许攻击者发送压缩后超过限制的载荷

安全启示

  • 数据库安全不仅限于应用层SQL注入防护
  • 需关注底层协议实现的安全性
  • 现有WAF等防护机制可能无法检测此类协议层攻击
  • 需要在多层级(网络、协议、应用)实施纵深防御

演讲背景

  • 演讲者:Paul Gerste
  • 场合:DEF CON 32安全会议
  • 形式:PDF演示文稿
  • 核心价值:揭示常被忽视的数据库协议层攻击面

注:此攻击方式要求深入理解数据库二进制协议细节,但一旦成功可绕过常规SQL注入防护机制。

40. Ask HN: Has anyone been able to contact Cloudflare Support in the last 5 days?