最新

我为我和我的团队构建了一个可自托管的基于网页的 SQL 客户端接口。<p>我们之前使用的是 DBeaver 的社区版，但我们需要更多的功能和改进的编辑器。PopSQL 是一个现代化的基于网页的 SQL 编辑器，但它不符合我们现有的基础设施安全设置。<p>我们需要：<p>- 单点登录（SSO）<p>- 审计日志<p>- 现代编辑器（类似于 <a href="https://www.pgcli.com/" rel="nofollow">https://www.pgcli.com/</a> 的提示）<p>- 可共享查询<p>- 查询解释（嵌入 <a href="https://explain.dalibo.com/" rel="nofollow">https://explain.dalibo.com/</a>）<p>- 将查询作为 API 服务<p>- 架构探索（嵌入 <a href="https://dbdiagram.io/" rel="nofollow">https://dbdiagram.io/</a>）<p>- 固定客户端 IP<p>在 Copilot + GPT-5.5 + GPT-5.4 的帮助下，我能够构建这个工具，并且已经在内部使用了几个月。目前，它仅支持 PostgreSQL 和 ClickHouse。<p>未来计划：<p>- 定时查询<p>- 查询管道和工作流<p>- 可嵌入的仪表板构建器<p>- 边缘 AI 助手——用于查询解释和生成的浏览器本地 LLM<p>- 更多数据库驱动程序——SQLite、Duckdb、Redis<p>请随意分叉、扩展，并使其适应您的使用案例。

我知道 Git 并不是为了像 GitHub 这样运作而设计的，而伪造问题也是多年来一直存在的老问题。对于 Shai Hulud 和 AI Agent，这次情况有些严重，因为如果没有启用警惕模式（Vigilant Mode）并且没有注册 GPG 密钥，提交验证也可能被伪造。 我理解平台和 Git 本身存在一些限制，但设计决策和设计缺陷是完全不同的事情。面对令人沮丧的漏洞奖励报告被驳回，以及 MSRC 将提交验证作为缓解措施的讽刺性品牌，我已经等了很久才在这里发帖。 GitHub 显然有机会通过与平台认证令牌和用户注册邮箱关联来进行验证，但他们选择不这样做。更具讽刺意味的是，当我等待对此问题的更多关注时，GitHub 被黑客攻击，这种联系真是无价之宝。 以下是正式的内容： --------------------------------------------------- GitHub 自己的文档建立了一系列信任假设，按照逻辑推导，揭示了一个无法审计、无法程序化检测的验证漏洞，任何拥有免费账户的 GitHub 用户都可以利用。 文档中的链条： 1. GitHub 文档指出，提交签名验证让其他人“可以确信这些更改来自可信来源”： https://docs.github.com/en/authentication/managing-commit-signature-verification 2. 验证检查提交是否使用注册到 GitHub 账户的 GPG/SSH 密钥签名： https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification 3. Git 每个提交有两个身份字段：作者（编写代码的人）和提交者（应用代码的人）。这两个字段可以通过环境变量自由设置——GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL： https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables 4. GitHub 的用户界面显著显示作者。提交者则隐藏在二次点击之后。绿色的“已验证”徽章位于作者的名字和头像旁边。 5. GitHub 的验证仅绑定于提交者的密钥。作者字段没有经过验证、没有被验证，也没有受到限制。API 直接暴露这一点——作者、提交者和验证是每个提交上的独立对象： https://docs.github.com/en/rest/git/commits 逻辑缺陷： 徽章在作者的名字旁边显示“已验证”——但它验证的是提交者的密钥。这两者可以是完全不同的人。GitHub 自己的 API 确认了这一点：一个提交可以返回 author=torvalds，committer=<ANYONE>，verification.verified=true。用户界面显示 Linus Torvalds 旁边有一个绿色的勾号。签名密钥是我的。 这并不是加密中的错误。GPG 签名是有效的。缺陷在于“已验证”所传达的信息与实际检查的内容之间的差异。 GitHub 知道这一点——并将防御措施设置在受害者的后面： GitHub 实际上有一个“部分验证”徽章状态。当作者与提交者不相等且作者启用了警惕模式时会触发： https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits 这意味着 GitHub 意识到作者与提交者不匹配是一个信任问题。但该防御措施是选择性启用的，默认关闭，并且依赖于被冒充用户的账户设置——而不是攻击者的。攻击者通过选择未启用警惕模式的受害者来控制防御措施是否生效。Linus Torvalds 没有启用，绝大多数 GitHub 用户也没有。