Improve authorized writing and in-app results - #1
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 91ffdd8d6e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| let script = makePrivilegedScript(image: image, imageSize: imageSize, disk: disk) | ||
| let rawArguments = ["-c", script] |
There was a problem hiding this comment.
When the authorized child inherits the user's HOME or ZDOTDIR, invoking zsh -c lets it load the user-writable .zshenv before this script performs validation; the zsh startup-file documentation specifies that every invocation reads $ZDOTDIR/.zshenv. An unprivileged process can therefore plant commands there and have them execute as root when the user approves this otherwise legitimate write. Invoke zsh with -f before -c, or avoid a startup-file-aware shell at this privilege boundary.
Useful? React with 👍 / 👎.
| } | ||
| imageURL = url | ||
| imageField.stringValue = url.path | ||
| writePhase = .idle |
There was a problem hiding this comment.
During an active write, the File-menu “选择系统镜像…” item and its Cmd-O shortcut remain enabled because beginWriting() disables only chooseButton. Invoking that menu reaches this unconditional assignment and changes the UI to the idle/readiness state even though the privileged dd process is still running, potentially prompting the user to disconnect the target. Guard this selector while isWriting or disable/validate the corresponding menu item.
Useful? React with 👍 / 👎.
| exit 1 | ||
| fi | ||
|
|
||
| "$ROOT_DIR/script/build_and_run.sh" --build-only |
There was a problem hiding this comment.
When this DMG is produced on a macOS version newer than 13, the invoked build has no explicit deployment target, so swiftc records its default target in the Mach-O binary and the download can be rejected by dyld on the advertised macOS 13 systems; setting only LSMinimumSystemVersion in Info.plist does not lower that load command. I checked the swiftc invocation in script/build_and_run.sh, and swiftc --help identifies -target <triple> as the option that generates code for a specified OS target. Pass an arm64 macOS 13 target (or MACOSX_DEPLOYMENT_TARGET=13.0) and validate it with otool during packaging.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| /bin/mkdir -p "$OUTPUT_DIR" | ||
| /usr/bin/ditto "$APP_BUNDLE" "$STAGING_DIR/$APP_NAME.app" |
There was a problem hiding this comment.
When an existing USB启动盘工具.app contains files left by an older build or local experiment, build_and_run.sh only creates its directories and overwrites the currently known files; this ditto then copies every stale file into the release DMG. Consequently the claimed reproducible artifact depends on local build history and can ship obsolete or unintended resources. Remove the bundle before building or assemble the release into a fresh bundle directory before copying it to staging.
Useful? React with 👍 / 👎.
| /usr/bin/ditto "$APP_BUNDLE" "$STAGING_DIR/$APP_NAME.app" | ||
| /bin/ln -s /Applications "$STAGING_DIR/Applications" | ||
|
|
||
| /usr/bin/hdiutil create \ |
There was a problem hiding this comment.
When a developer has the previously generated DMG mounted—a common state after inspecting a release—this hdiutil create runs before detach_created_image_if_needed, so the mounted backing image remains open and creation fails rather than reaching the detach call. The hdiutil create -help description of -ov only permits overwriting an existing file; it does not detach a mounted image. Call the detach helper before creation as well as in cleanup so packaging can be rerun while the prior artifact is mounted.
Useful? React with 👍 / 👎.
2 participants
What changed
sudohandoff with the macOS system authorization UI.diskutil,dd, sync, eject, and failure output into the app.Why
Opening Terminal, requesting a password again, and splitting progress across two apps made the flow feel untrusted and difficult to follow. The earlier workspace also behaved like a rigid form: the window could not be resized, an oversized autosaved frame was restored, long filenames contributed their full intrinsic width, the sidebar expanded with the window, and the log could not use added vertical space.
The revised layout groups preparation choices together, makes current activity the primary status surface, and follows a predictable desktop resizing policy: dynamic text truncates first, critical controls remain visible, and logs receive flexible space.
Security and compatibility
The current certificate-free build uses the legacy Authorization Services execution bridge. It does not collect or store credentials. A persistent privileged helper is intentionally deferred until Developer ID signing is available so an
SMAppServiceXPC client can be authenticated reliably.Validation
xcrun swift-format lint --strict Sources/USBBootableDriveTool/main.swift./script/test.shgit diff --check./script/build_and_run.sh --verifydd: 4,762,707,968 bytes written in 47.8 secondsBooting the completed media on target hardware remains a separate acceptance step.