James Dansereau
5ea053667f
The campaign has 20 playable missions (SP_LEVEL_MAX // 20 in bondconstants.h; mission_folder_setup_entries in front.c has exactly 20 entries). The old '21' counted -level_54 (LEVELID_CUBA), which the front end jumps to after the final mission for the extended cast display + credits scroll (do_extended_cast_display / bondviewRenderCredits, D129) - it is not a selectable mission. - README, docs/index.md, .github/release-notes.md, docs/security-and-fidelity-status.md: 21 -> 20 in current-status claims - AGENTS.md phase status: same correction - docs/dev/LEVEL-STATUS.md + LEVEL-PLAYTEST.md: relabel the level list; counting note explains historical '21/21 PASS' sweep results = 21 stage boots (20 missions + ending sequence) - social-preview card: stat line 21 -> 20, PNG regenerated (1280x640)
5.5 KiB
Security & fidelity status
This page answers two questions plainly: what does installing this put on
your machine, and how faithfully does the port actually reproduce the
original N64 game's logic. Both were reviewed end-to-end on 2026-09-15 and
re-verified for the v0.3.0 release bundles on 2026-09-18 (bundle contents,
no-networking source check, and the asset converter). The full engineering
record behind each item is in the project's finding log
(docs/dev/findings.md).
What a release actually installs
Each release (goldeneye-pc-port-*-win64.zip / -linux-x86_64.tar.gz)
contains, and only contains: the game engine executable, a fixed set of
standard runtime libraries (SDL2, zlib, and the MinGW/Linux runtime — no
third-party downloads), the one-time ROM-to-PC asset converter, a README,
and license texts. The build scripts hard-fail if a ROM image or an
oversized blob ends up in the bundle. No ROM, no game assets (textures,
audio, models, levels, text) are ever shipped — you supply your own
legally-owned copy.
At runtime, the engine:
- has no networking of any kind (no sockets, no HTTP, checked directly against the source),
- has no telemetry, crash reporting, or analytics of any kind,
- never touches the Windows registry and never requests elevated permissions,
- writes save data, config, and derived ROM assets only inside its own
folder — never to
%APPDATA%,Program Files, or any system location.
The one-time asset converter (ge007-convert / prepare-assets.py) — the
part of the bundle most likely to draw suspicion, since it's the thing that
reads your ROM and writes new files — has no network access at all,
verifies your ROM against a fixed table of known retail GoldenEye 007
hashes before touching it (an unrecognized file is rejected outright), and
writes only inside the bundle folder. Its full source ships right next to
the compiled version in every release if you'd like to read it yourself.
See SECURITY.md for why the binaries are
unsigned and what that means in practice (a SmartScreen prompt on first
run, and why some antivirus engines flag the converter specifically).
Building from source
Cloning and building pulls in only standard, well-known packages: MSYS2
pacman packages on Windows, apt packages on Linux — no npm, no
cargo, nothing downloaded at CMake configure time, no git submodules, and
no prebuilt binaries checked into the repository. One real gap: the CI
build installs pyinstaller from PyPI without pinning a version, which is
used to freeze the release's asset-converter tool. It's a widely-used
packaging tool, and what it packages is entirely in-repo, stdlib-only
Python — but an unpinned dependency means a future PyInstaller release
could change what ships without a corresponding diff in this repository.
Pinning it is a tracked follow-up.
One development-only backdoor exists in source builds: the GE_DEBUG_UNLOCKALL
environment variable (src/game/file2.c) pre-unlocks all cheat options at boot.
It is off unless explicitly set, changes no shipped behavior, and is documented
here so the env-var surface stays fully accounted for.
Fidelity to the original N64 game
The port's non-negotiable rule is that decompiled game logic is never
changed — only genuine N64-hardware dependencies get a PC-side
replacement, in the port/ layer. This was audited directly:
- Region build macros exactly mirror the original N64 Makefile's macro sets for all three regions — verified line-by-line.
- The audio/library file classification (which original files compile vs. get PC-shimmed) exactly matches the project's own ground-truth manifest — no silent gaps, no silent duplicates.
- The one shipped game-logic-adjacent change (a portal-culling
float-precision fix, D271) is
#ifdef PORT-gated, documented in the finding log, and moves toward matching N64 behavior, not away from it. Every other deviation from the decompiled source is one of the documented 32→64-bit pointer-width ABI corrections described above.
One issue, found and fixed before v0.3.0 shipped: the port's
random-number generator (port/src/random.c) was documented as a bit-exact
port of the N64's PRNG, but wasn't — a shift-operation helper didn't match
the real MIPS64 instruction semantics it was meant to mirror. This was
independently confirmed by hand-tracing the assembly against the C port,
tracked as finding D284, and fixed before the release (verified clean
across a full level sweep — all 20 missions plus the ending sequence —
no crashes). It affected loot placement, AI
behavior variance, and replay-state determinism from the very first random
draw, in every release before v0.3.0. Because of the fix, RNG-derived
output — including the save-file CRC — changed, which meant existing save
files and any previously recorded replays no longer validate; v0.3.0's
release notes describe the automatic save migration that handles this. We'd
rather say this plainly than let a "verified bit-exact" claim stand
uncorrected, both when it was wrong and now that it's fixed.
Everything else checked (the documented ABI/pointer-width exceptions used for the 32-to-64-bit transition, a sample of the finding log's own claimed fixes against the actual current code) matched what's documented.
This page is kept current alongside future releases. Its source review is a manual, human-reviewed process today — see the project roadmap for plans to partially automate the mechanical parts of it.