fix(utils): reject tar hardlinks that escape the extraction root

[Zelys-DFKH]

Description

ExtractArchive in pkg/utils/untar.go walks archive members before extracting and rejects two things: member paths that resolve outside the destination, and symlinks. Tar hardlink entries are covered by neither. Header.FileInfo() reports a regular file mode for a hardlink, so the symlink test does not match, and Header.Linkname is never inspected. An archive can therefore name a link target outside the extraction directory and the extractor will create it.

This passes Linkname through the same validation already applied to member names, so a hardlink pointing outside the extraction root is rejected with the existing "unsafe path" error. Hardlinks whose target resolves inside the root still extract normally, so ordinary archives are unaffected.

pkg/oci/image.go already handles this on the OCI image path, resolving tar.TypeLink targets against the extraction root before using them. This brings the archive path in line with it.

Notes for Reviewers

Three tests cover this, all in pkg/utils/untar_test.go.

rejects tar hardlinks that point outside the destination writes a tar holding a single tar.TypeLink entry whose Linkname is ../escaped.txt, then asserts extraction fails and nothing lands outside the destination. Without the fix it fails, and the failure output shows the underlying archiver attempting to create the link outside the extraction directory.

rejects tar hardlinks that overwrite a file outside the destination uses a .tar.gz, which is where ExtractArchive binds a Tar config with OverwriteExisting set, and follows the link entry with a regular entry of the same name. Without the fix that pair links to a file above the extraction root and then truncates it through the link, so ExtractArchive returns nil and the outside file comes back holding the archive's contents instead of its own. The plain .tar case never reaches the write.

extracts tar hardlinks that stay inside the destination links to an earlier member of the same archive and expects extraction to succeed, so the new check is not rejecting ordinary archives.

The full pkg/utils package passes on Linux with go1.26.0, 59 specs. gofmt -l and go vet ./pkg/utils/ are clean. golangci-lint would not run because the released binary is built with Go 1.25 while the module targets 1.26.0.

Unrelated to this change and not touched here: the same package's suite hangs on Windows. InTrustedRoot in pkg/utils/path.go loops for path != "/", and filepath.Dir on a Windows volume root returns its input unchanged, so the loop never terminates. I mention it only to explain why I verified on Linux.

Signed commits

• Yes, I signed my commits.
• Documentation updated (docs/content/) for user-facing changes, or not applicable

[localai-org-maint-bot]

Reviewed the hardlink target validation and its interaction with mholt/archiver: tar hardlinks are resolved as filepath.Join(destination, Linkname), so applying the existing archive-member path validation to Linkname closes the escape while retaining in-root links. The focused archive suite passes locally (8/8), and go vet ./pkg/utils/..., gofmt, and git diff --check are clean. The unrelated full-package failures here were only missing ffmpeg and unavailable DNS. Good to merge. @mudler