v1.8.1

v1.8.1 — 2026-10-16

Pakko creates 7z archives, and "Test" works for every archive it reads. Plus the fixes found by
walking every on-device check of v1.8.0 by hand. The two that matter most: on Windows 10, Windows
11 up to 23H2 and Windows Server 2022 Pakko refused Windows' own tar.exe, so no tar, 7z or RAR
archive could be opened, extracted or made there; and keys on a list row selected from the
keyboard have done nothing since v1.7.2, the first Native AOT build.

Added

• T-F342 - 7z archives can be created: 7Z in the App's Format list (second, after ZIP), Add to
  "name.7z" in the Explorer menu, pakko a -t7z (also -m0=lzma2|lzma|bzip2|deflate|copy),
  Archiver.Shell.exe --archive --format 7z. They are written by Windows' own tar.exe, which has
  the 7z writer in recent Windows releases: Pakko asks it once, and where it cannot write 7z the
  format is not offered. No password: the writer has no encryption, so a password for 7z is
  refused before anything is written. The writer's temporary file is kept next to the archive,
  not in %TEMP%. Group Policy's sevenzip format name covers creation too.
• T-F397 - "Test" for 7z, RAR and the tar family (tar, gz, bz2, xz, zst, lzma) in pakko t,
  the Explorer menu and the App. tar.exe reads every entry inside the sandbox and writes nothing.
  Where it compares the contents' checksums (7z, bz2, and xz or zst written with a check) a pass
  is "no errors"; for tar, gz, lzma and RAR a pass says that only the structure was checked.
  Recovery data (PAR2) works on a 7z end to end.

Fixed

• T-F389 - a file extracted from a tar, gz, bz2, xz, zst, lzma, 7z or rar archive has the
  permissions of the folder it is extracted into. Before, it kept an entry for Pakko's sandbox
  and a Low integrity label and did not inherit from that folder, so on a shared folder other
  people could be left without access to it. Files extracted by earlier versions are not changed:
  SECURITY.md ("Permissions of Files Extracted by Earlier Versions") says how to find and repair them.
• T-F380 - in the App, Delete removes the focused row of the list, Shift+F10 and the menu key
  open its menu, and Enter opens the focused row of the archive view. Under Native AOT the three
  did nothing; the mouse worked.
• T-F381 - with "Encrypt with password" on, the "Add recovery data (PAR2)" row stays in view:
  it is above the encryption rows now, and the card scrolls the password boxes into view.
• T-F382 - testing or extracting a ZIP entry whose compressed data is damaged says "The
  compressed data is damaged." where it showed .NET's "unsupported compression method".
• T-F383 - after "Skip" for every conflict the App says "Nothing was done - skipped: N", not
  "Extracted - archives: 0".
• T-F379 - a killed pakko a no longer leaves its hidden chunk folder behind until a later
  large run: any archive creation in that folder removes it.
• T-F385 - the Explorer operation window's password page no longer cuts its buttons.
• T-F387 - a long label (German) no longer pushes the PAR2 percentage box past the card's edge.
• T-F390 - when a selected file or folder is deleted while a tar or 7z archive is being
  created, Pakko names it; tar.exe's own message named a wrong path.
• T-F391 - a junction or symbolic link inside a folder being archived as tar or 7z is left out
  and reported, as ZIP always did. Before, tar.exe followed a junction (packing files from outside
  the selection) and stored a symbolic link with its absolute target.
• T-F398 - pakko l, x and t, the App and Explorer read a tar.lzma archive. Pakko
  writes tar.lzma but answered "not a recognized archive format" for one: an .lzma stream has no
  signature, so the name now decides when the bytes name no other format.
• T-F401 - Pakko runs Windows' tar.exe on Windows 10, Windows 11 up to 23H2 and Windows
  Server 2022 again. There tar.exe is signed through a Windows catalog, not with a signature of
  its own, and Pakko's check accepted only the latter: it refused tar.exe with "failed
  Authenticode signature verification", so every tar, gz, bz2, xz, zst, lzma, 7z and RAR
  action failed. The check accepts both kinds now and still requires Microsoft as the signer.
  What each system can then do depends on its tar.exe (T-F403): Windows 10's has zlib only, so
  it gets tar and tar.gz back; Server 2022's, with its updates, adds RAR.
• T-F402 - Pakko no longer offers 7z or tar.zst where tar.exe cannot do them. The tar.exe
  of Windows 10 and of Windows Server 2022 is built without LZMA, bzip2 and zstd: 7z, which
  nearly always uses LZMA, failed with tar.exe's own error. 7z now also needs LZMA in tar.exe,
  and tar.zst needs zstd.
• T-F403 - what Pakko offers follows what this system's tar.exe can do, everywhere. The
  App's Format and 7z method lists, pakko a, pakko i and the Explorer menu all take it from
  one rule over the libraries built into tar.exe. Before, creating tar.bz2, tar.xz, tar.zst or
  tar.lzma was offered on every system, and on a tar.exe without that library it either failed
  with tar.exe's own text or, for tar.zst and tar.bz2, made tar.exe run a program named
  zstd.exe or bzip2.exe from the current folder or PATH, outside the sandbox. Such a
  creation is now refused before tar.exe starts, naming the missing codec. Once Pakko has run
  once (the App, any item of the Explorer menu, or pakko from the installed package), the
  Explorer menu no longer offers Extract or Test for an archive this tar.exe cannot read; before
  that, Pakko refuses it when the item is used.

Changed

• pakko a x.7z src with no -t is now exit 7 and writes nothing: a .7z name needs -t7z.
  Before, it wrote a ZIP named x.7z.
• pakko t on a tar-family, 7z or RAR archive tests it: exit 0 for 7z, tar.bz2, and tar.xz
  or tar.zst written with a check (as tar.exe writes them); exit 1 with the warning "Only the
  archive's structure was checked" for tar, tar.gz, tar.lzma, RAR and an xz or zst stream without
  a check; exit 2 for a damaged one. Before, all of them were exit 1 with "no test
  capability". Scripts that read the exit code of t should expect this.
• The Explorer submenu lists the formats as zip, 7z, tar, as the App does.
• T-F386 - with Arabic, Hebrew or Urdu the App's window and dialogs are laid out right to
  left, as the Explorer operation window already was.
• T-F388 - under the AllowedFormats, BlockedFormats or DisableTarExtraction policy the New
  archive card lists only the formats that may be created.
• T-F384 - the App's two lists have names for screen readers.
• T-F377 - pakko.exe declares per-monitor DPI awareness, the one finding of the Windows App
  Certification Kit for v1.8.0.
• Built with the .NET 10.0.13 runtime (SDK 10.0.402).

Known issues

• Those of v1.8.0 still apply.

---

pakko.exe — standalone CLI

Download the zip for your architecture below (pakko-win-x64.zip or pakko-win-arm64.zip), then
verify it against SHA256SUMS before running it:

Get-FileHash .\pakko-win-x64.zip -Algorithm SHA256

Compare the printed hash against the matching line in SHA256SUMS.

Each zip and MSIX has a CycloneDX SBOM next to it (pakko-win-<arch>.cdx.json,
pakko-msix-<arch>.cdx.json) listing the components it ships, attested by this repository's CI:
gh attestation verify pakko-win-x64.zip -R pakkoapp-oss/pakko --predicate-type https://cyclonedx.org/bom.

pakko.exe runs standalone — no installation, no GUI/MSIX required. See docs/CLI.md for the full
command reference.

---

Pakko — MSIX (GUI app)

Prefer the Microsoft Store if you just want to install Pakko without warnings:
https://apps.microsoft.com/detail/9p5mw010d8pr — Microsoft's own signature, no SmartScreen/
AppLocker friction, auto-updates.

The .msix/.msixbundle below is instead signed with a self-signed development certificate,
not a publicly trusted one — installing it will trigger SmartScreen/AppLocker warnings, and it
will not sideload at all unless the signing certificate is explicitly trusted on the target
machine first (see scripts/README.md). It exists for testing a specific pre-release build, or
for environments that can't use the Store. Public code-signing for this direct-download path is
still being worked (see docs/TASKS.md's T-F10).

The package needs the Windows App SDK 2.5 runtime (framework package
Microsoft.WindowsAppRuntime.2, 2.5.1 or later). A Store install brings it along; if a sideloaded
install reports a missing dependency, install that runtime from
https://learn.microsoft.com/windows/apps/windows-app-sdk/downloads first. Since v1.7.2 this
replaces the 1.8 runtime earlier versions used.