mac_v4_signing_dep_vms: exclude vault_agent (its binary is flagged as malware) - #1332
Open
rcurranmoz wants to merge 1 commit into
Open
mac_v4_signing_dep_vms: exclude vault_agent (its binary is flagged as malware)#1332rcurranmoz wants to merge 1 commit into
rcurranmoz wants to merge 1 commit into
Conversation
… malware)
Third profile excluded from the VM role, on the same grounds as hardware
and duo: it cannot work in a guest and actively causes harm.
profiles::vault_agent pulls in packages::vault, which installs a
June-2021, Intel-only vault build from S3 whose code-signing certificate
has since been REVOKED:
$ spctl -a -vv /usr/local/bin/vault
/usr/local/bin/vault: CSSMERR_TP_CERT_REVOKED
$ file /usr/local/bin/vault
Mach-O 64-bit executable x86_64
macOS reports that as malware on sight — a full "vault will damage your
computer / Report malware to Apple" alert on first GUI login of the
published image. It comes from XProtect scanning the FILE, not from an
execution attempt: an earlier attempt to suppress it by disabling the
LaunchDaemon was verified to take effect ("vault-agent" => disabled) and
the alert still fired.
The binary cannot execute anyway. On a built image launchctl shows
vault-agent never running and /var/log/vault-agent.log is never created.
And vault-agent cannot function in a credential-free VM image regardless,
since there is no AppRole id/secret. So the profile contributes nothing
here except a macOS malware alert.
Re-add it once a current, notarised, universal vault binary is published
to S3 and packages::vault::version is bumped. S3 currently holds only
vault-1.6.1.pkg and vault-1.7.3.pkg, both of that vintage.
NB this likely affects the bare-metal signers too, and would explain
something previously noticed and not understood: on fx-mac-v4-signing01
/etc/vault_approle_secret is zero bytes and /etc/vault_token does not
exist — exactly what a vault-agent that has never started looks like.
Worth checking there independently of the VM work:
spctl -a -vv /usr/local/bin/vault
sudo launchctl list | grep -i vault
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Third profile excluded from the VM role, on the same grounds as
hardwareandduo: it cannot work in a guest and actively causes harm.What happens
profiles::vault_agentpulls inpackages::vault, which installs a June-2021, Intel-only vault build from S3 whose code-signing certificate has since been revoked:macOS reports that as malware on sight — a full "vault will damage your computer / Report malware to Apple" alert on first GUI login of the published image.
Why disabling the daemon didn't fix it
I tried that first. The alert comes from XProtect scanning the file, not from an execution attempt. Verified on the built image: the daemon was disabled (
"vault-agent" => disabled) and the alert still fired.The binary cannot execute anyway —
launchctlshowsvault-agentnever running and/var/log/vault-agent.logis never created. And vault-agent cannot function in a credential-free VM image regardless, since there's no AppRole id/secret.So the profile contributes nothing here except a macOS malware alert.
Re-adding it
Once a current, notarised, universal vault binary is published to S3 and
packages::vault::versionis bumped. S3 currently holds onlyvault-1.6.1.pkgandvault-1.7.3.pkg, both of that vintage.This probably affects the bare-metal signers
And it would explain something I noticed earlier and couldn't account for. On
fx-mac-v4-signing01,/etc/vault_approle_secretis zero bytes and/etc/vault_tokendoes not exist — exactly what a vault-agent that has never started looks like. Worth checking there, independently of this VM work:spctl -a -vv /usr/local/bin/vault sudo launchctl list | grep -i vaultIf it reproduces, the signers' vault-agent has been dead for some time and nothing noticed, because nothing depends on it at task time.
🤖 Generated with Claude Code