Uh oh!
There was an error while loading. Please reload this page.
Tidy up the macOS installer scripts and guard the openh264 licence - #29
Merged
Conversation
Group every constant at the top of postinstall and postremove instead of spreading them through the body, and review what the scripts actually do. Three things came out of that review: - The download used fixed paths under /tmp, which any local user can write. A symlink or a pre-created file there would have been moved into /Library by root. Use mktemp -d with a cleanup trap instead. - Nothing checked what was downloaded. Now that the launcher is signed with disable-library-validation, dyld no longer rejects a dylib signed by another team, so verify Cisco's team id before installing the file. - The log lived in /tmp too, next to a leftover debug marker no code reads. build-pkg.py now fails the build if any openh264 file is found inside the finished bundle. We are licensed to download that library, never to ship it, so a copy sneaking into the app is a licensing problem, not a build glitch.
The verification step must not be the reason a stock Mac ends up without the codec, so fall back to installing unverified when codesign is missing, the way the script behaved before. Cisco serves the same file over https, and the download runs as root, so stop asking for it in the clear.
dkmstr
approved these changes
Sep 1, 2026
Uh oh!
There was an error while loading. Please reload this page.
aschumann-virtualcable
deleted the
chore/macos-installer-scripts-cleanup
branch
September 1, 2026 15:31
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Follow-up to the call: group the constants at the top of the installer scripts and review what they actually do.
Constants
ARCHandVERSIONwere defined halfway down the script, the URL was built there, andTEMP_FILE/DECOMPRESSED/TARGET_FILElived further down still. Everything now sits in one block at the top of bothpostinstallandpostremove.What the review turned up
/tmp, which any local user can write. A symlink or a pre-created file at/tmp/openh264.dylibwould have been moved into/Libraryby root. Now it usesmktemp -dwith a cleanup trap.disable-library-validation, dyld no longer rejects a dylib signed by another team, so that guarantee has to be recovered here: the script verifies Cisco'sTeamIdentifierbefore installing the file./tmptoo, next to a leftover debug marker (udslauncher-postinstall-ran) that nothing in the tree reads. Both moved to/var/log/udslauncher-install.log.Licence guard
build-pkg.pynow fails the build if anyopenh264file is found inside the finished bundle. We are licensed to download that library, never to ship it, so a copy sneaking in is a licensing problem rather than a build glitch. Previously twocontinuestatements skipped the copy, but nothing stopped it arriving by another route.Checked against fake bundles: a clean one reports nothing,
libopenh264.8.dylibunderFrameworksis caught, and anOpenH264.frameworkdirectory underResourcesis caught too.One correction
The
postinstallwas renaming the file already. Themvto$TARGET_DIR/$TARGET_FILEwithTARGET_FILE="libopenh264.8.dylib"predates this branch, and the installed file is present on the ARM build machine:The path checked during the call was
~/Library/Application Support/UDS launcher/— user~/Libraryrather than/Library, andUDS launcherwith a space rather thanUDSLauncher. The bug that actually broke H264 was the loader looking for the unversioned name, fixed in #28.Not verified here
The scripts are macOS-only and could not be executed on the development machine. Both pass
bash -n; the licence guard was exercised against fake bundles. They need a real run on a build machine.