SecretSpec 0.15 发布：Provider credentials、Azure Key Vault、Gopass 和 PHP SDK 一次补齐

SecretSpec 0.15 这次更新的分量不小，因为它不是只加一个 provider，而是把凭证引导、云密钥库、密码存储和多语言接入几条线一起往前推。最核心的新能力是 provider credentials：现在一个 secret provider 的认证信息可以安全地存放在另一个 provider 里，由 SecretSpec 在内存里取用，而不是先把凭证暴露到应用环境变量。这对多环境、多账户、要做最小暴露面的团队来说，是很实打实的一步。

围绕这套能力，0.15 同时把 Azure Key Vault、Gopass 和 PHP SDK 接进来了：前者补上 service principal、Azure CLI、managed identity、AKS workload identity 等认证路径；后者让 GPG 加密、git 同步的密码库进入统一解析链；PHP 侧则开始能把同一个 Rust resolver 复用到 PHP-FPM、Laravel、Symfony 和 CLI 应用里。再加上 secretspec export、AWS Secrets Manager 创建 guardrails、provider chain 和 profile override 的一批修补，这更像一次平台层面的扩展，而不是普通的小版本迭代。

如果你把 Rust 看成“拿来做一套跨环境 secrets control plane”的底层语言，SecretSpec 这次更新很能说明它的野心：不是只做一个 CLI，而是在持续把配置、认证、审计、多 SDK 和 provider 生态拼成一整套可运营的秘密管理系统。

原文链接：https://secretspec.dev/blog/secretspec-0-15-provider-credentials-azure-key-vault-gopass-and-php-sdk/

ctt 0.5.0：把 GPU 压缩纹理制作、mipmap 和多编码器接口统一进一套 Rust 工具链

ctt 的价值，在于它不是又一个只服务某种纹理格式的小工具，而是试图把 GPU 压缩纹理制作 这件一直很碎的工程活，系统地收进一套 Rust 库 + CLI 里。作者把 bc7enc-rdo、Intel ISPC Texture Compressor、etcpak、AMD Compressonator、astcenc 这些现成编码器统一在同一个接口后面，再把 mipmap 生成、色彩空间、alpha 处理、容器输出（KTX2 / DDS） 一起接好，等于把“素材进来、压缩纹理出去”的流水线一次理顺。

从 README 和作者的 Reddit 说明看，这个项目不是纸上谈兵。它已经支持 BCn、ETC/EAC、ASTC 等多类格式，还能根据格式自动挑优先编码器，也允许显式指定某个后端。CLI 层面又把线程数、supercompression、cubemap、2D array、volume texture 这些生产里真的会遇到的参数都补齐了。对做游戏引擎、实时渲染或工具链的人来说，这种项目最吸引人的地方不是“会压缩”，而是 终于有人把跨平台压缩纹理流程做成可复用的标准件。

作者还提到它已经被 Bevy 和 Esoterica 引擎方向的工作使用，这点也挺关键：说明它不是只停在一个技术展示仓库，而是在往可落地的生态部件走。Rust 在图形工具链里一直缺少这种“脏活累活有人认真整理”的项目，ctt 这次算是补上了一个很实用的坑位。

原文链接：https://github.com/cwfitzgerald/ctt

pg_otel：把 PostgreSQL 慢查询计划直接导成 OpenTelemetry traces 的 Rust 插件

pg_otel 这类项目的看点不在“它是 Rust 写的”，而在它试图把很多系统里原本断掉的一段可观测性补上：应用侧 trace 能看到 HTTP、RPC、队列，但一到数据库内部，通常只剩慢查询日志或零散指标。这个插件走的路线是：挂到 PostgreSQL executor 的 start / end hook 上，拿到查询计划和 instrumentation 数据，再把结果作为 OpenTelemetry spans 送出去，让 trace 不再停在数据库调用的边界上。

从仓库说明看，作者做得还挺务实：它默认会参考 log_min_duration_statement，只为超过阈值的查询生成 spans，避免把 trace 系统直接打爆；导出部分则交给后台 worker 做，尽量减轻查询线程本身的负担。再加上 traceparent 可以通过 GUC 或 SQL comment 传进来，应用侧和数据库侧的链路就有机会真正串起来。

这项目显然还早，像队列长度、span 名称和 query 文本截断都还有硬编码限制，但方向挺明确：Rust + pgrx 已经不只是“能写 Postgres 扩展”，而是在开始切入数据库观测和诊断这类更靠近生产一线的场景。如果后面继续补稳定性和配置面，这条线很可能会被不少做平台工程的人盯上。

原文链接：https://github.com/w1ll-i-code/pg_otel

no_std for Wgpu & Winit：wasm32v1-none 跑通示例，WebGPU 的无标准库路线往前挪了一步

这条分享最有意思的地方，不是“有人搞 no_std”本身，而是作者把目标对准了 Wgpu + Winit 这样更偏应用层的基础设施，并且已经给出一个实际可跑的 wasm32v1-none 示例仓库。按照作者在 Reddit 的说明，这套 demo 基本直接沿用官方 wgpu_examples，改动并不激进，主要是把环境切到了 Winit 0.31 加上一组补丁，来证明 no_std WebGPU 应用 不是停留在概念层面。

这背后真正值得关注的是生态信号。no_std 过去更多停留在嵌入式、底层 crate 或小范围实验里，但如果 Wgpu / Winit 这类图形和窗口基础设施也能逐步打开这条路，那么像 wasm32v1-none 这种更受限、更可控的目标环境就会变得更现实。作者还提到自己和其他人已经在这件事上折腾了很久，现在终于看到“隧道尽头的光”，这也说明相关工作并不是一次性的玩票 demo。

对关心 WebAssembly、图形基础设施或者 Rust no_std 边界的人来说，这条线暂时还谈不上成熟，但它已经足够证明：Wgpu / Winit 这类重量级生态组件，开始有人认真往 no_std 能跑的方向推了。

原文链接：https://github.com/bushrat011899/wasm32v1-none-wgpu-example