cli: 'identity import' extracts secret keys with archive-controlled permissions and does not reject symlink members

[Dione-b]

Summary

ctg identity import (packages/cli/src/commands/identity.command.ts:87-104) unpacks an archive containing Stellar secret keys into ~/.config/stellar. The recent path-traversal hardening (464221b) closed the ../ case, but two gaps remain in untarDirectory (identity.command.ts:36-62).

1. Archive-controlled file permissions

await mkdir(targetDir, { recursive: true, mode: 0o700 });
await assertNoPathTraversal(archiveFile, targetDir);
await execa("tar", ["-xzf", archiveFile, "-C", targetDir], { stdio: "inherit" });

The 0o700 applies to the target directory only. GNU tar restores each member's recorded mode, so an archive whose entries are stored 0644/0666 yields world-readable secret keys inside a 0700 directory — and if any intermediate directory in the archive is stored 0755, the containing directory becomes traversable too. On a shared CI runner or multi-user host, that exposes signing keys to any local user.

The rest of the command is careful about exactly this (withSecureTempDir uses mkdtemp + rm, the staged archive is written with mode: 0o600) — the extraction step is the one place the guarantee is dropped.

2. Symlink escape is not covered by a name-only pre-check

assertNoPathTraversal runs tar -tzf and resolves each entry name against the target. It cannot see entry types. An archive containing:

link            -> symlink to /home/victim/.ssh
link/authorized_keys

passes the check — path.resolve(target, "link/authorized_keys") stays inside target — but extraction may write through the symlink created moments earlier by the same archive. This is the classic node-tar/Zip-Slip-adjacent symlink escape; GNU tar's defenses against it vary by version and flags, so relying on them implicitly is fragile.

There is also a TOCTOU gap in principle (list pass and extract pass are two separate reads of the file), though it is small here since the archive is staged in a 0700 temp dir the command itself owns.

Failure scenario

A developer follows a CI runbook and runs ctg identity import ci-identity.b64 on a shared build machine, using an archive produced by an untrusted or compromised pipeline. The archive's members are stored mode 0644; every other user on that host can now read the deployer's Stellar secret key. A second archive with a symlink member writes into ~/.ssh/authorized_keys instead of the Stellar config dir.

Suggested fix

• Extract with --no-same-permissions --no-same-owner and a restrictive umask (or chmod -R go-rwx the target immediately after extraction) so imported key material is never group/world readable.
• Reject archives containing symlink or hardlink members outright. tar -tvzf (verbose) exposes the type character, or switch to a library extractor with an explicit filter that rejects non-regular-file/non-directory entries.
• Consider --no-overwrite-dir and extracting to a fresh staging dir, then moving into place, so a partially-validated archive never touches ~/.config/stellar.

Scope: audit was read-only, no code changed. Related to the already-shipped traversal fix in 464221b — this is the remainder of that surface.

[Dan-tolu]

@Dan-tolu has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I'd be glad to handle this issue. I'll keep the implementation concise, maintainable, and well-documented.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Dan-tolu to this issue.

[Miss-shelby]

@Miss-shelby has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I'd like to work on this issue.
I've traced the relevant code and know where the fix needs to go, I'll scope it to the root cause (not a surface patch) and add a test to lock in the behaviour. I'm comfortable with the stack and can iterate quickly on review feedback. Could you assign it to me?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Miss-shelby to this issue.

[sunnykid-02]

@sunnykid-02 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on this issue because allowing identity import to extract secret keys with archive-controlled permissions can create a serious security risk. Sensitive key material should not inherit permissions or metadata that could make it accessible to unintended users or processes.

I have experience working with CLI applications, secure credential handling, filesystem permissions, and security-sensitive workflows.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @sunnykid-02 to this issue.

[drips-wave]

Congratulations, @Miss-shelby! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Miss-shelby: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