fix(templates): reject path traversal, absolute paths, and symlinks during archive extraction

[TheWeirdDee]

Closes #684.

Objective

Reject absolute paths, parent traversal, links, and files outside the destination root when extracting a downloaded/local .zip template package.

What was there before

templates::extract_zip_archive (src/utils/templates.rs) — used by both registry install (downloading a template archive from a remote registry) and local .zip template sources — already had a partial zip-slip guard:

let entry_path = match entry.enclosed_name() {
    Some(p) => p.to_path_buf(),
    None => continue,   // <-- silently skips the entry
};
...
if !out_path.starts_with(&dest_canon) {
    anyhow::bail!("... escapes the destination directory (zip-slip)");
}

enclosed_name() (from the zip crate) already returns None for entries with an absolute path or a .. component that would escape the archive root — so those were being caught. But two things were missing:

1. Absolute paths / parent traversal were silently skipped, not rejected. A malicious or corrupted archive would appear to extract "successfully" with the dangerous entries quietly dropped, rather than failing loudly. That's misleading — the caller has no idea the archive was tampered with.
2. Symlink entries were never checked at all. Nothing looked at the entry's Unix mode bits, so a symlink entry would just get written out as a regular file containing the literal target-path bytes — not itself an escape (this code never calls a symlink-creation API), but not what the issue asks for either ("reject... links").

What changed

• Absolute-path and parent-traversal entries (still detected via enclosed_name() == None) now make the whole extraction fail with a clear error naming the offending entry, instead of silently continuing to the next entry.
• Added an explicit symlink check via entry.unix_mode() (masking for S_IFLNK), which also rejects the whole extraction with a clear error.
• Kept the existing zip-slip (out_path resolves outside dest) check as a final defense-in-depth layer, since enclosed_name() already guarantees no ../absolute components make it that far — this check just makes the guarantee explicit rather than implicit.
• No behavior change for well-formed archives: the existing happy-path test (nested nested single nested directory → normalize_template_root → validate_template_structure) still passes unmodified.

Tests added

• extract_zip_archive_rejects_parent_traversal — an entry named ../escaped.txt fails extraction with a clear error, and nothing is written outside the destination.
• extract_zip_archive_rejects_absolute_path — an entry named /etc/passwd-clone fails extraction with a clear error.
• extract_zip_archive_stops_at_first_malicious_entry — a mixed archive (one legitimate file, one traversal entry) fails as a whole rather than partially extracting the legitimate file (boundary case: not a single-bad-entry archive).
• is_symlink_mode_detects_symlink_and_ignores_other_types — unit test for the Unix-mode classification helper (regular file / directory / symlink bit patterns). I couldn't construct an actual symlink zip entry through the safe zip::write::ZipWriter API for an end-to-end test — FileOptions::unix_permissions() masks off the file-type bits by design (zip 0.6.6 has its own test, unix_permissions_bitmask, confirming this), and start_file() always forces the S_IFREG bit. So the classification logic is unit-tested directly against synthetic mode values instead, which is what's actually security-relevant here (the bit-masking check), independent of how a real symlink entry would reach it.

Documentation

Added an "Archive Extraction (Client-Side)" subsection to REMOTE_REGISTRY_IMPLEMENTATION.md's existing ## Security section, describing exactly what gets rejected and why (compatibility/security note per the issue's acceptance criteria).

Testing performed

cargo test --lib templates:: currently cannot complete on master in this repo — building the full test binary hits ~20+ pre-existing, unrelated compile errors elsewhere in the tree (missing struct fields on TemplateEntry in template_recommender.rs/template_analytics.rs/templates.rs's own older fixtures, a type mismatch on changelog, a mutable-borrow issue in ai.rs, etc. — see #759 for the same issue surfacing on a different feature). None of that is caused by or related to this change, and I did not touch any of those files.

To validate this specific fix independent of that, I copied extract_zip_archive + is_symlink_mode and the new tests into an isolated scratch crate (dependencies: anyhow, zip = "0.6", tempfile, matching what's pinned here) and ran them there:

running 5 tests
test tests::is_symlink_mode_detects_symlink_and_ignores_other_types ... ok
test tests::extract_zip_archive_rejects_parent_traversal ... ok
test tests::extract_zip_archive_rejects_absolute_path ... ok
test tests::extract_zip_archive_stops_at_first_malicious_entry ... ok
test tests::extract_zip_archive_happy_path ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

cargo fmt --check on the touched file is clean.

[drips-wave]

@TheWeirdDee Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Manuelshub]

@TheWeirdDee Please all failing CIs

[Manuelshub]

@TheWeirdDee Please resolve conflicts!!!!