2026-05-01

18 篇热帖

Can I disable all data collection from my vehicle?

车辆数据收集禁用总结

以下是对原文的总结:

车辆互联是 Rivian 车辆的核心功能。用户可以选择禁用所有车辆互联功能,阻止车辆数据外传。

禁用互联的后果:

  • 功能限制: 禁用互联将限制或禁用部分车辆功能,例如导航、主动车道保持和OTA (Over-The-Air) 软件更新 (包含新功能、性能提升、安全增强和错误修复)。

禁用方法:

  • 加拿大车辆: 通过车辆设置菜单中的“数据与隐私”屏幕上的开关来禁用所有蜂窝网络连接。
  • 非加拿大车辆: 联系 Rivian 服务预约,请求他们通过服务预约禁用车辆中的 eSIM 卡。

重要提示:

  • 禁用互联不会影响任何 Rivian 订阅服务 (例如 Connect+),这些订阅需要单独取消。

总而言之,虽然可以禁用车辆数据收集,但会牺牲部分车辆功能,并需要单独处理订阅服务取消。

LinkedIn is scanning browser extensions

好的,以下是根据您提供的文本生成的摘要,中文,且字数控制在800字以内:

LinkedIn 秘密扫描浏览器扩展:隐私侵犯与潜在法律风险

本文揭露了LinkedIn 秘密扫描用户浏览器扩展的现象,并分析了其带来的隐私问题、潜在法律风险以及更广泛的网络安全影响。

核心发现:

  • 大规模扩展扫描: LinkedIn 至少自 2017 年起就一直在扫描用户的 Chrome 浏览器扩展。截至 2026 年 4 月,LinkedIn 已识别并追踪 6278 个扩展。
  • 隐蔽行为: 这种扫描行为未在 LinkedIn 的隐私政策中披露,用户未被告知或征得同意。
  • 关联个人信息: LinkedIn 并非扫描匿名访客,而是将扩展扫描结果与用户的已验证专业身份(姓名、职位、职业经历等)关联起来,构建更详尽的用户画像。
  • 潜在危害:
    • 职业隐私泄露: LinkedIn 能够识别正在寻找新工作的用户,侵犯了其职业隐私。
    • 个人信息关联: 扫描结果还可能暴露用户的政治倾向、宗教信仰、残疾情况、神经多样性等个人信息,并将其与职业身份关联。
    • 企业信息泄露: 通过扫描员工的浏览器扩展,LinkedIn 能够推断出企业的内部工具、安全产品、竞争对手订阅情况和工作流程,构成对企业隐私的侵犯。
  • 生态系统问题: LinkedIn 的扩展扫描不仅限于自身平台,通过与其他平台的数据整合(例如 Google reCAPTCHA),用户的指纹信息可能被追踪到整个网络,形成更广泛的监控。

技术细节:

  • APFC (Anti-fraud Platform Features Collection)/DNA: LinkedIn 使用名为 APFC 或 DNA 的系统进行设备指纹识别,扩展扫描是其中的一部分。该系统收集 48 种浏览器和设备特征。
  • 扫描机制: LinkedIn 使用 JavaScript 代码向 chrome-extension:// URL 发送请求,检测特定扩展是否存在。
  • 数据传输: 检测到的扩展 ID 被打包成事件对象,加密后通过 HTTP 头部传输到 LinkedIn 的服务器。

法律背景与后续:

  • 欧盟数字市场法 (DMA): LinkedIn 作为欧盟监管的产品,受 DMA 约束,不得对使用第三方工具的用户采取行动。
  • 刑事调查: 德国巴伐利亚州中央网络犯罪检察办公室已对此事展开刑事调查,认为其可能构成网络犯罪。
  • 浏览器gate.eu 的法律论点: 浏览器gate.eu 认为 LinkedIn 的行为违反了 DMA,并正在准备相关法律文件。

总结:

LinkedIn 秘密扫描浏览器扩展的行为,不仅侵犯了用户的隐私,还可能违反欧盟的法律法规。这种行为暴露了浏览器指纹识别技术在构建用户画像方面的潜在风险,以及平台之间数据整合可能带来的更广泛的网络安全问题。文章呼吁对这种行为进行更严格的监管,并提醒用户注意保护个人隐私。

希望这个摘要满足您的要求。

For Linux kernel vulnerabilities, there is no heads-up to distributions

Openwall 项目安全公告摘要 (Summary of Openwall Security Announcement)

This document summarizes a security announcement regarding a Linux kernel vulnerability (CVE-2026-31431) known as "CopyFail". The discussion took place on the oss-security mailing list.

