Windows portable .zip release asset is actually a TAR archive

[wangzexi]

Description

The latest Windows portable release asset is named Hiddify-Windows-Portable-x64.zip, but its contents are an uncompressed GNU/POSIX TAR archive rather than a ZIP archive. This prevents normal Windows ZIP extraction.

Affected asset:

• Release: v4.1.1
• Asset: Hiddify-Windows-Portable-x64.zip
• Published SHA-256: 5099b3df2d21f1bb0c1cbf28dfa9fc6fa817e7eea77a0efe4daf93f571aae418

Reproduction

A range request is enough to identify the format:

curl -fL --range 0-1023 \
  -o Hiddify-Windows-Portable-x64.head \
  https://github.com/hiddify/hiddify-app/releases/download/v4.1.1/Hiddify-Windows-Portable-x64.zip

file Hiddify-Windows-Portable-x64.head
# POSIX tar archive (GNU)

od -An -tc -j257 -N8 Hiddify-Windows-Portable-x64.head
# u s t a r

The first bytes contain the TAR member name Hiddify/; a real ZIP should begin with a ZIP signature such as PK\x03\x04.

Root cause

The regression was introduced by ccdd8a748e49b3816f5e8be1a18a145bca1d19ad, which added portable ZIP post-processing using:

tar -a -cf "$FILE_NAME.zip" Hiddify

The Windows build path resolves tar to GNU tar. GNU tar's --auto-compress / -a recognizes compressor suffixes such as .gz, .bz2, .xz, and .zst, but not .zip. It therefore writes an ordinary TAR archive while preserving the misleading .zip filename.

Reference: GNU tar auto-compress suffixes

Proposed fix

Use the 7-Zip CLI already installed on GitHub-hosted Windows runners and select ZIP explicitly:

7z a -tzip "$FILE_NAME.zip" Hiddify

This preserves the intended top-level Hiddify/ directory and produces a genuine ZIP archive. A focused local check confirmed a PK\x03\x04 signature, successful Python zipfile extraction, and a successful 7z t integrity test.