pkg-attach and pkg-audit: an uploaded pkg that no group carries is inert

[rcurranmoz]

Uploading a pkg and attaching it to an assignment group are separate operations in SimpleMDM, and an unattached app does nothing at all — with nothing surfacing that fact.

On 2026-08-19 p_role_tart_worker was built, signed, uploaded, and left unattached, while the eight hosts it existed for carried no /etc/puppet_role. It was caught only because someone queried the group's app list by hand. Nothing in the toolchain could answer "is this pkg actually going to reach anything?"

pkg-audit (read-only)

Inverts every assignment group's app relationship, then names any pkg no group carries.

$ reprovision pkg-audit
  · 23 custom pkg(s) in the account (39 apple-store app(s) excluded), 20 attached to at least one group
  ▲ 1 bundle id(s) uploaded more than once with a copy attached to nothing:
  ▲     com.github.munki.pkg.p_role_gecko_t_osx_1400_r8
  ▲         630818  'p_role_gecko_t_osx_1400_r8-1.0-Signed'   ATTACHED TO NOTHING
  ▲         630822  'p_role_gecko_t_osx_1400_r8-1.0-wrapped'  ATTACHED TO NOTHING
  ▲ 5 custom pkg(s) attached to NOTHING — uploaded but inert

Both filters exist because the first live run buried its own findings:

• apple-store apps excluded by default. 39 entries for 1Password, Duo, Google Drive and friends, which legitimately reach iOS devices by other means. --include-store restores the full view.
• duplicates only when a copy is unattached. Flagging every duplicate bundle id surfaced com.mozilla.pkg.SignerBootstrap (six copies, one per signer group — vpn/tb/fx/dep/adhoc/ff-ent) and com.puppetlabs.puppet-agent (ARM and Intel), both deliberate. A duplicate that includes a stray upload is the smell.

pkg-attach

Attaches, then verifies by re-reading the group rather than trusting the POST — same reason step_add_to_group re-reads: with this API a 2xx is not evidence the state changed. Resolves an app by id or a unique substring of name/bundle id, and on an ambiguous match lists candidates instead of picking one.

Two guards matter more than the happy path:

• Production groups are refused, reusing PROTECTED_GROUP_IDS. Attaching a new app to a live prod group pushes it to every member; 2017918 has 130+ devices taking work. This is the "never add the bootstrap pkg to a production group" footgun in its other form, so it fails before any HTTP call.
• --push is off by default. push_apps re-pushes every app in the group to every member, including postinstalls — so a default-on push would let an innocuous attach re-run the bootstrap pkg on hosts that are mid-task. Without it the pkg lands at each device's next check-in, which on these boxes is often boot-only. The affected device count is printed either way.

What the audit found, which is the interesting part

The fleet's role pkgs are not the ones this repo's sibling blueprints build:

app	bundle	attached to
636989 Puppet Role - 1400 Prod	com.github.munki.pkg.PuppetRole	gecko-t-osx-1400-r8
637744 Puppet Role 1500 Prod	…p_role_1500	5 m4 groups
637743 Puppet Role 1500 Staging	…p_role_1500_staging	m4-staging
690299 p_role_tart_worker	…p_role_tart_worker	Tart
630818 / 630822	…p_role_gecko_t_osx_1400_r8	nothing
627567	…p_role_gecko_t_osx_1400_r8_staging	nothing

So relops_infra_as_code/osx_pkg_blueprints has never been the source of truth for what the fleet runs — the blueprint-built uploads were never attached, and p_role_gecko_t_osx_1500_m4 isn't in the account at all. Also worth noting r8 prod is served by a bundle id of just PuppetRole, generic enough that a second upload under that name would collide.

Testing

• 264 tests pass, ruff clean; 16 new tests covering the guards, verification, app resolution, and both audit filters.
• pkg-audit exercised live against the real account (read-only) — output above.
• pkg-attach's write path (POST /assignment_groups/{id}/apps/{app_id}) is not yet exercised live; today's attach was done through the UI. The read paths it depends on (apps(), assignment_group_app_ids()) are live-verified. Worth confirming on the next real attach.

🤖 Generated with Claude Code