Security: `arcup --self-update` replaces the installer without authenticity verification

[mssystem1]

Summary

The arcup --self-update command downloads the latest installer directly from the mutable main branch and replaces the local executable without verifying a checksum, commit SHA, or cryptographic signature.

The downloaded file is only checked for an ARCUP_INSTALLER_VERSION declaration. A file containing a higher version string is accepted and copied over the installed arcup executable.

This differs from Arc node release installation, where the archive is verified against a downloaded SHA-256 checksum.

Repository

circlefin/arc-node

Create issue:

https://github.com/circlefin/arc-node/issues/new

Affected file

arcup/arcup

Mutable self-update source:

arc-node/arcup/arcup

Lines 23 to 25 in 745ba4e

	ARCUP_BIN_PATH="$BIN_DIR/arcup"
	GITHUB_API_URL="${GITHUB_API_URL:-https://api.github.com}"
	case "$GITHUB_API_URL" in

Self-update implementation:

arc-node/arcup/arcup

Lines 435 to 469 in 745ba4e

	require_command curl "curl not found. Please install curl."
	_ARCUP_TMP_FILE=$(mktemp)
	info "Downloading latest arcup..."
	if ! curl_with_headers -fsSL -o "$_ARCUP_TMP_FILE" "$ARCUP_BIN_URL"; then
	error "Failed to download arcup update"
	fi
	local remote_version
	remote_version=$(grep '^ARCUP_INSTALLER_VERSION=' "$_ARCUP_TMP_FILE" | sed -E 's/ARCUP_INSTALLER_VERSION="(.+)"/\1/')
	if [[ -z "$remote_version" ]]; then
	error "Failed to determine remote version"
	fi
	if ! version_gt "$remote_version" "$ARCUP_INSTALLER_VERSION"; then
	info "Arcup is already up to date (version $ARCUP_INSTALLER_VERSION)"
	exit 0
	fi
	info "Updating from $ARCUP_INSTALLER_VERSION to $remote_version..."
	if cp "$_ARCUP_TMP_FILE" "$ARCUP_BIN_PATH" 2>/dev/null; then
	chmod 755 "$ARCUP_BIN_PATH"
	else
	error "Failed to update arcup at '$ARCUP_BIN_PATH' — ensure it is writable"
	fi
	echo ""
	info "Arcup updated successfully to version $remote_version"
	exit 0
	}
	# Remove arc binaries and env files

The update path downloads the script and installs it with:

curl_with_headers -fsSL -o "$_ARCUP_TMP_FILE" "$ARCUP_BIN_URL"

followed by:

cp "$_ARCUP_TMP_FILE" "$ARCUP_BIN_PATH"
chmod 755 "$ARCUP_BIN_PATH"

Steps to reproduce

1. Install an older version of arcup.

2. Run:

   arcup --self-update

3. Observe that the update is downloaded from:

   https://raw.githubusercontent.com/circlefin/arc-node/main/arcup/arcup
   

4. Observe that the downloaded file is only inspected for:

   ARCUP_INSTALLER_VERSION="..."

5. No SHA-256 checksum, pinned commit, release asset signature, or trusted signing key is verified before the file replaces the installed executable.

A minimal file containing a higher version declaration and arbitrary shell commands would satisfy the current version check.

Expected behavior

A self-updating executable should verify that the downloaded replacement was published by the Arc maintainers before executing or installing it.

The update should be obtained from an immutable release asset and verified using at least one trusted mechanism, such as:

• a checksum embedded in or anchored by the currently installed updater;
• a cryptographic signature checked against a pinned maintainer key;
• a pinned release commit or immutable GitHub release asset with verified provenance.

Actual behavior

arcup trusts the contents returned from a mutable main branch URL and installs them after checking only that the file declares a newer version.

The existing GPG/checksum verification used for Arc node archives is not applied to the self-update path.

Impact

If the update source or delivery path is compromised, the next user running:

arcup --self-update

could install and subsequently execute attacker-controlled shell code.

Depending on how Arc operators run the installer, this could expose:

• validator or node host credentials;
• environment variables;
• filesystem contents accessible to the operator;
• node configuration and secrets;
• the integrity of the Arc node installation.

This is particularly sensitive because installer scripts are commonly executed with elevated filesystem permissions.

Suggested fix

Publish arcup as an immutable GitHub release asset and verify it before replacement.

For example:

1. Download arcup, arcup.sha256, and optionally arcup.asc from the same tagged release.
2. Verify the checksum.
3. Verify the signature against a pinned Arc release-signing fingerprint.
4. Validate the downloaded script before replacing the current executable.
5. Perform the replacement atomically.

Example flow:

download_file "$tag" "arcup" "$TMP_DIR"
download_file "$tag" "arcup.sha256" "$TMP_DIR"

verify_checksum_file \
  "$TMP_DIR/arcup" \
  "$TMP_DIR/arcup.sha256" \
  "arcup"

install -m 755 "$TMP_DIR/arcup" "$ARCUP_BIN_PATH.new"
mv -f "$ARCUP_BIN_PATH.new" "$ARCUP_BIN_PATH"

The updater should fail closed when verification cannot be completed.

Tests

Add tests confirming that:

• a self-update with a mismatched checksum is rejected;
• an unsigned update is rejected when signatures are required;
• a downloaded file with only a higher version string is insufficient;
• the current executable is preserved when verification fails;
• updates are obtained from an immutable release reference;
• replacement is atomic.

Checklist

• Move self-update artifacts to immutable GitHub releases
• Add SHA-256 verification to self-update
• Configure and pin the Arc release-signing key
• Fail closed when authenticity cannot be verified
• Replace the executable atomically
• Add self-update integrity tests
• Document the update trust model

[osr21]

The report is accurate. A few things worth adding before a fix is implemented:

The naive partial fix doesn't help

The most common first instinct is to also download a .sha256 from the same mutable URL:

curl .../main/arcup         -o arcup
curl .../main/arcup.sha256  -o arcup.sha256
# verify...

This provides no security improvement. Both the file and its checksum come from the same mutable source — an attacker who can serve a malicious arcup can serve a matching arcup.sha256 alongside it. The checksum must come from a separately-trusted anchor that an attacker cannot simultaneously control. A pinned GitHub release tag is the right source: tags are immutable (force-pushing to a tag requires admin access and is auditable), so arcup.sha256 from releases/download/v0.2.0/arcup.sha256 is independently trustworthy in a way the main branch URL is not.

The infrastructure is already in the script

The self-update path doesn't need new primitives — verify_checksum_file() (line 653), compute_sha256() (line 385), and download_file() (line 308, with its GitHub API → gh CLI → curl fallback chain) are all already implemented and used by the node archive install at lines 779–785:

# Lines 779–785 — what node install already does correctly:
download_file "$VERSION_TAG" "${ARCHIVE_NAME}.sha256" "$TMP_DIR"
verify_checksum_file "$ARCHIVE_PATH" "$TMP_DIR/${ARCHIVE_NAME}.sha256" "$ARCHIVE_NAME"

The self-update fix is essentially wiring update_arcup() to follow the same pattern against a tagged release rather than the mutable main URL. The implementation lift is smaller than it might appear — the hard parts are already written.

GPG path is already stubbed

Lines 16–18:

# TODO: set GPG key fingerprint once release signing key is published
GPG_KEY_FINGERPRINT=""
GPG_KEYSERVER="keyserver.ubuntu.com"

And lines 788–809 show the node install already conditionally runs GPG verification when GPG_KEY_FINGERPRINT is non-empty. Self-update should run the same GPG block so that once a signing key is published, self-update integrity automatically improves without another code change.

Atomic replacement needs a same-directory tmpfile

The current code:

_ARCUP_TMP_FILE=$(mktemp)          # goes to /tmp
cp "$_ARCUP_TMP_FILE" "$ARCUP_BIN_PATH"  # non-atomic
chmod 755 "$ARCUP_BIN_PATH"

mktemp without -p creates the file in /tmp. On most Linux installs $BIN_DIR (~/.arc/bin or /usr/local/bin) is on a different filesystem from /tmp. A mv across filesystems silently falls back to copy-then-delete, losing atomicity — if the process is killed mid-copy the binary is corrupted. The fix for both problems:

_ARCUP_TMP_FILE=$(mktemp -p "$(dirname "$ARCUP_BIN_PATH")" arcup.XXXXXX)
# ... download, verify ...
mv -f "$_ARCUP_TMP_FILE" "$ARCUP_BIN_PATH"
chmod 755 "$ARCUP_BIN_PATH"

The tmpfile is already cleaned up by the existing _arcup_cleanup EXIT trap (lines 51–55), so no change needed there.

Sketch of the corrected flow

update_arcup() {
    # Resolve the latest arcup release tag from the GitHub API
    local remote_tag
    remote_tag=$(fetch_latest_release_json | extract_json_string_field "tag_name")
    # (or: derive it from ARCUP_INSTALLER_VERSION embedded in the release asset)

    local TMP_DIR
    TMP_DIR=$(mktemp -d)
    # (register TMP_DIR in _arcup_cleanup as well)

    # Download arcup and its checksum from the immutable tagged release
    download_file "$remote_tag" "arcup"        "$TMP_DIR"
    download_file "$remote_tag" "arcup.sha256" "$TMP_DIR"

    # Verify checksum (uses existing verify_checksum_file)
    verify_checksum_file "$TMP_DIR/arcup" "$TMP_DIR/arcup.sha256" "arcup"

    # Optional: GPG — mirrors what node install already does at lines 788–809
    if [[ -n "$GPG_KEY_FINGERPRINT" ]]; then
        download_file "$remote_tag" "arcup.asc" "$TMP_DIR"
        # ... same gpg --batch --verify block as line 802 ...
    fi

    # Atomic replacement: tmpfile on same filesystem as target
    local STAGING
    STAGING=$(mktemp -p "$(dirname "$ARCUP_BIN_PATH")" arcup.XXXXXX)
    cp "$TMP_DIR/arcup" "$STAGING"
    chmod 755 "$STAGING"
    mv -f "$STAGING" "$ARCUP_BIN_PATH"   # atomic on same filesystem
}

This requires arcup to be published as a release asset (alongside its .sha256 and optional .asc) at each tagged release, which is the right long-term structure regardless — it makes every released installer version permanently retrievable and verifiable.