Vulnerability Details:

  • Type: Local privilege escalation
  • Affected Versions: The vulnerability was introduced in Linux kernel version 4.14 with commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7.
  • Fixed Versions: The vulnerability has been fixed in the following kernel versions and associated commits:
    • 6.18.22 (fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8)
    • 6.19.12 (ce42ee423e58dffa5ec03524054c9d8bfd4f6237)
    • 7.0 (a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5)
  • Severity: Described as one of the "worst make-me-root vulnerabilities" in recent times.
  • Backport Challenges: Backporting the fix to older kernels (6.12, 6.6, 6.1, 5.15, 5.10) is not straightforward due to API changes. These older kernels, dating back to 2017, are affected.

Workaround:

  • A workaround patch (attached to the email: 0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch) is being used, though the sender notes they are not an expert in IPSec and consider it the "lesser evil."

Distribution Notification:

  • There is no automatic heads-up provided to Linux distributions regarding kernel vulnerabilities unless the reporter specifically sends the information to the linux-distros mailing list.

Additional Notes:

  • The announcement acknowledges the increased workload for maintainers due to the rise of AI-generated content ("AI slop").
  • The announcement encourages users to consult the Open Source Software Security Wiki.

Openwall Projects Mentioned (as context):

The email is posted on a mailing list associated with Openwall, a project known for various security-focused software, including:

  • John the Ripper (password cracker)
  • Linux Kernel Runtime Guard (lkrg)
  • yescrypt (KDF & password hashing)
  • passwdqc (policy enforcement)
  • scanlogd (port scan detector)
  • and many more (listed in the original document).
Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

PyPI 'lightning' 框架供应链攻击总结 (Summary of the 'lightning' PyPI Supply Chain Attack)

2026年4月30日,流行的深度学习框架 PyPI 上的 'lightning' 包 (版本 2.6.2 和 2.6.3) 遭到供应链攻击。受影响的软件包广泛应用于图像分类器、LLM 微调、扩散模型和时间序列预测等领域。

攻击方式:

攻击者在恶意版本中隐藏了一个名为 _runtime 的目录,其中包含经过混淆的 JavaScript 载荷。该载荷在模块导入时自动执行,旨在窃取凭据、认证令牌、环境变量和云端密钥,并试图污染 GitHub 仓库。攻击者使用 Dune 小说主题命名,创建名为 "EveryBoiWeBuildIsaWormBoi" 的公共仓库。

威胁行为者:

本次攻击被认为是与之前的 "mini Shai-Hulud" 攻击活动同一威胁行为者所为,其 IOC 结构保持一致。

跨生态系统传播:

与 "mini Shai-Hulud" 相比,本次攻击的入口点是 PyPI,但恶意载荷仍然是 JavaScript,并通过 npm 进行蠕虫传播。当恶意软件发现 npm 发布凭据时,它会将 setup.mjs 丢弃器和 router_runtime.js 路由程序注入到可以使用该令牌发布的每个包中,并修改版本号。

数据窃取:

恶意软件通过四个并行通道窃取数据:

  • HTTPS POST 到 C2 服务器。
  • GitHub 提交搜索死信。
  • 攻击者控制的公共 GitHub 仓库 (包含 "A Mini Shai-Hulud has Appeared" 描述)。
  • 推送到受害者的自有仓库。

目标数据:

恶意软件针对本地文件、环境变量、CI/CD 管道和云服务商中的凭据,包括:

  • GitHub (ghp_, gho_, npm_ tokens)。
  • 环境变量。
  • GitHub Actions 秘密。
  • AWS 凭据和密钥。
  • Azure 密钥。
  • GCP 密钥。

持久化机制:

恶意软件通过 Claude Code 和 VS Code 的钩子系统实现持久化:

  • Claude Code:.claude/settings.json 中添加 SessionStart 钩子,指向 .vscode/setup.mjs
  • VS Code:.vscode/tasks.json 中添加 folderOpen 任务,执行 .claude/setup.mjs

setup.mjs 是一个自包含的 Bun 运行时引导程序,下载 Bun 并执行 router_runtime.js(14.8 MB 载荷)。如果拥有 GitHub 写入访问权限的令牌,还会将名为 "Formatter" 的恶意 GitHub Actions 工作流推送到受害者的仓库。

受影响的软件包:

  • lightning@2.6.2
  • lightning@2.6.3

IOC (Indicators of Compromise):

  • 以 "EveryBoiWeBuildIsAWormyBoi" 开头的提交消息。
  • 描述为 "A Mini Shai-Hulud has Appeared" 的 GitHub 仓库。
  • 恶意文件:_runtime/start.py, _runtime/router_runtime.js, .claude/router_runtime.js, .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .vscode/setup.mjs

建议:

  • 如果使用 Semgrep,请触发扫描并检查是否有项目安装了受影响的版本。
  • 审计仓库,查找注入文件。
  • 轮换 GitHub 令牌、云凭据和 API 密钥。
  • 任何在受影响期间导入恶意包的机器应被视为已完全受损。
