[tacet] Strip quarantine before anything execs the bundle - #6
Merged
Conversation
Casks quarantine by default. For tacet that is fatal rather than annoying: nothing launches this bundle through LaunchServices — launchd starts it, and install-server.sh execs it to verify the install. Exec'ing a quarantined bundle directly blocks in _dyld_start waiting on a first-launch consent decision that has no UI to answer it, so the app deadlocks before running a line of its own code. Notarization does not help, which is what made this confusing: the gate is consent, not assessment, and `spctl -a` accepts the exact bundle that hangs. /Applications was never the variable either — a quarantined copy in ~/Applications hangs identically. The first blocked launch then wedges the path, not the file. Removing the xattr afterward does not recover it and neither does replacing the file; only a different path does. So the strip has to happen in postflight, before launchd or the installer can touch the binary. Solves: DRYCodeWorks/tacet#25 Tests: brew style + brew audit --cask clean; mechanism isolated against the published v0.1.1 artifact (quarantined -> rc=124 in _dyld_start, unquarantined -> rc=2) across five paths
This was referenced Aug 6, 2026
Merged
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.
Fixes the
_dyld_starthang tracked in DRYCodeWorks/tacet#25, which currently makes this cask unsafe to recommend.Why
Casks quarantine by default. Nothing ever launches tacet through LaunchServices — launchd starts it, and
install-server.shexecs it to verify the install. Exec'ing a quarantined bundle directly blocks in_dyld_startwaiting on a first-launch consent decision that has no UI to answer it, so the app deadlocks before running a line of its own code.Notarization does not help. The gate is consent, not assessment:
spctl -a -vvvreturnsaccepted / Notarized Developer IDon the exact bundle that hangs./Applicationswas never the variable either. A quarantined copy in~/Applicationshangs identically; the earlier "same bytes run elsewhere" observation held only because those copies were never quarantined.The first blocked launch then wedges the path, not the file — removing the xattr afterward does not recover it, and neither does replacing the file or
lsregister -u. Only a different path does. That is why the strip has to run inpostflight, before launchd or the installer can touch the binary.Evidence
Isolated against the published v0.1.1
Tacet.zipon macOS 26.6 (25G72), Apple Silicon:/Applications/Tacet.appusage:, rc=2/Applications/Tacet.app_dyld_start~/Applications/TacetQ.app/Applications/Tacet.app/Applications/TacetProbe3.appusage:, rc=2Full isolation table and the sampled stacks are in the issue.
Verification
brew style Casks/tacet.rb— no offensesbrew audit --cask --tap drycodeworks/tap tacet— cleanNot yet verified live. A real
brew install --cask/uninstallcycle would stop the runningcom.drycodeworks.tacet*agents on the test machine, so it was left for a deliberate run rather than done as a side effect.