Installer packages signed through the affected old Developer ID chain need re-signing planned before February 1, 2027. That does not mean every old Mac app stops running on the same day. Apple separately says previously signed and notarized Mac software with a secure timestamp will keep working. Begin with artifact type and issuing authority.

For maintainers, old download links, updaters and deployment repositories are easy to overlook. Updating CI credentials can still leave users receiving an old package. The synthetic inventory model below separates migration actions from the real signature and installation checks that must follow. 中文版.

Separate the dates and affected artifacts

The Mac Observer report found through Google News is dated October 17, 2026. Its primary source is Apple’s October 1 notice: the original Developer ID Sub-CA expires February 1, 2027, and .pkg files signed with affected certificates will no longer install from that date. This is an explanation of the earlier notice, not a newly announced rule.

Apple distinguishes existing software from future updates. Previously signed, notarized software with a secure timestamp keeps working; future releases should use the replacement certificate and required timestamping. That is a conditional statement, not a blanket exemption for everything old.

There is still time before the deadline. This article explains migration preparation; it does not claim affected packages have already universally failed or report a test of macOS installation behavior on a future date.

A familiar certificate name is insufficient evidence

Apple’s replacement guide treats expiration dates as a screening aid, not proof of the issuer. Identically named Developer ID certificates can belong to different authorities. Inspect the Organizational Unit under Issuer Name on the developer’s own certificate to distinguish the old authority from G2.

Do not inspect the intermediate authority entry instead. The guide explicitly distinguishes the developer’s certificate from the Developer ID Certification Authority item. Mixing those levels can lead to a confident classification of the wrong object.

Keep artifact identity, type, signing-certificate identity, issuer classification, supporting evidence and owner together in the inventory. A display name helps a person read the record, but does not replace evidence that distinguishes certificates. Building this inventory does not require exporting private keys; use only the evidence needed for the classification.

Build a triage inventory before changing packages

A deliberately synthetic rule can route old-authority packages into re-signing preparation, qualifying existing apps into retention, G2 artifacts into ordinary validation, and unknown issuers or unsupported types into manual investigation. It records the next action, distinguishing preparation to re-sign from a package already failing today, rather than forcing every row into a pass/fail answer.

Retain means no change solely for this expiration migration. It does not establish that an app is permanently safe, unrevoked or compliant with every system policy. G2 is not an automatic approval of the distribution chain either: the specific certificate, signature, notarization and delivered copy still need their appropriate checks.

This distinction separates known work from insufficient evidence. Missing metadata should not quietly turn into a conclusion that nothing needs attention. The following code intentionally consumes classifications supplied by the inventory; it does not discover or authenticate those classifications itself.

# 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")

Eight checks passed locally, covering old packages, G2, unknown issuers, missing app conditions and unsupported types. The input is synthetic metadata. No keychain access, certificate-chain validation, real package signing or software installation occurred.

Follow the artifact all the way to the download

Changing the build machine establishes only that a future build may use a new identity. Trace the actual release path: build output, release attachments, download site, object storage, mirrors, updater endpoints and enterprise deployment repositories. Determine which locations still serve an old copy rather than assuming one CI change updates them all.

Re-signing changes file contents. Generate release digests, manifests and version associations from the final artifact. An old checksum beside a new package is not a valid record of the new file. A local test of the new package also does not establish successful delivery if a cache or mirror continues serving its predecessor.

Avoid losing traceability by overwriting every archive indiscriminately. Preserve the internal audit record, identify historical versions still publicly distributed and replace outward-facing copies through the established release process. Record replacement and verification separately. Retention policy should follow the team’s existing requirements rather than being invented from this notice.

Ask three different validation questions

First, identity and artifact: what is this file and which certificate signed it? Second, platform acceptance: does it install or launch through the intended path on the target system? Third, delivery: does a download from the user-facing location return the same validated artifact? Evidence answering one question does not automatically answer another. If a package contains an app, record the package signature and inner app signature separately; the inner app’s status does not replace checking its installer container.

A build log saying new certificate does not prove the remote attachment changed. An app opening on a developer machine does not establish a clean-environment package installation. Record the operating-system version, artifact digest, download source and execution time so that a result has an inspectable scope.

Use controlled test environments and the normal signing and notarization workflow. Do not manufacture acceptance by disabling platform protection, ignoring verification failures or changing the clock. No such platform tests were performed here. Passing the inventory’s assertions cannot be reported as an installation success rate.

Track renewal for the actual signing certificate

Apple distinguishes the G2 authority’s lifetime from the annual lifetime of certificates it issues. Reading CA valid through 2031 as our signing identity works until 2031 would miss the next renewal. A chain contains several lifetimes, and an operational reminder must identify which one it tracks.

Assign an owner and expiration reminder to the identity actually in use. Schedule replacement validation before expiry rather than recording only the 2027 deadline. Tie the reminder to the relevant pipelines and distributed artifacts; forwarding a notice without ownership does not establish a maintained renewal process.

Follow the official account guide for permission requirements and replacement steps. This article does not perform account administration or change a signing identity. Its purpose is to organize the evidence and release work around the announced transition.

A useful starting point for package maintainers

Find the packages still publicly distributed, then identify inventory rows missing issuer evidence. Plan replacement and target-system testing for affected packages. Do not re-sign every qualifying existing app merely because a headline mentions expiration. When evidence is incomplete, resolve it before choosing an action rather than guessing the result of the triage.

This connects to the earlier CI evidence-binding article: a verification result belongs to a specific artifact and set of conditions. Replacement credentials alone do not complete delivery. Downloading the right copy and validating it through the intended platform path closes the remaining gap.

If this inventory model helps you locate an overlooked installer or distinguish certificate levels correctly, voluntary support through the section below is welcome.

Sources and catch-up note

Checked the October 17 report, October 1 Apple notice and replacement guide. Both diagrams, triage rules and eight local checks are original teaching material. No real-certificate, installer or future-date test was run. This pair retains its planned October 18, 07:00 Beijing article date and was actually posted later on October 18; cited news and announcements were public before the original slot.