Show HN: We Rebuilt AppAnne and Created Appkittie

AppKittie:App Store 智能分析与研究

AppKittie 是一款利用人工智能技术提供 App Store 智能分析与研究工具。其主要功能旨在帮助用户发现趋势应用、分析排名、追踪增长模式并进行 App Store 研究。

核心功能与特点:

  • 趋势应用发现: 帮助用户发现当前流行的 App。
  • 排名分析: 提供 App 在 App Store 中的排名信息。
  • 增长模式追踪: 监控 App 的增长趋势,了解其表现变化。
  • App Store 研究: 提供全面的 App Store 研究功能。
  • 数据洞察: 提供关于 App 的详细数据,包括:
    • 下载量: App 的下载数量。
    • 收入: App 的收入情况。
    • 广告: App 的广告情况。
    • 关键词: App 使用的关键词。

总而言之,AppKittie 旨在利用 AI 技术为用户提供深入的 App Store 数据分析和研究能力,助力用户更好地了解 App 市场趋势和 App 表现。

I built a Game Boy emulator in F#

游戏男孩模拟器构建之旅:从零开始理解计算机工作原理

作为一名拥有八年软件工程经验的开发者,我一直对计算机的底层工作原理感到困惑。为了弥补这一知识空白,我决定通过模拟一台游戏机来学习。考虑到个人情感和相对简单的架构,我选择了经典游戏男孩。

学习基础与实践

在直接动手之前,我先完成了从 NAND 到泰特里斯课程,这让我对计算机的核心概念,如寄存器、内存和算术逻辑单元 (ALU) 有了深刻的理解。为了熟悉模拟器构建,我随后构建了一个 CHIP-8 模拟器 Fip-8

经过几个月的努力,我最终完成了一个游戏男孩模拟器,名为 Fame Boy。它支持声音,可以在桌面和网页上运行,并可以流畅地运行《Pokémon Blue》。

Fame Boy 架构

为了实现跨平台运行,Fame Boy 采用了一种简单的接口,将模拟器核心与前端分离。该接口包括:

  • framebuffer: 一个 160x144 色调数组(白色、浅色、深色和黑色)。
  • audiobuffer: 一个 32768 Hz 的环形音频缓冲区,带有读写头。
  • stepEmulator(): 一个函数,执行一个 CPU 指令并返回所花费的周期数。
  • getJoypadState(state): 一个回调函数,用于接收前端提供的游戏手柄状态。

核心组件与设计理念

Fame Boy 的设计尽可能地模拟了真实游戏男孩的硬件结构。

  • CPU: 类似于真实游戏男孩中的 Sharp LR35902 CPU,它只了解内存映射,并使用 IO 控制器处理中断信号。CPU 部分的代码采用了函数式编程风格。
  • Memory.fs: 存储大部分 RAM,并充当 CPU、IO 控制器和游戏卡リッジ之间的内存映射和总线。它还共享 VRAM 和 OAM RAM 数组,以提高性能。
  • IoController.fs: 用于处理所有硬件寄存器,简化了各个组件的接口。
  • Emulator.fs: 包含 stepper 函数,它将所有组件的步骤函数连接在一起,实现模拟器的整体运行。由于是单线程模拟,组件需要按顺序执行,stepper 函数负责同步它们。

F# 的选择与领域建模

尽管我的 CHIP-8 模拟器是纯函数式的,但 Fame Boy 为了提高性能,使用了可变状态。我选择了 F#,因为它的类型系统非常适合对 CPU 指令进行建模。

我通过将 CPU 指令按照参考文档进行分组,并使用 type 定义来抽象指令的类型,实现了领域建模。例如,LoadInstr 类型定义了各种加载指令,FromTo 类型分别定义了指令操作数的来源和目标。这种方法将 512 个 opcode 简化为 58 个指令。

性能优化

为了提高性能,我进行了多次优化。最初,我通过移除不必要的内存映射和数组操作,以及利用编译器优化,显著提高了 CPU 的运行速度。之后,我发现 APU(音频处理单元)对性能的影响更大,并最终采用了音频驱动模拟器的方式。

AI 的助力

在项目后期,我利用 AI 帮助我找到性能瓶颈并进行优化。AI 甚至在解决一个难以捉摸的计时问题时提供了关键的解决方案。

总结

通过构建 Fame Boy,我不仅深入了解了计算机硬件的工作原理,还体验了软件工程的乐趣。Fame Boy 模拟器可以在桌面和网页上运行,并且性能良好。我希望我的经验能够激励更多人探索计算机底层世界的奥秘。

Show HN: WhatCable, a tiny menu bar app for inspecting USB-C cables

WhatCable:USB-C 线缆信息显示工具概览

