Post-mortem: the previous implementation of PruneStaleFiles walked
Directory.EnumerateFiles(clientRoot, "*", SearchOption.AllDirectories)
and deleted anything not listed in the current manifest. That made
clientRoot unsafe to set to anything other than a dedicated install
directory. Because clientRoot is Directory.GetCurrentDirectory(), any
user who ran Metin2Launcher.exe from their home directory (or worse,
from a parent directory containing other projects) would have had
every unrelated file in that tree silently deleted — including
.ssh keys, .bashrc, docs, source trees. One of Jan's colleagues
hit exactly this tonight and lost a significant chunk of their home
directory.
The blast radius was enormous and entirely my fault. This commit
switches prune to a strict ledger-based model so the launcher can
ONLY delete files it itself wrote:
.updates/applied-files.txt — newline list of relative paths this
launcher has ever successfully
installed into clientRoot.
On prune:
1. Read the ledger.
2. For every entry not in the current manifest's file set (plus
the top-level launcher.path), delete the file at that relative
path inside clientRoot — if and only if PathSafety.ResolveInside
accepts the resolved path (defense against traversal/symlinks).
3. Rewrite the ledger to exactly match the current manifest.
Files the launcher never wrote are invisible to prune. A fresh
install dir has no ledger, so prune is a no-op on the first run and
subsequent runs only touch files listed in the ledger. Even if a user
points the launcher at ~/ with valuable data, prune cannot touch
anything it didn't put there.
Other hardening:
- PathSafety.ResolveInside is now invoked for every prune target, so
a maliciously crafted manifest can't name "../../etc/passwd".
- Ledger write happens after apply so a crash mid-apply doesn't
leave a stale ledger that would prune real user files on the next
run.
Immediate mitigations taken outside this commit:
- Pulled the published Metin2Launcher.exe off updates.jakubkadlec.dev/
launcher/ and replaced it with a README.txt warning, so no new user
can download the dangerous binary.
- Will rebuild and re-upload the safe binary before re-announcing.
Followup:
- Add a Gitea issue documenting the incident and the ledger contract.
- Tests for the ledger read/write and for the "ledger empty = no
prune" safety case.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
metin-launcher
Self-updating launcher for the Metin2 client.
This is the single entry point the player runs. It fetches a signed manifest from
updates.jakubkadlec.dev, verifies an Ed25519 signature against a compiled-in
public key, reconciles the local client against the manifest by sha256, downloads
anything that differs from a content-addressed blob store (with HTTP Range resume),
applies updates atomically, hands launcher self-update off to Velopack, and then
starts Metin2.exe. If the update server is unreachable the launcher falls back
to launching whatever the player already has.
Architecture and failure modes live in the client repo under
docs/update-manager.md and docs/update-manifest.md. This project implements
those specs in C# .NET 8; it does not own the spec.
Build
dotnet build Launcher.sln -c Release
dotnet test
Tests are xUnit and run on Linux. A local HttpListener stands in for the blob
server in BlobDownloaderTests.
Publish (Windows single-file)
dotnet publish src/Metin2Launcher/Metin2Launcher.csproj \
-c Release -r win-x64 --self-contained \
-p:PublishSingleFile=true
The CI hasn't been wired yet; the MVP only requires the build to succeed.
Publishing a release
scripts/publish-launcher.sh is the single entry point for cutting a Velopack
release of the launcher and pushing it to the
https://updates.jakubkadlec.dev/launcher/ feed that
LauncherConfig.VelopackFeedUrl points at. It runs dotnet publish for
win-x64 self-contained single-file, then drives vpk pack (Velopack CLI
global tool, auto-installed on first run) with --packId Metin2Launcher --channel win-x64 --mainExe Metin2Launcher.exe, and finally rsyncs the
resulting RELEASES-win-x64 + *.nupkg (full + delta) to the VPS.
scripts/publish-launcher.sh --version 0.1.0 --dry-run
scripts/publish-launcher.sh --version 0.1.0 --yes
Flags: --version (required), --dry-run (build + pack but skip rsync),
--yes (skip the interactive rsync confirmation), --rsync-target (override
the default VPS path).
Known limitation (2026-04-14): Velopack's vpk pack is platform-routed.
On a Linux host it only builds Linux .AppImage bundles and refuses to pack
the win-x64 publish output (it tries to ELF-parse Metin2Launcher.exe and
crashes with Given stream is not a proper ELF file). Building the win-x64
Velopack release therefore needs a Windows host. The script is correct —
it's the toolchain that's gated. Once we have a Windows CI runner this can
be wired into Gitea Actions; until then run the script on a Windows dev box.
The dotnet publish step on Linux still works and is a useful sanity check.
Run
By default the launcher opens an Avalonia GUI window (900x560, fixed size)
showing a banner, status / progress on the left and a news panel on the right.
Pass --nogui to run the legacy headless flow that just logs progress and
launches the game when done — useful for CI or unattended boxes.
Metin2Launcher.exe # GUI (default)
Metin2Launcher.exe --nogui # headless, log + launch
User settings (locale, dev-mode override) live at
<client>/.updates/launcher-settings.json. The manifest URL override is only
honoured when DevMode is true so a tampered local file alone cannot redirect
updates.
Drop Metin2Launcher.exe next to Metin2.exe in the client install directory
and run it. On first launch it will:
- fetch
https://updates.jakubkadlec.dev/manifest.json+.sig - verify the signature against the compiled-in public key
- hash every file listed in the manifest, download anything that doesn't match
into
.updates/staging/, then atomically move each one into place - check for a Velopack launcher update against the feed at
https://updates.jakubkadlec.dev/launcher(skipped cleanly on non-installed dev builds) - start
Metin2.exe
A log is written to both stdout and <client>/.updates/launcher.log. On a plain
dotnet run (no client root yet), the log falls back to
%LOCALAPPDATA%/Metin2Launcher/launcher.log on Windows or
$XDG_DATA_HOME/Metin2Launcher/launcher.log on Linux.
Project layout
src/Metin2Launcher/
Program.cs entry: Velopack bootstrap, --nogui switch, Avalonia host
Config/LauncherConfig.cs hardcoded URLs, timeouts, public key
Config/LauncherSettings.cs user settings (locale, dev-mode override) JSON
Orchestration/ update flow extracted from CLI, IProgress driven
Manifest/ DTOs, HTTP loader, Ed25519 verifier
Transfer/ streaming sha256, Range-resume blob downloader
Apply/ atomic staging -> final move
GameLaunch/ CreateProcess wrapper
Logging/ hand-rolled file + stdout logger
Localization/ cs.json + en.json embedded resources, Loc loader
UI/ Avalonia App, MainWindow, SettingsDialog
UI/ViewModels/ MVVM view models
tests/Metin2Launcher.Tests/
Dependencies
- Avalonia 11 — cross-platform GUI (Linux + Windows from one csproj).
- CommunityToolkit.Mvvm —
ObservableObject+[RelayCommand]source generators. - NSec.Cryptography — libsodium-backed Ed25519 (.NET 8 BCL does not have it).
- Velopack — launcher self-update. Only used for the launcher binary itself; game assets (~4 GB) are handled by our own patcher code.
- xunit / xunit.runner.visualstudio — tests.
Release formats
The launcher dispatches on a top-level format field in the signed manifest.
Two strategies exist today:
legacy-json-blob(default whenformatis absent) — individual files listed infiles[], downloaded by sha256 and atomically replaced inside the client root.m2pack— thefiles[]entries are.m2ppack archives plus aruntime-key.jsonsidecar. The launcher never opens or decrypts.m2parchives; it just places them next to the client root and forwards the runtime key toMetin2.exevia environment variables (M2PACK_MASTER_KEY_HEX,M2PACK_SIGN_PUBKEY_HEX,M2PACK_KEY_ID).
A manifest whose format value is signed but unknown is refused outright —
the orchestrator falls back to offline mode rather than silently downgrading.
See docs/m2pack-integration.md for the full threat model and file layout.
An opt-in "client applied this release" telemetry ping is available via
LauncherConfig.TelemetryUrlTemplate. It is empty by default, which short-
circuits the reporter so no network call is made. When set, the reporter
fires a single bounded (5s) best-effort POST after a successful apply and
swallows any failure.
Signing key
LauncherConfig.PublicKeyHex is the Ed25519 public key that every manifest
must verify against:
1d2b63751ea0e0354d28e7eb4ec175919a01518b0bcf5878f0a3aa8e7c6ce2bc
The matching private key lives only on the release machine at
~/.config/metin/launcher-signing-key with chmod 600, is never committed
to any repo, and is used by scripts/sign-manifest.py in the m2dev-client
repo to sign manifest.json before upload. Rotation is done by shipping a
new launcher binary that embeds the new public key; the rotation flow is
documented in m2dev-client/docs/update-manager.md.