Homebrew 官方 Tap 包接收策略详解收录标准、Notability 门槛与源码级审计机制【免费下载链接】brew The Package Manager for Everywhere项目地址: https://gitcode.com/GitHub_Trending/br/brewHomebrew 官方仓库homebrew/core与homebrew/cask并非“来者不拒”的软件注册表其 Package Acceptance Policy 定义了 formula 与 cask 共用的收录基线公共存在性与维护状态、Notability 量化门槛、fork 替换规则、内容合规与项目风险条款等。本文以该策略文档为主体结合brew audit背后的源码实现shared_audits.rb完整解读每项标准的判定逻辑、可程序化执行的部分是如何自动化的以及仓库专属政策如何与之衔接帮助提交者在动手写 formula/cask 之前准确预判自己的软件能否被官方 Tap 接受。策略定位formula 与 cask 共用的收录基线Homebrew 的官方 Tap 是homebrew/coreformula从源码构建的开源命令行软件与库和homebrew/caskcask上游发布的预构建应用与二进制两个仓库。接收策略的文档开头明确了三者关系共用部分Package-Acceptance-Policy.md 包含 formulae 和 casks 共享的接受标准即本文主体仓库专属部分homebrew/core的平台、许可证、构建要求等保留在 Acceptable-Formulae 中cask 的渠道、平台兼容性、试用版规则等保留在 Acceptable Casks 中两者均声明“shared package acceptance policy also applies”共享策略同样适用上游开发者视角Working with Homebrew as an Upstream Project 面向软件上游作者补充如何让自己的项目更容易被打包收录。这种“共用基线 仓库细则”的分层结构意味着提交者在评估收录可能性时必须同时满足两层标准先过共享策略的门槛如 Notability再过目标仓库的专属要求如 formula 必须能从源码构建、cask 必须通过 Gatekeeper 检查。适用范围与第三方 Tap不达标的软件去哪里策略文档的“Scope and third-party taps”一节给出了核心边界Homebrew 的官方仓库只接受项目能够**验证verify、维护maintain并支持support**面向广泛用户群使用的软件。不满足官方标准的软件通常可以在第三方 Tap中维护。这里有两个关键事实官方 Tap 是精选curated而非开放注册。从源码结构看Homebrew/brew通过 official_taps.rb 维护官方 Tap 的白名单机制其中还列出了DEPRECATED_OFFICIAL_TAPS已弃用列表Tap 的信任级别直接影响其软件是否被默认信任执行——第三方 Tap 属于“可执行代码而非纯元数据”默认需要显式brew trust才能加载。分发不等于背书。文档明确写道通过第三方 Tap 分发“does not imply Homebrew endorsement or support”不代表 Homebrew 的推荐或支持。这对用户是安全提示对开发者则意味着软件被拒收官方仓库后转入第三方 Tap是一条合法且常见的退路但不应在软件自身宣传中暗示官方身份。公共存在性与维护状态收录前提的四条硬指标“Public presence and maintenance”一节要求软件同时满足以下四点任何一条缺失都会直接导致不符合资格要求具体含义独立于 Homebrew 的公共存在软件必须有独立于 Homebrew 的公共存在public presence且homepage能解释这个项目上游积极维护上游必须处于活跃维护状态无已知未修复安全漏洞软件不能有已知且未修补的安全漏洞known unpatched security vulnerabilities实际可支持软件对 Homebrew 而言必须仍具实际支持价值文档同时给出两条明确的一票否决已停止维护的软件discontinued software不符合资格依赖 Homebrew 专属补丁来弥补上游不维护的软件不符合资格——即不允许用“社区打补丁续命”的方式收录上游已死的项目。Notability量化知名度门槛及其源码实现这是整份策略中最具可操作性、也是唯一被brew audit --online程序化执行的部分。文档规定新包必须证明“存在超出作者本人的公共兴趣”public interest beyond its author。对 GitHub 项目满足以下任一阈值即可提交类型forkswatchersstars普通提交他人代提交≥ 30≥ 30≥ 75自提交仓库所有者本人提交≥ 90≥ 90≥ 225注意三个判定细节三项指标是**“或”关系**满足其一即可而非全部自提交门槛恰好是普通门槛的3 倍指标统计对象是规范上游仓库canonical upstream repository而不是未经背书的镜像或代码托管平台的 fork创建不满 30 天的代码仓库通常不符合资格“less than 30 days old is normally not eligible”。对于托管在其他平台GitLab、Bitbucket 等的软件文档表述为“Equivalent public evidence may be considered”——可考虑等效的公共证据。此外文档保留了一句弹性条款“Repository-specific exceptions may apply when these metrics do not represent the softwares actual use or maintenance prospects”当指标不能代表软件实际使用情况或维护前景时仓库专属例外可以适用。源码印证Notability 如何被brew audit自动检查上述每一条政策文字都能在 shared_audits.rb 中找到对应实现。阈值常量与 3 倍自提交系数。文件开头L11-L15定义了各平台基线SELF_SUBMISSION_THRESHOLD_MULTIPLIER 3 GITHUB_NOTABILITY_THRESHOLDS T.let({ forks: 30, watchers: 30, stars: 75 }.freeze, ...) GITLAB_NOTABILITY_THRESHOLDS T.let({ forks: 30, stars: 75 }.freeze, ...) BITBUCKET_NOTABILITY_THRESHOLDS T.let({ forks: 30, watchers: 75 }.freeze, ...) FORGEJO_NOTABILITY_THRESHOLDS T.let({ forks: 30, watchers: 30, stars: 75 }.freeze, ...)可以看到 GitHub 与策略文档完全一致30/30/75而 GitLab 只统计 forks 与 stars无 watchers 概念、Bitbucket 只统计 forks 与 watchers——这正是文档所说“等效公共证据”的落地不同托管平台按各自可用的指标做同等级别的判定。自提交识别与 3 倍系数。self_submission? 通过比较 Pull Request 作者与仓库所有者大小写不敏感来判定“自提交”notability_thresholds_for 则对自提交将所有阈值乘以SELF_SUBMISSION_THRESHOLD_MULTIPLIER即 3得到文档中的 90/90/225def self.notability_thresholds_for(thresholds, self_submission) return thresholds unless self_submission thresholds.transform_values { |value| value * SELF_SUBMISSION_THRESHOLD_MULTIPLIER } end判定逻辑是“或”关系且拒绝 fork 与非规范仓库。以 GitHub 的 github 审计方法 为例return GitHub fork (not canonical repository) if metadata[fork] # ... if (metadata[forks_count] notability_thresholds.fetch(:forks)) (metadata[subscribers_count] notability_thresholds.fetch(:watchers)) (metadata[stargazers_count] notability_thresholds.fetch(:stars)) return #{notability_prefix} (30 forks, 30 watchers and 75 stars) end三个指标同时低于阈值才告警即任一达标即通过与文档的“或”语义一致对 fork 仓库直接返回“not canonical repository”对应文档“指标适用于规范上游仓库而非 fork”的规定。30 天仓库年龄规则。紧随其后的是年龄检查L367-L370age_days (Date.today - Date.parse(metadata[created_at])).to_i return if age_days 30 GitHub repository too new (#{age_days} days old, 30 days required)GitLabL373-L397、BitbucketL399-L438另额外拒绝已弃用的 Mercurial 仓库、ForgejoL440-L465四个实现结构一致均以created_at/created_on字段计算天数并要求 ≥ 30。调用入口与例外机制。这些审计由 formula_auditor.rb 在brew audit流程中调用SharedAudits.github(user, repo, self_submission:)。而文档中“Repository-specific exceptions may apply”的弹性条款对应的技术机制是各处广泛出现的formula.tap.audit_exception(...)调用如 formula_auditor.rb L332 的许可证豁免、L645 的证书错误豁免——Tap 维护者可以在 Tap 配置中对特定包声明豁免项这正是“仓库专属例外”在工程上的实现方式。需要说明的是Notability 审计属于--online联网审计会实际请求各托管平台 API 获取仓库元数据因此本地离线运行brew audit时不会触发这些检查。Discoverability 与 Searchability官方仓库不做推荐服务“Discoverability and searchability”一节为官方仓库划定了功能边界不做编辑推荐。官方仓库“not editorial curation or recommendation services”不是编辑策展或推荐服务分类、推荐、发现新软件的编辑合集都在其范围之外定位是“让已知软件容易安装”make known software straightforward to install——前提是用户已经知道这个软件可搜索性与消歧仍在范围内。因为用户必须能够找到“正确的那个包”所以命名消歧避免同名混淆、让brew search结果可辨识属于收录工作的一部分。这一边界解释了为什么homebrew/core不会出现“今日推荐”之类的策展内容而命名冲突的裁决谁保留无前缀 token则交由各仓库政策处理例如 Acceptable Casks 规定无关同名应用中“现有或更广为人知的应用通常保留无前缀 token”。Fork 替换原项目的两条硬性路径文档对“用 fork 取代已有项目”设置了严格准入新包不能用 fork 替换现有项目除非满足仓库专属的替换标准或至少满足以下两个条件之一原项目或原作者已公开指定该 fork 为其官方继任者officially designated successor至少两个其他主要软件发行版已将该 fork 用作原项目的替代品at least two other major software distributions use the fork as the replacement。同时文档明确合格的 fork 必须满足其仓库的所有其他接收要求Notability、维护状态等一条不少。对于不够格“继任”的 fork仍有一条退路——在仓库政策允许、且用户不会将其与原项目混淆时可以以不同名称distinct name提交。各仓库对 fork 细则的差异值得对照阅读Acceptable-Formulae 要求“名称能明确区分于原项目”Acceptable-Casks 更具体——与原版并存的 fork 必须在文件名和 token 中使用厂商名前缀即使原版已停止维护也要保留血缘标识并额外允许一种 cask 专属例外“当有充分证据证明 fork 的采用已压倒性地普遍用户理解原名称指的就是 fork”时可替换原 cask。成人内容面向多国用户的审查边界Homebrew 服务于多国用户策略明确不将某一文化的成人内容观强加给所有用户。但审查流程本身有明确约束审查一个包时维护者不应意外接触到露骨的成人或暴力素材。具体规则是包含成人内容的包可以被收录前提是包的homepage及其url所属域名根页面在普通办公环境审查时safe to open in a normal workplace review可以安全打开这些页面可以包含软件的事实性文字描述但这些页面不得在没有额外刻意操作additional deliberate action的情况下显示露骨的成人或暴力图像。这条规则的本质是“入口页面清洁”审查者点击homepage和下载域名的根路径时必须安全内容本体则不在限制之列。项目风险一个兜底性拒绝条款“Project risk”一节是一条原则性兜底条款当收录某软件会给 Homebrew 项目自身带来实质性的法律、基础设施、安全或项目延续性风险material legal, infrastructure, safety or project-continuity risk时Homebrew 有权拒绝或移除该包。这解释了策略后文“满足标准不保证收录”的立场——风险条款可以在任何具体标准之上覆盖决策。维护者裁量权标准是基线而非公式策略文档最后“Maintainer discretion”给出三点裁量原则值得提交者特别注意满足全部标准 ≠ 保证被接受缺少某一标准 ≠ 每例都必须拒绝记录在案的例外documented exception是允许的——当例外能提升 Homebrew 整体的可靠性、安全性或实用性时会做出有文档记录的例外新提交的标准可能高于存量包。因为接受一个包即意味着一项持续的维护承诺ongoing maintenance commitment存量包可能是在更宽松的旧标准下收录的新提交不应直接对标存量案例。工程上第 2 点“有文档记录的例外”与前文提到的audit_exception机制、以及 Tap 信任模型 中的人工评审流程相互印证Homebrew 的例外不是口头承诺而是以代码中可审计的白名单/豁免项形式存在。配套阅读如何把策略映射到提交实践策略文档本身不含操作步骤它回答“能不能收”而“怎么提交”由配套文档承担。结合 Adding Software to Homebrew 的流程一份完整的评估清单是先查标准对照本文的共享策略 Acceptable-Formulae 或 Acceptable-Casks 的仓库细则先查先例在homebrew/core或homebrew/cask的 open/closed PR 中检索此前的拒绝可能暴露了尚未解决的许可证、安全或分发问题本地验证用HOMEBREW_NO_INSTALL_FROM_API1 brew install --build-from-source FORMULA、brew test FORMULA、brew audit --strict --new --online FORMULA等命令验证——其中brew audit --online会触发前文分析的 Notability、仓库年龄等联网审计安全视角收录政策是供应链防线的一环homepage可达性、下载源可验证性、SHA-256 校验等要求与 Homebrew Security and Supply Chain 中“所有变更经人工 PR 评审”“命名空间由维护者策展”的模型一脉相承。小结Homebrew 的包接收策略以“可验证、可维护、有公共兴趣”为核心用 Notability 量化门槛GitHub 30/30/75自提交 90/90/225仓库年龄 ≥ 30 天划出底线用 fork 继任条款、成人内容边界、项目风险兜底条款控制结构性风险同时以维护者裁量权和 Tap 级例外机制保留弹性。策略中可量化部分已被brew audit --online的共享审计实现shared_audits.rb自动化提交者在提交前跑一遍联网审计即可在进入人工评审前拦截绝大多数标准问题。【免费下载链接】brew The Package Manager for Everywhere项目地址: https://gitcode.com/GitHub_Trending/br/brew创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考