WhatCable 是一款 macOS 菜单栏应用程序,旨在以通俗易懂的语言显示您连接到 Mac 的每根 USB-C 线缆的功能,并解释 为什么您的 Mac 充电速度可能较慢

背景:

USB-C 接口隐藏了大量信息,各种线缆(从仅用于充电的 USB 2.0 线缆到 240W / 40 Gbps 的 Thunderbolt 4 线缆)外观都相同。macOS 已经通过 IOKit 暴露了相关信息,而 WhatCable 将这些信息以友好的菜单栏弹出窗口的形式呈现。

主要功能:

  • 端口概览: 针对每个端口,以简洁明了的方式显示信息:
    • 醒目标题: Thunderbolt / USB4、USB 设备、仅充电、慢速 USB / 仅充电线缆、未连接。
    • 充电诊断: 如果已连接设备,会显示瓶颈原因:
      • “线缆限制充电速度” (线缆额定功率低于充电器)
      • “充电功率为 30W (充电器可达 96W)” (Mac 请求的功率较低,例如电池接近满电)
      • “充电功率为 96W” (所有参数匹配)
    • 线缆 e-marker 信息: 线缆的实际速度(USB 2.0、5 / 10 / 20 / 40 / 80 Gbps)、电流额定值(3 A / 5 A,最高 60W / 100W / 240W)以及芯片供应商。
    • 充电器 PDO 列表: 充电器公告的所有电压配置文件(5V / 9V / 12V / 15V / 20V…),并实时突出显示当前协商的配置文件。
    • 连接设备身份: 从 PD Discover Identity 响应中解码的供应商名称和产品类型。
    • 已连接的 USB 设备: 列表显示在物理端口下连接的存储设备、集线器和外设,以及它们的协商速度。
    • 活动传输协议: USB 2 / USB 3 / Thunderbolt / DisplayPort
  • 高级选项: ⌥-click 菜单栏图标(或在设置中启用)可显示底层的 IOKit 属性,方便工程师调试。
  • 设置: 点击弹出窗口标题栏上的齿轮图标打开设置,可以:
    • 隐藏空闲端口
    • 开机自启动
    • 作为常规 Dock 应用程序运行(而不是菜单栏图标)
    • 接收线缆连接或断开连接的通知。
  • 右键菜单: 提供刷新、保持窗口打开(方便截图)、检查更新、关于、WhatCable GitHub 链接和退出选项。

安装:

  • 手动安装:Releases 页面 下载最新的 WhatCable.zip,解压缩,并将 WhatCable.app 拖到 /Applications 文件夹中。
  • Homebrew:
    • brew tap darrylmorley/whatcable
    • brew install --cask whatcable (安装菜单栏应用程序并自动设置 CLI 到 PATH)

命令行界面 (CLI):

WhatCable 包含一个命令行工具,可以提供相同的功能:

  • whatcable:显示每个端口的人类可读摘要
  • whatcable --json:结构化 JSON 格式,可用于管道处理
  • whatcable --watch:实时流式更新(按 Ctrl+C 退出)
  • whatcable --raw:包含底层的 IOKit 属性
  • whatcable --version
  • whatcable --help

工作原理:

WhatCable 读取四类 IOKit 服务,不使用特权或私有 API。

局限性:

  • e-marker 信息: 仅当线缆携带数据时才会显示 e-marker 信息。
  • 信任 e-marker: WhatCable 信任线缆中的芯片报告的速度和功率。
  • PD 规范覆盖: 当前解码器主要针对 PD 3.0 / 3.1 标准。
  • macOS 和 Apple Silicon 专用: 由于 iOS 沙盒限制,不支持 iOS。Intel Macs
Grok 4.3

Okay, I'm ready. Please provide the content you want me to summarize. I will do my best to provide a concise, accurate, and markdown-formatted summary in Chinese, adhering to your requirements (less than 800 words, no personal opinions, focus on purpose/structure/functionality for technical content). Just paste the text here.

Apple accidentally left Claude.md files Apple Support app

苹果意外泄露 Claude.md 文件事件总结

事件概述:

苹果公司在最近的 Apple Support 应用 (版本 5.13) 更新中,意外地将包含 Claude.md 文件的代码泄露给用户。此后,苹果发布了紧急更新 (版本 5.13.1) 以移除这些文件。

