T03 · Remote Payload Retrieval and Execution
- Location
scripts/homebrew/setup.sh:145- Finding
Unverified Homebrew Installer Is Downloaded and Executed Directly
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill mostly does what it says, but it can make persistent, high-impact changes to package sources, Git routing, shell profiles, and trust settings that deserve careful review.
Install only if you are comfortable letting this skill modify development tool configuration and system package sources. Prefer dry-run first, avoid --yes, review any sudo commands, avoid --proxy-clone unless you want all future HTTPS GitHub Git operations routed through a third-party proxy, and be cautious because backups may include sensitive files such as .npmrc.
scripts/homebrew/setup.sh:145Unverified Homebrew Installer Is Downloaded and Executed Directly
scripts/rust/setup.sh:110Rust Setup Recommends Executing an Unverified Remote Script Through a Shell Pipeline
scripts/github/setup.sh:157Global Git Configuration Transparently Routes All GitHub HTTPS Operations Through a Third-Party Proxy
scripts/restore_config.sh:101Untrusted Backup Metadata Can Select an Arbitrary Restore Destination
The declared description is for a comprehensive, self-contained orchestrator covering many package managers and diagnostic tasks. The supplied code chunk is only an APT setup script focused on Ubuntu/Debian sources.list management. While one small aspect of the description mentions running relevant scripts for individual tools, this specific code does not match the claimed primary purpose of being the main entry point that diagnoses and configures all tools. Its actual scope is materially narrower: APT-only configuration with backup, proxy warning, confirmation, dry-run, and package index update.
The declared description presents this as the main self-contained entry point for configuring mirrors and diagnosing network/tooling issues in China. The provided code chunk is instead a backup helper script focused on copying existing config files and enumerating backup metadata. That is a materially different primary purpose from the declared behavior. While backup functionality could be a supporting detail in a larger mirror-configuration skill, the code shown does not implement any of the core promised capabilities such as tool detection, proxy conflict checks, mirror application, connectivity tests, or diagnostic reporting. Therefore the description does not accurately represent what this code chunk actually does.
The description presents a broad orchestration and diagnostic skill for many development tools, with environment-wide detection, diagnostics, and recommendations. The actual code chunk only implements Conda mirror configuration. It does include one declared aspect—proxy conflict checking—and performs expected setup tasks like backup, config generation, cache cleaning, and basic validation. However, its primary purpose is much narrower than the declared skill description, and the major multi-tool diagnostic/orchestration behavior is absent from this code chunk. There is also a likely implementation bug: setup_conda_mirror calls generate_conda_mirror, but the defined function is generate_condarc. That bug does not change the mismatch determination.
The declared description is for a comprehensive, self-contained entry point that configures and diagnoses many development tools in China network conditions. The supplied code instead implements a narrow Docker-specific setup script for configuring Docker CE installation package mirrors on Linux. It changes apt/yum repo files, installs prerequisite packages, fetches a GPG key, updates package caches, and warns that Docker Hub image mirrors are different. Those actions are consistent with one small part of the declared system, but the code chunk does not exhibit the broad orchestration, diagnostics, tool detection, proxy checking, or recommendation features claimed in the description. Therefore, the description does not accurately represent this specific code chunk.
The declared description is for a broad, all-in-one tool configuration and diagnostic entry point covering many package managers and network checks. The supplied code chunk only implements Flutter mirror setup. It edits ~/.bashrc, ~/.bash_profile, or ~/.zshrc to set FLUTTER_STORAGE_BASE_URL and PUB_HOSTED_URL, removes prior Flutter config blocks, backs up the profile, and warns about proxy conflicts via a shared helper. While proxy-conflict checking aligns partially with the description, the primary purpose and scope are much narrower than declared, and the advertised diagnostic capabilities are absent from this code chunk.
The description presents a broad, self-contained umbrella skill for setup and diagnostics across many development tools in China's network environment. The actual code chunk is much narrower: it handles GitHub-related acceleration only, specifically release URL rewriting, global git insteadOf rules for GitHub via ghfast, and one curated flutter-sdk mirror mapping. While the script does include a proxy-conflict warning hook from common utilities, that is only a small supporting detail and does not substantiate the declared comprehensive diagnostic behavior. This is therefore a clear description-behavior mismatch due to substantial overstatement of scope and capabilities.
The declared description is for a broad, all-in-one environment configuration and diagnostics skill, but the supplied code chunk only implements a narrow Go proxy setup operation. It modifies shell startup files to set GOPROXY/GO111MODULE, validates a selected Go mirror, and checks for Go installation. While proxy-conflict checking is mentioned and likely provided by a shared helper, there is no evidence here of multi-tool detection, diagnostics, source connectivity testing, recommendation generation, or acting as a central entry point. Therefore the description materially overstates and misrepresents what this specific code chunk actually does.
The declared description portrays a broad, centralized skill for both configuration and diagnostics across many development tools and network conditions in China. The supplied code chunk is much narrower: it is specifically scripts/homebrew/setup.sh and only configures Homebrew mirrors. It does include one declared-supporting behavior—checking for proxy conflicts—and it can install Homebrew if missing, but it does not implement the multi-tool detection, diagnostics, source connectivity tests, comparison of mirror speeds, or recommendation generation described as core functionality. This is therefore a material description-versus-behavior mismatch for the supplied code chunk.
The description presents a self-contained, top-level orchestration and diagnostic skill for many development tools across the system. The actual code provided is narrowly scoped to Python package manager mirror setup: it manages pip, uv, and some poetry-related guidance. While some elements align with the description at a small scale—such as checking for proxy conflicts and configuring mirrors—the primary scope and capabilities are materially narrower than claimed. There is no implementation here for npm/yarn/pnpm, docker, apt, cargo, go, conda, flutter, or homebrew, and no comprehensive diagnostic behavior such as connectivity tests, mirror speed comparisons, or recommendation generation. Therefore the declared description does not accurately represent this supplied code chunk.
The supplied code chunk does not implement the declared primary purpose of configuring mirrors, detecting installed tools, diagnosing network connectivity, checking proxy conflicts, or generating recommendations. Instead, it is a backup restoration utility focused on enumerating backups and restoring prior configuration files for specific tools. That is a materially different purpose and an undeclared capability relative to the description. While backup/restore could be related to a broader configuration-management skill, this specific code chunk is not accurately represented by the declared description as written.
The declared description presents a broad, centralized tool for full-environment configuration and diagnostics across many package managers and development tools. The supplied code chunk is much narrower: it only configures Rust/Cargo mirror settings and emits rustup-related guidance. While one declared element—checking for proxy conflicts—is partially reflected via a helper call, the script does not implement the description’s primary multi-tool orchestration or network-diagnostic behavior. This is therefore a material description-to-behavior mismatch due to substantially overstated scope and capabilities.
The script explicitly backs up ${HOME}/.npmrc, which commonly contains registry authentication tokens, scoped credentials, or private registry settings. Copying credential-bearing files into a backup store increases the attack surface and can expose secrets if the backup directory has weaker permissions, is later archived, or is readable by other users/processes.
# Format: tool_name:path1,path2,...
declare -A TOOL_CONFIGS=(
["pip"]="${HOME}/.config/pip/pip.conf,${HOME}/.pip/pip.conf"
["npm"]="${HOME}/.npmrc"
["docker"]="/etc/docker/daemon.json"
["apt"]="/etc/apt/sources.list,/etc/apt/sources.list.d/*"
["homebrew"]="${HOME}/.bash_profile,${HOME}/.zshrc,${HOME}/.config/fish/config.fish"
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
# Remove old docker.list if exists
if is_root; then
rm -f /etc/apt/sources.list.d/docker.list
else
sudo rm -f /etc/apt/sources.list.d/docker.list
fi
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
# Remove old docker.list if exists
if is_root; then
rm -f /etc/apt/sources.list.d/docker.list
else
sudo rm -f /etc/apt/sources.list.d/docker.list
fi
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Add Docker's official GPG key
log_info "Adding Docker GPG key..."
local keyring_dir="/etc/apt/keyrings"
if is_root; then
install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Add Docker's official GPG key
log_info "Adding Docker GPG key..."
local keyring_dir="/etc/apt/keyrings"
if is_root; then
install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Add Docker's official GPG key
log_info "Adding Docker GPG key..."
local keyring_dir="/etc/apt/keyrings"
if is_root; then
install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Add Docker's official GPG key
log_info "Adding Docker GPG key..."
local keyring_dir="/etc/apt/keyrings"
if is_root; then
install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
Saving a remotely retrieved repository signing key into APT's trusted keyring establishes a new trust root for package installation. If that key is not independently authenticated, an attacker controlling the mirror or network path can introduce a malicious key and cause arbitrary code execution later through trojaned packages.
log_info "Adding Docker GPG key..."
local keyring_dir="/etc/apt/keyrings"
if is_root; then
install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
chmod a+r "$keyring_dir/docker.asc"
else
This line streams a remote GPG key into a trusted system keyring path under sudo. Because that key determines which packages APT will trust, accepting it from a mirror without fingerprint verification can let an attacker establish a malicious package-signing root.
if is_root; then
install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
chmod a+r "$keyring_dir/docker.asc"
else
sudo install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
Writing network-supplied key content into the APT keyring path with elevated privileges creates a persistent trust-anchor change. In the context of a bootstrap skill that reconfigures package sources, this is especially dangerous because it can silently affect all future package installs.
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" -o "$keyring_dir/docker.asc"
chmod a+r "$keyring_dir/docker.asc"
else
sudo install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
sudo chmod a+r "$keyring_dir/docker.asc"
fi
The piped curl | sudo tee pattern directly installs a repository key into the system trust store with no cryptographic identity check beyond TLS to the mirror. Compromise of the mirror, CDN, DNS, or local TLS trust can result in a malicious signing key being trusted for privileged package installation.
chmod a+r "$keyring_dir/docker.asc"
else
sudo install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
sudo chmod a+r "$keyring_dir/docker.asc"
fi
This command chains a remote download directly into a privileged write, collapsing trust, validation, and installation into one step. In a repository bootstrap context, that makes the host trust whatever key the mirror serves and can enable malicious package installation with root impact.
chmod a+r "$keyring_dir/docker.asc"
else
sudo install -m 0755 -d "$keyring_dir"
curl -fsSL "${mirror_url}/linux/${distro_id}/gpg" | sudo tee "$keyring_dir/docker.asc" > /dev/null
sudo chmod a+r "$keyring_dir/docker.asc"
fi
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
if is_root; then
echo "$repo_line" > /etc/apt/sources.list.d/docker.list
else
echo "$repo_line" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
fi
# Update package list
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
if is_root; then
echo "$repo_line" > /etc/apt/sources.list.d/docker.list
else
echo "$repo_line" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
fi
# Update package list