skillctl: Path traversal and symlink-follow in skillctl allow arbitrary file disclosure and deletion

Impact

skillctl 0.1.0 and 0.1.1 contained four path-safety vulnerabilities that, in combination, allowed an attacker to:

1. Exfiltrate arbitrary files on the operator's machine by publishing a malicious skills library containing a symlink inside a skill folder (e.g. niania → /home/user/.aws/credentials). The symlink fell through entry.file_type().is_dir() in fs_util::copy_dir_all, was dereferenced by fs::copy, and the target's content was copied into the project. A subsequent skillctl push would have published the secret to the (possibly public) library — what the reporter called "round-trip path exfiltration".

2. Delete arbitrary directories outside the project or library root by crafting a .skills.toml with a malicious destination or source_path field. Both were deserialized as PathBuf with zero validation. Because Path::join lets an absolute right-hand side replace the base, destination = "/home/user/.ssh" made cwd.join(...) resolve outside the project; .. traversal was equally unguarded. Downstream remove_dir_all in replace_folder_contents then wiped arbitrary writable directories on skillctl pull / push / detect. .skills.toml is the exact kind of file teams commit and exchange via PR; a single merged malicious PR was sufficient to weaponise the maintainer's next skillctl pull --all.

3. detect --target accepted .. traversal, even though absolute paths were rejected. --target ../../../etc would have written outside the library root.

4. Fork-name validation accepted . and .. literally, so a fork named .. would have produced a Path::join resolving to the parent directory and could have clobbered it.