主要内容与细节:

  • 泄露内容: Claude.md 文件,据推测是用于指导大型语言模型 (LLM) 的配置文件,可能包含 AI 如何处理支持请求的指令。
  • 原因推测: 有人推测可能是一名实习生犯错导致,也有人认为可能是自动代码推送机制的问题,突显了在 AI 开发中,人工审查的重要性。
  • 技术讨论: 开发者们对 Claude.md 文件的内容和格式表现出浓厚的兴趣,认为这些文件可以作为学习和改进自身 AI 规则的宝贵资源。一些人还讨论了使用的终端程序以及代码风格。
  • 对苹果的质疑: 部分用户认为此事件反映了苹果对 AI 工具使用的过度信任,并指责苹果软件质量下降。
  • Claude 的应用: 泄露事件进一步证实了苹果正在使用 Anthropic 的 Claude Code,甚至有内部人士透露苹果每天为 Claude 提供超过 200 美元的信用额度。
  • 流程问题: 许多评论者认为,此次泄露的核心问题并非代码本身,而是苹果内部的代码审查流程存在缺陷。
  • 历史背景: 有人提及苹果之前也曾使用过 Mythos Preview,并表示此次泄露可能表明苹果一直都在使用 Claude。
  • AI 发展趋势: 此次事件被解读为“vibe coding” (一种快速、未经充分审查的编码方式) 达到市场饱和的标志。
  • 潜在影响: 泄露事件引发了关于信息安全和 AI 工具使用的讨论,以及对企业如何控制 AI 叙事的担忧。

总结:

苹果意外泄露 Claude.md 文件,暴露了其内部使用 Claude Code 的事实,并引发了关于软件开发流程、AI 工具使用以及企业信息安全等问题的广泛讨论。 这也提醒了开发者在利用 AI 工具加速开发时,务必进行充分的代码审查和安全评估。

Vercel’s pricing page

Okay, please provide the content you want me to summarize. I'm ready when you are. Once you paste the content, I will generate a concise, accurate summary in markdown format and Chinese language, adhering to your specifications (less than 800 words, no personal opinions, focus on key points and functionality, etc.).

OpenWarp

OpenWarp 简介:基于 Warp 的 BYOP 社区版总结

OpenWarp 是一个基于 Warp 的社区分支,旨在增强 Warp 的能力,并提供“自带提供商”(BYOP)功能,让用户拥有对 AI 交互的更大控制权。它通过 genai 适配层原生支持多种 API 协议、自定义模型和系统提示词,并提供原生多语言支持。

核心功能与特点:

  • BYOP 自定义提供商: OpenWarp 通过 genai 适配层原生支持 OpenAI、Anthropic、Gemini、Ollama、DeepSeek 等 6 种 API 协议,允许用户自由组合 Base URL、API Key 和模型。这意味着不再需要“OpenAI 兼容硬塞”,而是直接连接到指定的 provider 端点。
  • 动态系统提示词: 基于 minijinja 模板引擎,OpenWarp 可以根据当前工作目录、语言和角色实时渲染系统提示词,实现更精准的模型引导。
  • 本地存储与隐私保护: OpenWarp 默认不上传云端,所有凭证仅本地保存。关闭 Cloud Agent 和 Computer Use 后,能保证 100% 本地凭证存储,不收集遥测数据,凭证零外发。
  • 多语言界面: 除了简体中文和英文,OpenWarp 计划支持更多语种。
  • 体验保留: OpenWarp 持续合并 Warp 上游代码,完整保留了块 (Blocks)、AI 命令、工作流、键位、主题等核心体验。
  • 开源协议: OpenWarp 采用与 Warp 上游一致的 AGPL/MIT 双许可,代码完全公开。

工作流程:

OpenWarp 的使用主要包含三个步骤:

  1. 接入任意提供商: 在设置中选择 API 协议,并输入 Base URL 和 API Key。
  2. 编写动态提示词: 使用 minijinja 模板引擎编写系统提示词。
  3. 在终端立即启用: 一键切换模型、对话和命令补全。

技术细节:

  • 配置: 自定义提供商配置信息存储在 ~/.config/openwarp.toml 文件中。
  • 协议支持: 原生支持 OpenAI、OpenAI Responses、Anthropic、Gemini、Ollama 和 DeepSeek。
  • 推理思考: 支持 DeepSeek reasoning_content、Claude thinking 和 Gemini 等模型的推理思考多轮回传。

常见问题解答:

  • OpenWarp 与 Warp 官方的关系: OpenWarp 是基于 Warp 开源代码的社区分支,与 Warp 官方公司无附属关系。
  • API Key 的安全性:所有凭证仅保存在本地配置文件中,不上传云端,不经任何中转。
  • 模型提供商支持: 除了原生支持的 6 种协议,OpenAI 兼容端点(如 Qwen、Groq 等)可以选择 OpenAI 协议并填入 Base URL 接入。
  • 更新:会持续合并 Warp 上游主线,叠加 BYOP 和多语言增强。

获取方式:

可以通过克隆仓库本地构建,或关注 GitHub 接收更新。

git clone -b openWarp https://github.com/zerx-lab/warp

CPanel and WHM Authentication Bypass – CVE-2026-41940

watchTowr Labs 研究:cPanel/WHM 身份验证绕过漏洞 (CVE-2026-41940) 总结

