受旧Developer ID签发链影响的.pkg，需要在2027年2月1日前安排重签；这不等于所有旧Mac应用都会在同一天停止运行。Apple对已经签名、公证且带安全时间戳的Mac软件，给出了继续工作的说明。排查时先分清产物类型，再确认签发方。

对维护安装包的团队，真正容易漏掉的是旧下载链接、更新器与企业部署仓库。即使CI已经换证，用户仍可能拿到旧包。下面给出一份可复现的盘点分流模型，并解释它与真实签名验证之间的边界。Read in English。

先把日期与适用对象说清楚

Google News收录的The Mac Observer报道日期为2026年10月17日，原始依据是Apple于10月1日发布的到期公告。公告所指原Developer ID Sub-CA将于2027年2月1日到期；使用受影响证书签名的.pkg从该日期起将无法安装。这里不是把10月1日的公告包装成刚刚发布的新规则。

同一公告区分了已有软件与未来更新：此前已签名、公证并带安全时间戳的软件可继续工作；后续版本使用新证书并按要求提供时间戳。继续工作这个结论有明确条件，不能缩写成“所有旧软件不受影响”。

目前离截止日仍有时间。本文是迁移准备解读，不是声称今天旧包已经全面失效，也没有验证未来日期上的macOS安装行为。

为什么不能只看证书名称或到期日

Apple替换帮助提醒，到期日可以用于筛查，但不能独立证明签发方。同名Developer ID证书可能来自不同authority。应查看自己的开发者证书Issuer Name中的Organizational Unit：旧签发方与G2在这里有不同标识。

尤其不要误查中间CA条目本身。帮助页明确要求检查自己的证书，而非名为Developer ID Certification Authority的authority条目；否则会把链中的不同层级混在一起。

盘点时至少把产物标识、产物类型、签名证书身份、签发方判断、证据来源和负责人放在同一条记录中。显示名称只适合人读，不能替代能够区分实际证书的证据；也不应为做这份清单导出私钥。

先建分流表，不急着批量改包

一份明确虚构的盘点规则可以这样拆：旧签发方的pkg进入重签准备；已满足公告条件的既有app进入保留；G2产物仍需正常验证；签发方不明或类型不支持的记录转人工核对。

这里的“保留”仅针对这次到期迁移，不表示应用永远安全、未被撤销或满足所有系统政策。“G2”同样不是整个分发链自动合格的绿灯：还要确认具体证书有效性、签名、公证与交付副本。

这样的分类比给每行一个“通过/失败”更有用。它把已知需要行动与证据不足分开，并将“需要准备重签”与“当前已经安装失败”分开，避免把缺失信息误当作没有风险。

# Synthetic inventory triage only. No certificate or signature verification.
def triage(kind, issuer, notarized=False, timestamp=False):
    if kind not in {"pkg", "app"} or issuer not in {"old", "G2"}:
        return "manual"
    if issuer == "G2":
        return "separate-validation"
    if kind == "pkg":
        return "prepare-re-sign"
    if notarized and timestamp:
        return "retain-existing-app"
    return "manual"

cases = [
    (("pkg","old"), "prepare-re-sign"),
    (("pkg","G2"), "separate-validation"),
    (("pkg","unknown"), "manual"),
    (("app","old",True,True), "retain-existing-app"),
    (("app","old",True,False), "manual"),
    (("app","old",False,True), "manual"),
    (("dmg","old"), "manual"),
    (("app","G2",True,True), "separate-validation"),
]
for args, expected in cases:
    assert triage(*args) == expected
print("8 inventory checks passed")

八项检查已本地执行，覆盖旧pkg、G2、未知签发方、app条件缺失及不支持类型。代码只接收人工归类的合成元数据，没有读取钥匙串、验证证书链、重签真实包或安装任何软件。

换证之后，还要追到用户拿到的文件

构建机配置改好，只证明未来某个任务可能使用新身份。应沿着发布路径检查：构建输出、发布附件、下载站、对象存储、镜像、自动更新地址和企业软件分发仓库，哪些地方仍提供旧副本。

重签会产生新的文件内容。用于发布校验的摘要、清单及版本关联应基于最终副本重新生成，不能把旧包的摘要贴在新包旁边。若缓存或镜像仍返回旧副本，本地验证新包并不能证明用户已收到新包。

不应直接覆盖所有归档而丢失追溯线索。可先保留内部审计记录，明确哪些历史版本仍公开分发，再按既定发布流程替换对外副本，并记录替换完成与验证结果。具体保留策略由团队既有要求决定。

把验证分成三道不同的问题

第一道是身份与产物：该文件究竟是什么，签名来自哪张证书。第二道是平台接受：在目标系统和实际安装路径下能否按预期安装或启动。第三道是交付：从用户会访问的地址下载，拿到的是不是同一个已验证副本。三道问题不能互相作答。若pkg里还包含app，包的签名与内部app的签名也应分别记录，不能用内层应用的状态替代安装容器的检查。

例如一份构建日志写着“使用新证书”，无法证明远端下载附件已经更新；一台开发机能启动app，也无法证明pkg安装路径在干净环境中正常。验证条件应包含系统版本、产物摘要、下载来源和执行时间。

测试应放在受控环境，用团队正常的签名与公证流程完成，不通过关闭系统保护、忽略验证失败或修改时钟来制造“成功”。本文没有执行这些平台测试，分流代码的通过次数也不能当作安装成功率。

年度续期应跟着具体证书走

Apple公告说明G2 authority的有效期与它签发的开发者证书有效期不同，后者需要年度续期。把“CA到2031年”理解成“我们的签名证书也能一直用到2031年”，会把下一次维护遗漏。

更实用的做法是给实际使用的证书建立负责人和到期提醒，并把替换验证安排在过期前，而不是只记录这次2027年的截止日。提醒应对应正在用的身份、流水线和分发产物，不能停留在一封没人负责的公告转发。

创建或替换证书的具体权限与操作步骤应按官方帮助执行；本文不代替账户管理，也没有修改任何签名身份。

安装包维护者现在可以先做什么

先找出仍在公开分发的pkg，再找出签发方证据缺失的条目。对受影响包安排替换和目标系统测试，对已有符合条件的app不要仅因这条新闻就无差别重签。证据不全时先补证据，而不是猜测分流。

这与CI结果复用的证据绑定相通：验证结果应绑定具体产物与条件。换证本身不是交付完成，重新下载到正确副本并按目标路径验证，才把迁移闭环补上。

若这份盘点模型帮你避免漏掉旧安装包或混淆证书层级，欢迎通过文末支持区自愿支持。

来源与补发说明

核对10月17日原报道、10月1日Apple公告及替换帮助。两幅图、盘点规则和八项本地检查为原创教学内容，未进行真实证书、安装包或未来日期测试。本组文章按10月18日07:00计划日期补发，实际补发于10月18日；引用的新闻与公告在原计划前已公开。