Lmiracle

本期摘要本期重点关注 PyPI 供应链安全连续告警——LiteLLM 与 telnyx 相继被植入恶意代码，警示开源依赖风险；OpenWrt 社区则围绕 25.12.x 升级路径与华为、MikroTik 等设备适配展开热烈讨论。 Linux 动态LiteLLM PyPI 包遭供应链攻击，信息窃取恶意软件曝光3 月 24 日，广泛使用的 LLM 网关库 LiteLLM 在 PyPI 上发布的版本被发现植入信息窃取恶意软件。攻击者通过污染上传流程将恶意代码混入正式包，波及大量依赖该库的 AI 基础设施项目。LWN 详细复盘了此次事件中多个环节失守的根本原因，包括发布流程缺乏签名校验与二次审核机制。 🔗 原文 telnyx PyPI 包被注入恶意代码，周下载量逾百万受波及SafeDep 研究人员发现，telnyx 4.87.1 与 4.87.2 两个版本于 3 月 27 日上传至 PyPI 时，telnyx/_client.py 已被注入恶意代码。该包周均下载量超过 100 万次，潜在影响范围极广。事件与 LiteLLM 攻击时间高度重叠，疑似同一攻击者或组织所为，建议所有使用者立即锁 ...

本期摘要本期亮点集中在两条主线：Fedora 完成协作平台迁移、LLM 辅助内核开发引发版权争议；OpenWrt 25.12.x 系列 bug 持续涌现，x86 平台”深度休眠”等疑难问题值得关注。芯片侧 eFPGA 作为 Intel 18A 时代的”硅保险”逻辑也颇具深意。 Linux 动态Fedora Forge 正式上线，Pagure 进入倒计时Fedora 基于 Forgejo 构建的新协作开发平台 Fedora Forge 已宣布全面投入使用，面向整个 Fedora 社区开放。这意味着已服役多年的自研平台 Pagure 将逐步退出历史舞台。Forgejo 作为 Gitea 的社区 fork，在功能与生态上更具活力，此次迁移标志着 Fedora 在开发工具链现代化上迈出关键一步。 🔗 原文 LLM “vibe coding” ext4：OpenBSD 案例引发版权与质量双重争议LWN 深度报道了一个颇具争议的项目——有人尝试用 LLM 为 OpenBSD 重新实现 ext4 文件系统，部分动机是绕开 Linux 内核代码的 copyleft 限制。这一事件将 LLM 生 ...

本期摘要本期核心看点：Linux 内核五版本同步更新、LibreQoS v2.0 正式发布带来更强的网络可观测性；OpenWrt 社区就 AI 生成内容政策展开讨论，与此同时 Google 将量子计算威胁（Q Day）预警时间线大幅提前至 2029 年，加密基础设施的迁移压力骤增。 Linux 动态五个稳定版内核同步发布Greg Kroah-Hartman 宣布同步发布 6.19.10、6.18.20、6.12.78、6.6.130 和 6.1.167 五个稳定版内核，各版本均包含针对整个代码树的重要修复。其中 6.6.x 和 6.1.x 属于长期支持（LTS）分支，对路由器及嵌入式设备的 OpenWrt 构建影响显著，建议相关用户尽快升级。 🔗 原文 LibreQoS v2.0 正式发布开源流量管理平台 LibreQoS 发布 2.0 大版本，重点优化了运维体验与日常网络可观测性，用户可在更细粒度层面观测全网流量状态、排查用户侧故障。此版本对 ISP 及有流量整形需求的 OpenWrt 用户尤具实用价值，配合 Linux 内核的 tc/eBPF 能力可大幅提升 QoS ...

本期摘要本期焦点：LiteLLM 供应链投毒事件敲响开源安全警钟，OpenWrt 25.12.1 多款设备出现 USB 与 WiFi 回归性缺陷；芯片侧 AI 基础设施加速落地，UALink 安全规范 IP 正式亮相，运营商资本开支向算力侧加速迁移。 Linux 动态LiteLLM PyPI 包遭投毒，SSH 密钥与云凭证面临泄露风险LiteLLM 1.82.8 被发现植入凭证窃取代码，可自动收集并外传 SSH 私钥、主流云服务凭证及加密钱包信息。该事件再次暴露 PyPI 供应链的安全脆弱性，所有曾安装该版本的用户应立即轮换相关密钥。 🔗 原文 zswap 与 zram 的本质差异：Chris Down 深度解析内核开发者 Chris Down 撰文澄清业界对 zswap 和 zram 的常见误解。两者虽同为压缩页面技术，但架构截然不同：zram 是块设备替代方案，zswap 则是传统 swap 的透明压缩前端，两者在内存压力响应策略和回收路径上均有显著差异，运维人员应根据负载特征选型。 🔗 原文 Firefox 149.0 发布，引入分屏浏览与内置 VPNFirefox ...