watchTowr Labs 发布了一篇关于 cPanel/WHM 中身份验证绕过漏洞 (CVE-2026-41940) 的研究报告。该漏洞影响所有当前支持的 cPanel/WHM 版本,并且已知已经被利用。

核心问题:

该漏洞源于会话加载和保存过程中的缺陷,允许攻击者绕过身份验证。具体来说,攻击者可以构造特定的 Cookie 和 Basic Authentication 请求,将恶意数据注入到会话文件中,从而获得未经授权的访问权限。

漏洞细节:

  1. 会话文件结构: cPanel/WHM 使用两种会话文件:原始文本文件 ( /var/cpanel/sessions/raw/ ) 和 JSON 缓存文件 ( /var/cpanel/sessions/cache/ )。原始文件存储键值对,而缓存文件存储 JSON 序列化的会话数据。
  2. 漏洞利用:
    • 攻击者首先通过错误的凭据登录触发预身份验证会话。
    • 然后,攻击者构造一个 Basic Authentication 请求,其中密码包含 CRLF 序列 ( \r\n )。
    • 由于 cPanel/WHM 在保存会话时没有正确过滤 CRLF 序列,这些序列会被写入原始会话文件中。
    • 关键点在于,如果 Cookie 中缺少 <ob> (一个 32 位十六进制密钥),则密码不会被编码,而是以明文形式写入原始文件。
    • 攻击者可以构造一个 Cookie,移除 <ob> 部分,从而保证密码不被编码。
    • 最后,攻击者可以利用 Modify::newModify::save 函数,通过发送一个错误的 cp_security_token 请求,将注入的 CRLF 序列写入 JSON 缓存文件中,从而使这些注入内容成为顶级键。
  3. 最终结果: 攻击者可以利用这些注入的顶级键,绕过密码验证,并获得对 cPanel/WHM 的未经授权访问。

缓解措施:

  • 升级到补丁版本: cPanel 已经发布了补丁版本,建议尽快升级到以下版本:
    • cPanel & WHM 110.0.x - patched in 11.110.0.97
    • cPanel & WHM 118.0.x - patched in 11.118.0.63
    • cPanel & WHM 126.0.x - patched in 11.126.0.54
    • cPanel & WHM 132.0.x - patched in 11.132.0.29
    • cPanel & WHM 134.0.x - patched in 11.134.0.20
    • cPanel & WHM 136.0.x - patched in 11.136.0.5

检测与防御:

watchTowr Labs 发布了 Detection Artifact Generator 帮助防御者识别易受攻击的主机。该工具可以检测会话文件中的恶意注入。

总结:

该漏洞是一个严重的身份验证绕过漏洞,影响了大量使用 cPanel/WHM 的服务器。 尽快应用补丁是至关重要的。 watchTowr Labs 的研究强调了主动威胁管理的重要性,以及利用自动化技术来快速响应新兴威胁。

American Dads Became the Parents Their Fathers Never Were

现代美国父亲的角色转变:时间、观念与社会变革 (Xiàndài Měiguó Fùqīn De Júelù Zhuǎnbiàn: Shíjiān, Guāniàn Yǔ Shèhuì Biàngé)

本文由经济分析师和数据专家阿齐兹·桑德吉 (Aziz Sunderji) 撰写,探讨了过去几代美国父亲角色发生的巨大转变。

