跳转至内容
  • 0 赞同
    1 帖子
    8 浏览
    R
    终端模拟器 Ghostty 的创始人 Mitchell Hashimoto(HashiCorp 联合创始人、GitHub 用户 #1299)4 月 28 日发文宣布,Ghostty 项目将迁出 GitHub,原因是该平台近一个月来几乎每天都发生影响其工作的故障。Hashimoto 在文中描述了自己与 GitHub 长达 18 年、几乎每天登录的深厚羁绊,并坦言"写这篇文章让我感到一种不理性的悲伤"——他在 GitHub 上发起了人生中第一个成功的开源项目 Vagrant,彼时的梦想职业也是加入 GitHub。他过去一个月专门记录了日记,为每次 GitHub 故障影响工作的日期打"X",结果几乎每天都有 X。发文当日,GitHub Actions 发生故障导致他约两小时无法进行任何 PR 审查,而这仅是 4 月 27 日更大规模 Elasticsearch 宕机之外的另一次独立故障。他明确表示:“这里不再是严肃工作的场所,如果它每天都能把你挡在门外好几个小时。” 迁移计划正在推进中:Hashimoto 称已与多家供应商(包括商业平台和开源方案)进行讨论,将以渐进方式剥离对 GitHub 的依赖,现有仓库地址将保留为只读镜像。Ghostty 目前在 GitHub 上拥有 27.8k star、约 1700 个公开 issue,是近年增长最快的终端模拟器项目之一,核心功能特性包括基于 Zig 编写、GPU 加速渲染、原生跨平台 UI 与内置 Kitty 图形协议支持。此番迁移的直接触发点是 GitHub 持续不稳定的基础设施,但 Hashimoto 也承认这一决定筹谋已久,并非仅因单次故障一时冲动——他的个人项目仍将留在 GitHub,Ghostty 因对平台基础设施依赖最深、社区影响最大,成为迁移的优先对象。 Mitchell Hashimoto | GitHub - ghostty-org/ghostty https://mitchellh.com/writing/ghostty-leaving-github https://github.com/ghostty-org/ghostty
  • 0 赞同
    1 帖子
    9 浏览
    R
    GitHub 4 月 28 日 14:17 UTC 起报告 Pull Request 性能下降,14:51 UTC 进一步定位为 /pulls 与 /repo/pulls 页面未能列出全部已索引的 PR——根因是 Elasticsearch 集群当前未包含全部已索引文档,是 4 月 27 日另一起事故的连带影响。GitHub 强调没有 PR 数据丢失:随着 PR 被更新会自动重新索引,同时官方已加速触发全量 reindex。事故对依赖 Elasticsearch 的网页与部分 API 影响较大;不依赖 Elasticsearch 的接口——包括 GitHub CLI 命令 gh pr list 与 REST API /repos/{owner}/{repo}/pulls——不受影响,可作为期间获取 PR 数据的临时手段。 事故时间线如下:14:17 UTC 启动调查;15:58 UTC 团队采取"以正确性优先、避免进一步影响"的稳妥重建策略;21:43 UTC 通报 reindex 仍在进行;22:46 UTC 部分受影响仓库的 PR 列表通过临时缓解措施恢复可用;4 月 29 日 00:40 UTC 起进入 mitigation in progress 阶段,预计 24 小时内全量恢复受影响仓库的 PR 列表。该事故被官方分级为 Minor,但开发者侧反馈较为强烈——多名 Hacker News 用户报告 PR 列表完全不显示或缺失大量条目,部分依赖 PR 列表做 CI 检查或合规审计的工作流被阻塞。 GitHub Status | IsDown 事故页 | Hacker News 讨论 https://news.ycombinator.com/item?id=47939579
  • 0 赞同
    1 帖子
    4 浏览
    R
    GitHub.com 与 GitHub Enterprise Server 被披露存在高危远程代码执行漏洞 CVE-2026-3854(CVSS 8.7),Wiz 安全研究团队 3 月 4 日上报,GitHub 在 2 小时内向 GitHub.com 部署修复,Enterprise Server 修复版本为 3.14.25、3.15.20、3.16.16、3.17.13、3.18.8、3.19.4、3.20.0 及以上。漏洞根因是 git push 操作时用户提供的 push option 值未经过滤即被拼接进 GitHub 内部 X-Stat 头部,而该内部头部使用分号作为分隔符——同样可出现在用户输入中——攻击者由此能注入额外的元数据字段。Wiz 描述利用链由三段注入串成:先注入非生产环境的 rails_env 绕过沙箱,再注入 custom_hooks_dir 重定向 hook 目录,最后通过 repo_pre_receive_hooks 配合路径遍历以 git 用户身份执行任意命令。任何对仓库具备 push 权限的认证用户均可触发。 漏洞影响范围远超表面:在 GitHub.com 的多租户架构下,攻击者一旦在共享存储节点上获得代码执行,即可跨租户读取数百万仓库的内容,与组织或用户归属无关。Wiz 描述其"利用难度极低",公开披露时仍有约 88% 的 Enterprise Server 实例处于易受攻击状态。GitHub.com 看似多了一道"Enterprise 模式标志为 false 时 custom hooks 路径不激活"的保护,但该标志同样通过 X-Stat 头部传递、可被同一注入手法覆写,因此 SaaS 实例同样可被攻陷。GitHub 首席信息安全官 Alexis Wales 在官方博客确认尚未发现该漏洞被恶意利用的证据,并强调该事件再次提醒"使用不同语言开发的多个内部服务通过共享内部协议传递数据时,每个服务对数据格式的隐含假设本身就是关键攻击面"。Wiz 建议所有运营多服务架构的团队系统性审计用户可控输入在内部协议中的流动路径,尤其是当安全相关配置直接派生自共享数据格式时。 The Hacker News | GitHub Blog | Wiz | SecurityWeek | NVD https://thehackernews.com/2026/04/researchers-discover-critical-github.html https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/ https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854 https://www.securityweek.com/critical-github-vulnerability-exposed-millions-of-repositories/
  • 0 赞同
    1 帖子
    9 浏览
    R
    GitHub 于 4 月 27 日宣布,全线 Copilot 套餐将于 2026 年 6 月 1 日起从现有的”高级请求单元(PRU)“计费模式切换至基于 token 消耗的”GitHub AI Credits”体系,输入、输出与缓存 token 均按各模型公开 API 费率折算扣除。套餐月费不变——Pro 10 美元、Pro+ 39 美元、Business 19 美元/用户、Enterprise 39 美元/用户,每月订阅费折算为等额 AI Credits 随套餐附赠;代码补全与 Next Edit Suggestions 两项功能不消耗 Credits,继续包含在所有套餐中。年付 Pro/Pro+ 用户维持现行模式至到期,但 6 月 1 日起模型倍率系数将提升;到期后自动降为 Copilot Free,可选择升级至月付套餐并获得按比例折算的剩余价值 Credits。为缓冲企业侧过渡压力,Business 与 Enterprise 月付客户将在 6 月、7 月、8 月分别获得 30 美元与 70 美元的额外赠送 Credits,并引入跨组织的 Credits 共享池机制,避免单个席位的剩余额度闲置浪费。 GitHub 首席产品官 Mario Rodriguez 在公告中解释,Copilot 已从编辑器内嵌助手演变为可跨仓库运行数小时多步骤 Agent 任务的平台,现有模式下一次快问与一次多小时自主编码会话对用户成本完全相同,GitHub 长期自行承担了差额推理费用,“PRU 模式已不可持续”。此次调整同期宣布取消 PRU 耗尽后的降级回退体验,改由管理员在企业、成本中心、用户三个层级设置预算上限,超出 Credits 池后可选择允许按费率继续使用或直接封顶。5 月初将上线”预览账单”功能,用户可在 Billing Overview 页提前查看 6 月起的预估费用。Copilot 代码审查同时宣布将额外消耗 GitHub Actions 分钟数(详见此前 Changelog 公告)。 GitHub Blog https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
  • 0 赞同
    1 帖子
    11 浏览
    R
    Git 2.54 于 4 月 20 日正式发布,来自 137 名贡献者(66 名首次参与)的提交合并进入这一版本,同时覆盖 2.53 的新特性。最大亮点是新增实验性命令 git history,提供 reword 与 split 两个子命令:git history reword <commit> 可直接在编辑器中修改任意历史提交的提交信息,并自动更新所有下游分支,全程不触碰工作区或暂存区,甚至支持裸仓库;git history split <commit> 则以类似 git add -p 的交互界面将一个提交拆分成两个,自动重写后代分支——该命令底层基于 git replay 的核心库,有意不支持含 merge commit 的历史、也不允许产生冲突,定位为"精准、非交互式历史改写"而非 rebase -i 的替代。另一重要特性是配置文件定义钩子:不再要求把脚本放入 .git/hooks/ 目录,可直接在 ~/.gitconfig 或系统级配置中以 [hook "name"] event = pre-commit 的形式声明钩子,多个钩子可绑定同一事件并按顺序执行,支持通过 hook.<n>.enabled = false 单独禁用,git hook list 可查看来源。 功能更新层面,git maintenance run 的默认维护策略由 gc 切换为 2.52 引入的 geometric——后者通过增量合并满足几何级数关系的 packfile,避免昂贵的全量 GC,同时保持 commit-graph 与 reflog 最新;git replay 新增原子引用更新(不再向 stdout 打印 update-ref 命令)、--revert 模式与根提交支持;git log -L 路由经标准 diff 管线,首次与 -S、-G、--word-diff、--color-moved 兼容;HTTP 传输新增 429 重试机制,支持 Retry-After 头与 http.retryAfter、http.maxRetries、http.maxRetryTime 配置;git rebase 新增 --trailer 选项可批量为所有被 rebase 的提交附加 trailer;git blame 支持 --diff-algorithm 参数;alias 命令名限制从 ASCII 字母数字放开至任意字符(通过 subsection 语法),使 “状態” 或 “hämta” 这样的本地语言别名成为可能;此外 MIDX 增量索引新增 compaction 支持,为长期运行的大型仓库提供更可持续的多层压缩。 GitHub Blog https://github.blog/open-source/git/highlights-from-git-2-54/
  • 0 赞同
    1 帖子
    6 浏览
    R
    GitHub 于 4 月 27 日发布公告,Copilot 代码审查功能将于 2026 年 6 月 1 日起在计费方式上发生变化:此前仅消耗 Copilot 高级请求单元(PRU),此后将同时以两种方式计费——其一,纳入新版基于用量的 AI Credits 计费模型;其二,每次在私有仓库运行代码审查,将从账户或组织现有的 GitHub Actions 分钟额度中扣减,超出包含分钟数的部分按 Actions 标准费率收费。公共仓库不受影响,Actions 分钟继续免费。此变化适用于 Copilot Pro、Pro+、Business 及 Enterprise 全部付费档位,包括通过"直接组织计费"为无授权用户触发的代码审查。 该变化的背景是 GitHub 上月披露 Copilot 代码审查已迁移至 Agent 工具调用架构,可跨仓库拉取更广泛的代码上下文、给出更相关的 PR 反馈,而该架构运行在 GitHub-hosted runners 上,天然产生 Actions 计算成本。GitHub 建议用户在 6 月 1 日前检查当前 Actions 用量与预算上限,并通过 Copilot 用量指标、Actions 指标和账单报告持续监控;如使用 self-hosted runners 或更大规格 runner,费率另行计算。 GitHub Changelog https://github.blog/changelog/2026-04-27-github-copilot-code-review-will-start-consuming-github-actions-minutes-on-june-1-2026/
  • 0 赞同
    1 帖子
    11 浏览
    R
    OpenAI 在 GitHub 仓库正式开源名为 monitorability-evals 的评估框架,旨在量化 AI 模型在实际运行中的“可监控性”。该框架包含一系列基准测试工具,通过模拟多种复杂场景,评估模型生成的输出是否易于被现有安全工具和监控系统识别与审计。OpenAI 官方表示,此举是为了帮助开发者在部署大型语言模型(LLM)时,能够更准确地捕捉潜在风险并提高系统的透明度。 背景上,随着 AI 模型能力的增强,如何有效监管模型的隐蔽偏差和非预期行为成为业界难题。monitorability-evals 提供的评估维度涵盖了文本特征、逻辑一致性以及对特定监控协议的依从性,为构建更安全的 AI 应用提供了标准化衡量尺度。目前,该项目已开放社区贡献,GitHub 页面显示其支持多种主流模型评估流程,有望成为 AI 安全工程领域的重要参考标准。 GitHub