本期摘要Linux 7.0-rc5 发布，内核进入稳定收尾期；FCC 将外国消费级路由器列入禁止授权清单，引发路由器行业重大政策震荡；Open RAN 能耗研究与 MWC 2026 Wi-Fi 路线图共同勾勒出下一代无线网络的演进方向。 Linux 动态Linux 7.0-rc5 发布Linus Torvalds 发布了 7.0-rc5 预发布版本，本轮 RC 补丁量较前几个版本有所收窄，但相比历史同期 rc5 仍偏大。Linus 表示”情况开始平稳下来”，主线合并窗口后的修复工作正逐步走向尾声，正式版发布可期。 🔗 原文 BPF 程序睡眠上下文追踪新方案开发者 Puranjay Mohan 提交补丁集，拟允许 BPF 程序在可睡眠上下文中临时获取锁，同时进入原子（atomic）上下文。当前内核严格禁止可睡眠 BPF 程序进入原子区；此补丁若合入，将大幅拓宽 BPF 在内核中的应用边界，也对 eBPF 网络程序的设计产生影响。 🔗 原文 稳定版内核 6.19.9 与 6.18.19 发布Greg Kroah-Hartman 同步发布两个稳定分支更新，包含树内多处重要修复。两 ...

背景在无线组网场景下，STA（客户端/下级节点）需要通过 WPS 完成入网，并自动判断上级 AP 是否支持 EasyMesh。若支持，则走 Multi-AP 组网流程成为 Mesh Agent；若不支持，则降级为普通桥接模式。本文基于一份真实的 pcapng 抓包，完整分析 WPS 握手过程、EasyMesh 探测机制。 一、WPS M1–M8 完整握手流程WPS 握手分两个阶段：M1–M4 完成密钥协商与身份验证，M5–M8 完成凭证传递。 消息字段详解 消息 方向 关键字段 M1 STA → AP Version, UUID-E, MAC, EnrolleeNonce, Public Key (DH), Auth Type Flags, Encr Type Flags, Multi-AP Extension (0x1048, 若支持 EasyMesh) M2 AP → STA RegistrarNonce, Public Key (DH), EncrSettings, Multi-AP Extension (回应 EasyMesh, 若支持) M3 S ...

简介本博客基于 Hexo 搭建，使用 Butterfly 主题，部署在 GitHub Pages 上。Hexo 是一款快速、简洁且高效的静态博客框架，使用 Markdown 写作，一键生成静态页面，非常适合技术博客。 本文记录从零搭建到日常使用的完整流程。 环境准备依赖 Node.js >= 18 Git 安装 Hexo CLI12345# 全局安装（需要权限）sudo npm install -g hexo-cli# 验证hexo --version 初始化博客123hexo init my-blogcd my-blognpm install 目录结构如下： 12345678my-blog/├── _config.yml # 站点主配置├── package.json├── scaffolds/ # 文章模板├── source/│ └── _posts/ # 博客文章├── themes/ # 主题└── public/ # 生成的静态文件（自动生成） 安装 B ...

mqtt broker简介和选型MQTT Broker（mqtt代理服务器），负责管理和转发消息，关于细节不在赘述。关于broker选型，需要考虑使用场景、性能、易用性和支撑的特性等。 目前主流的mqtt broker有mosquitto、EMQX、HiveMQ、VerneMQ、Amazon AWS IoT Core等，由于需要跑在RTOS上，只需要简单转发消息即可，故选择mosquitto。 移植过程中需要考虑的问题 问题1，根据使用场景，优先裁剪config文件 问题2，仅保留mosquitto原文件和调用lib文件，删除多余app、test等文件 问题3，解决类型匹配，RTOS中头文件类型可能有冲突 问题3，由于mosquitto只支持用epoll和poll机制，而ECOS只支持select，故使用select分装poll函数 问题4，mosquitto是配置文件的方式传入配置信息，考虑配置文件加载 问题6，mosquitto中存在信号机制，考虑相关RTOS是否支持信号 移植梳理每个目录，修改删除不必要的文件，如：test、doc、docker等目录。顶层Make只需要编译sr ...

背景工作中经常遇到驱动相关问题，之前对驱动开发也是现学现买。准备系统接触linux驱动驱动和kernel，刚开始主要熟悉linxu驱动框架，不涉及相关硬件（后续可能回学习ARM或RISC-V）。打算在自己的主机上编译kernel模块，直接调试加载。 环境 ununtu 24.04 kernel版本 12$ uname -r6.8.0-31-generic 源码和分析第一个简单的驱动以hello.c命令，代码中只有module init和module exit. 1234567891011121314151617181920#include <linux/module.h>#include <linux/cdev.h>int hello_init(void){ printk("hello world! init.\n"); return 0;}void hello_exit(void){ printk("hello world! exit.\n"); return;& ...

netif_receive_skb简介netif_receive_skb作用： 把接收帧传给每个协议分流器 把接收帧传给skb->protocol所关联的L3协议处理函数。 负责L2必须的功能处理 如果某接收帧数据没有关联skb->protocol，而且L2没有处理该帧，kernel不知道如何处理该帧数据，会将起丢弃。 skb->protocol：一般由驱动接收程序赋值，从L2层设备驱动程序的角度看，就是用在下一个较高层的协议。如：IP、IPv6以及ARP等；值在include/linux/if_ether.h中。由于每种协议都有对应的处理函数，因此驱动程序使用该字段告诉上层程序对应协议。 netif_receive_skb() 是主要的接收数据处理函数。它总是成功。 缓冲区可能会在拥塞控制处理期间或被协议层丢弃。此函数只能从软中断上下文调用，并且应启用中断。 如果桥接代码或者入口流量控制没有处理该帧数据，则该帧会传给L3协议处理函数（通常每种协议只有一个处理函数，但是也可以注册多个）。 至此，接收部分已经完成。 L3对封包的处理： 传递 ...