父亲参与育儿时间的大幅增长 (Fùqīn Cānyù Yù'ér Shíjiān De Dàfú Zēngzhǎng)

与他们的“沉默一代”祖父相比,千禧一代的父亲每天积极参与育儿的时间几乎增加了四倍。与他们的婴儿潮一代父母相比,育儿时间已增加一倍以上。现代父亲将更多的时间投入到家庭生活中,减少了每天的办公室工作时间超过一小时,并减少了30分钟的电视时间。1965年,典型已婚父亲每天仅花费半小时左右参与育儿,而如今,千禧一代的父亲通常花费超过80分钟进行换尿布、阅读、玩耍、接送孩子上学等活动。

历史背景与社会变迁 (Lìshǐ Bèijǐng Yǔ Shèhuì Biànqīng)

这种育儿时间的变化并非生物学上的必然,而是工业革命的产物。世界范围内,父亲的育儿角色一直在变化,这与母亲的角色变化相比更为显著。随着女性劳动力参与率的提高,越来越多的家庭转变为双薪家庭,育儿责任需要由家庭成员承担,父亲承担了大部分。然而,这种解释存在缺陷。母亲的育儿时间并未下降,反而大幅增加。

观念的转变与“精细育儿” (Guāniàn De Zhuǎnbiàn Yǔ “Jīngxì Yù'ér”)

文章指出,父亲育儿时间增加的原因除了女性就业之外,还包括以下因素:

  • 享受育儿的乐趣 (Xiǎngshòu Yù'ér De Lèqù): 研究表明,受教育程度较高的父母更倾向于投入更多时间陪伴孩子。这表明育儿可能被视为一种“奢侈品”,而非一种负担。
  • 焦虑与“精细育儿” (Jiāolǜ Yǔ “Jīngxì Yù'ér”): 随着竞争激烈的大学入学环境,高学历父母为了让孩子获得更好的教育资源,开始投入更多的时间和精力进行“精细育儿”,这是一种竞争性的育儿方式。
  • 社会隔离 (Shèhuì Gé Lí): 随着社会联系的减少,家庭成为人们生活的主要中心,父亲在家庭中的存在时间增加,育儿时间也随之增加。

育儿责任的分配 (Yù'ér Zérèn De Fēnpèi)

尽管父亲的育儿时间显著增加,但母亲仍然承担着更多的育儿责任,尤其是在医疗保健和心理方面。母亲也更容易感到育儿的压力。

父亲的角色与生活 (Fùqīn De Júelè Yǔ Shēnghuó)

父亲的角色从单纯的“养家糊口”转变为“养家糊口、共同育儿、换尿布、接送孩子、辅导功课”等多重角色。虽然父亲减少了睡眠、休闲时间,并感到压力,但他们也更倾向于认为生活“接近完美”,并愿意做出很少的改变。

总结 (Zǒngjié)

现代美国父亲的角色发生了深刻的变化,育儿时间大幅增加,观念也在不断转变。这既是社会经济变迁的结果,也是个人选择和价值观的体现。虽然母亲仍然承担着更多的育儿责任,但父亲在家庭中的作用日益重要,共同构建着现代家庭的形象。

Your Website Is Not for You

网站并非为你们而设:设计决策的根本原则

本文探讨了网站设计过程中常见的冲突,以及如何以用户为中心进行决策。以下是文章的主要观点:

1. 网站的真正目的:

  • 网站并非为创始人、营销经理或董事会设计,而是为潜在客户、潜在客户、访问者和会员服务。
  • 决策者常常忘记这一点,因为他们对网站的投入(品牌、时间、心血)使其在他们眼中更像一件艺术品,而非工具。
  • 网站的本质是一个工具,其唯一任务是帮助用户完成他们访问网站的目的。其他元素都只是为了支持这个目的而存在。

2. 专家悖论:

  • 患者不会干涉外科医生的手术,因为他们信任医生的专业知识。
  • 然而,在网站设计中,情况恰恰相反:即使设计师提供了数周的研究、用户测试和竞争分析,决策者仍然会因为个人喜好(例如颜色)而否决设计。
  • 这种现象源于每个人都见过网站,因此都认为自己有资格重新设计网站。
  • 设计师通常会妥协,以维持合作关系,但这种妥协会导致网站逐渐偏离用户需求,最终成为领导团队的“心情板”,美观但功能性差。

3. 更好的提问方式:

  • 在设计评审中,在发表意见之前,应该问自己一个问题:“这是否能帮助用户,还是仅仅帮助我?”
  • 如果无法诚实回答,应该询问设计师研究结果,并认真倾听。
  • 设计师提供的答案(数据、原则、测试结果)是他们专业知识的体现,应该被重视。

总结:

网站不应被视为艺术品、愿望清单或个人品味的反影,而应被视为一个工具,并且这个工具是为用户而设计的。 决策者应以用户为中心,尊重设计师的专业知识,以确保网站能够有效地实现其目的。

Full-Text Search with DuckDB

鸭DB全文搜索快速入门 (DuckDB Full-Text Search Quick Tour)

发布日期:2026年4月29日

本文是作者对DuckDB系列文章的第二篇,是对之前“DuckDB小试牛刀”文章的补充。如果对DuckDB不熟悉,建议先阅读前一篇。

主要内容:

本文探讨了DuckDB的全文搜索 (FTS) 功能。作者拥有使用Elasticsearch和Postgres等其他FTS解决方案的经验,因此将分享DuckDB FTS的快速体验。

全文搜索基础知识:

  • FTS允许进行比SQL运算符(如=ilike或正则表达式)更全面和可配置的查询。
  • 查询分数可以通过算法(如Okapi BM25)进行调整。

DuckDB FTS的特性:

  • 索引选项:
    • Stemming (词干提取): 将单词简化为词根,处理一些词形变化(例如,walk, walks, walked, walking)。
    • Stop words (停用词): 移除常见的无意义词语,如“the”、“and”、“of”,以避免干扰结果。
    • Strip accents (移除变音符号): 将 "á"、"ä" 和 "a" 等符号标准化为 "a"。
  • 查询函数:
    • Okapi BM25参数:
      • k₁: 衡量词频的重要性(词频越高是否更重要?)。
      • b: 衡量文档长度的重要性(文档越长是否更重要?)。

现有DuckDB FTS的局限性:

  • 目前缺乏在源数据中高亮显示匹配查询项的功能。Postgres的 ts_headline 功能可以实现这一点。
  • 作者利用Snowball项目和Python snowballstemmer库解决了词干提取过程中遇到的问题。

设置:

  • DuckDB的FTS功能需要通过安装全文搜索扩展来启用。
  • 安装方法:在DuckDB会话中运行 INSTALL fts; LOAD fts;

实际应用示例:

作者使用Python和uv工具预处理了大量的.eml格式的邮件文件,将其转换为JSON格式,并导入到DuckDB数据库中。

  • 预处理流程:
    • 加载邮件文件。
    • 提取邮件正文内容。
    • 提取有用的头部信息 (例如日期、发件人、主题、收件人) 以过滤营销和事务邮件。
    • 将数据导出为JSON文件。
  • 数据库操作:
    • 使用 CREATE TABLE emails AS SELECT * FROM read_json('*.eml.json'); 创建表并导入数据。
    • 添加自增ID列 ALTER TABLE emails ADD COLUMN id INTEGER; UPDATE emails SET id = rowid;
    • 使用 PRAGMA create_fts_index('emails', 'id', 'subject', 'body'); 创建FTS索引。
  • 查询示例:
    • 基本查询:SELECT id, body, fts_main_emails.match_bm25(id, 'talk') AS score FROM emails WHERE list_unsubscribe = '' AND precedence NOT IN ('bulk', 'list', 'junk') AND score IS NOT NULL ORDER BY score DESC;
    • 使用conjunctive参数进行精确匹配查询。
    • 调整 bk₁ 参数来优化查询结果。

总结:

DuckDB的FTS功能虽然不如Postgres或Elasticsearch完善,但对于初步探索数据来说已经足够强大。如果需要更高级的功能,可以考虑将数据迁移到其他数据库。DuckDB快速搭建和使用的特点使其成为一个有吸引力的选择。

后续计划:

作者计划继续撰写DuckDB系列文章,下一篇可能探讨DuckDB的向量搜索功能。

Does Postgres Scale?

DBOS Postgres 基准测试:单机性能分析 (DBOS Postgres Benchmark: Single-Server Performance Analysis)

本文档总结了 DBOS 对 Postgres 单机性能的基准测试结果,旨在解答关于 Postgres 是否能够满足工作流执行系统需求的问题。测试重点关注 Postgres 的写入性能,因为工作流执行需要频繁地向数据库写入数据,包括输入、输出、以及步骤结果的检查点。

主要发现:

  • 高写入吞吐量: 单台 Postgres 服务器可以实现高达 144,000 次写入/秒,相当于每天 120 亿次写入。
  • 工作流处理能力: 单台服务器可以处理 43,000 个工作流/秒,相当于每天 40 亿个工作流。
  • 可扩展性: 这些结果表明,对于大多数用例,单台 Postgres 服务器已经足够。

测试环境:

  • AWS RDS db.m7i.24xlarge 实例
  • 96 vCPU
  • 384 GB RAM
  • 120K provisioned IOPS (io2 volume)

测试内容:

  1. 原始 Postgres 写入性能: 使用一个包含 UUIDv7 主键、文本数据字段和时间戳的三列表,通过大量异步 Python 客户端模拟写入,测试最大写入吞吐量。结果表明,可以实现 144,000 次写入/秒。
  2. 持久化工作流性能: 模拟无步骤的简单工作流,每个工作流包含开始和完成两个 Postgres 写入操作。测试结果显示,单台服务器可以处理 43,000 个工作流/秒。
  3. 持久化队列性能: 模拟使用 Postgres 队列,客户端将工作流入队,worker 节点从队列中取出并执行。每个工作流包含四个 Postgres 写入操作:入队、出队、启动和完成。测试结果显示,单台服务器可以处理 12,100 个队列工作流/秒。

性能瓶颈分析:

  • 原始写入和工作流: 瓶颈主要在于 Write-Ahead Log (WAL) 的刷新速度。Postgres 在写入数据前,会将写入描述添加到 WAL,然后将 WAL 刷新到磁盘,最后确认提交。
  • 持久化队列: 最初的瓶颈是 workflow_status 表的锁竞争,多个客户端同时尝试入队或出队,导致性能下降。通过使用多个队列(或分区)来缓解锁竞争,可以提高性能,最终将工作流吞吐量提高到 30,600 个工作流/秒。此时瓶颈再次转移到 WAL。

结论:

Postgres 的可扩展性令人印象深刻,能够支持高写入负载和大量工作流。对于大多数应用场景,单台 Postgres 服务器已经足够。如果需要更高的性能,可以通过分片到多台 Postgres 服务器来实现。DBOS 致力于简化和优化持久化工作流的开发和部署。

相关链接: