Secure file handoffs on remote cloud Macs

When a team uploads signing materials, test data, or builds awaiting acceptance to a cloud Mac, the most common mistake is placing them directly in the repository root. As soon as the files arrive, indexers, build scripts, and cleanup jobs may begin reading them. If an archive contains path traversal entries, incorrect permissions, or undocumented extended attributes, the problem can spread directly into the workspace. A safer approach is to separate “transfer” from “use” into two distinct stages.

Define the handoff boundary first

Every handoff should identify at least four things: the sender, the recipient, the purpose of the files, and the retention period. Source patches, test fixtures, build artifacts, and credentials must not be mixed in the same archive. Credentials should be provided through a controlled injection mechanism and must not appear in chat history, build logs, or ordinary file packages.

Even on VMRunner dedicated physical nodes, create a separate staging directory for each task instead of reusing a long-lived Downloads directory. The directory name may use a ticket number or internal task ID, but it should not contain customer names, email addresses, or other sensitive information.

umask 077
handoff_root="$HOME/Handoffs/task-4821"
install -d -m 700 "$handoff_root/incoming"
install -d -m 700 "$handoff_root/verified"
install -d -m 700 "$handoff_root/logs"
stat -f '%Su %Sg %Sp %N' "$handoff_root" "$handoff_root/incoming"

umask 077 makes subsequently created files accessible only to the current user by default. install -d creates each directory and sets its permissions in one operation, avoiding the brief exposure that can occur when a directory is created first and secured afterward.

The staging area is not intended for permanent storage. Its purpose is to provide a buffer where files can be inspected, rejected, and removed before they enter the project workspace.

Create a verifiable manifest before sending

The sender should freeze the directory contents before generating checksums. Do not calculate hashes while a build job is still rewriting artifacts, or the recipient may receive a manifest that refers to a different version. A good practice is to copy the files into a read-only delivery directory, confirm the file count, and then generate a SHA-256 manifest.

Exclude unnecessary content when packaging

For source deliveries, exclude .git, local caches, derived data, and environment files. For build artifacts, preserve the required signing structure and extended attributes. Do not arbitrarily repackage application directories merely to reduce archive size.

cd "$HOME/Delivery/task-4821"
find . -type f ! -name 'SHA256SUMS' -print0 \
  | sort -z \
  | xargs -0 shasum -a 256 > SHA256SUMS
shasum -a 256 SHA256SUMS

The recipient must obtain the checksum of SHA256SUMS itself separately through a confirmed internal channel. If both the manifest and the files arrive through the same unverified path, an attacker can replace both.

Verify files before extracting them

Files should enter incoming first rather than overwrite the repository directly. Once the transfer is complete, record each item’s name, size, owner, and permissions before comparing checksums. Stop if anything differs. Do not try to “fix it and continue,” because the discrepancy may result from an interrupted transfer, repackaging by the sender, or file substitution.

cd "$handoff_root/incoming"
shasum -a 256 -c SHA256SUMS
find . -maxdepth 2 -print0 \
  | xargs -0 stat -f '%z %Su %Sg %Sp %N' \
  > "$handoff_root/logs/received-files.txt"

Inspect archive paths first

For a ZIP archive, run unzip -l package.zip first. For a tar archive, run tar -tf package.tar. Reject archives containing absolute paths, ../ traversal paths, or unexpected symbolic links. After inspection, extract only into an empty directory, then rerun the file inventory and permission checks.

macOS files may also carry extended attributes. Use xattr -lr to inspect provenance markers and other attributes; do not routinely clear them recursively. Remove a specific attribute from a specific file only when its origin is known, its impact is understood, and the task genuinely requires it.

Tighten permissions when promoting files

After verification succeeds, copy the files to verified, then have the project owner move them into the workspace. This preserves an accepted copy that remains separate from the original received content. Ordinary files can be made readable and writable by the current user, while immutable inputs used only by the build can be set to read-only.

cp -R "$handoff_root/incoming/ProjectInput" \
  "$handoff_root/verified/"
chmod -R go-rwx "$handoff_root/verified"
find "$handoff_root/verified" -type f -exec chmod 600 {} +
find "$handoff_root/verified" -type d -exec chmod 700 {} +

Do not run recursive chmod blindly across the entire project. Executable scripts, application bundles, and frameworks have different permission requirements, and changing everything to 600 may break later tasks. Tighten permissions only on the staging copy. During the final import, restore any permissions required by repository metadata or build rules.

If multiple people collaborate through the same cloud Mac, use separate system accounts and directories whenever possible. Temporarily granting global read and write access may be convenient, but it makes file provenance and responsibility for changes impossible to trace.

Confirm that nothing remains when closing the handoff

Before completing the task, confirm that the project has received the required files and record their final checksums. Then check for extracted copies, packages left by failed retries, log attachments, and processes that still have files open. lsof +D can be slow on large directories, so run it only against the staging directory for this handoff.

lsof +D "$handoff_root" 2>/dev/null
find "$handoff_root" -type f -maxdepth 4 -print
rm -rf "$handoff_root"
test ! -e "$handoff_root" && printf '%s\n' 'handoff removed'

Deleting the staging area does not complete credential governance. If a sensitive value appeared in command-line arguments, Shell history, build logs, or error reports, clean up those records and rotate the credential. For routine handoffs, retain only the minimum audit data: the task identifier, send and receive times, manifest checksum, acceptance result, and deletion result. Do not retain the file contents.

A reliable remote collaboration workflow does not depend on everyone remembering to be careful. Instead, every file must pass through four explicit stages: isolation, verification, authorization, and cleanup. After packaging these commands into team scripts, regularly test them with harmless samples that simulate checksum failures, path traversal, and permission anomalies. The rejection path must remain just as operational as the normal path.

Frequently asked questions