v0.1.9

Changed

• Visual Studio solution versioned with the repository (Kubuno.Maps.slnx, generated by vskubuno, the naming of
  every Kubuno repository): the server is the project Kubuno.Maps.Server, the frontend Kubuno.Maps.Web, in
  the solution folders Server, Libraries and Frontend, with the shared launch profile "Maps (Kubuno Core + browser)".
  The crate and npm names do not change.

Added

• Choice of database engine. Maps now runs on PostgreSQL, MySQL/MariaDB or
  SQLite, selected by the administrator at run time ([database] engine) from a
  single build — there is no separate binary per engine, and all three drivers
  ship in the one .kbpkg. SQLite makes a self-contained, server-less install
  possible.

Changed

• Saved-place and review tags are stored as a portable JSON array. They were
  held in a PostgreSQL-only array column; the same tags, tag filtering and
  behaviour now work identically on the three engines. Existing PostgreSQL
  instances are converted automatically on upgrade — the column is migrated in
  place and its index rebuilt — so no action is required and no data is lost.

Security

• The signed-in user is now taken from the core's signed identity token only. The module used to trust the
  plain X-Kubuno-User-Id / -Role / -Email headers, so any process able to reach its local port could
  act as any user, administrators included. It now accepts a request only with a valid X-Kubuno-Auth token
  signed by the core with this module's own secret, for this module, and not expired (kubuno-modauth); the
  plain headers are ignored. With no internal secret configured, every user request is refused. The /ipc/* guard now compares X-Internal-Secret in constant time and refuses every request when no secret is configured (an empty header used to match an empty secret).

• The 3D sky view (textures, star catalogue, constellations) no longer relies on the access-token cookie
  the web client used to keep readable by page scripts: textures load with signed tickets, data files
  with your session. Requires a Kubuno core that issues signed tickets (POST /api/v1/auth/tickets) and @kubuno/sdk with the signed-URL helpers.

• Security fixes from the shared database layer (kubuno-db 0.9.0). The
  database password can no longer appear in a log through the debug output of
  the database settings.

• GPX import can no longer be stalled or starved by a crafted file. The XML
  parser used to read uploaded .gpx tracks could be pushed into minutes or
  hours of pure CPU work by a single tag carrying a very large number of
  attributes, and into unbounded memory growth by a tag repeating namespace
  declarations. Either one, sent by anyone able to submit a track, could pin a
  worker thread or drive the module into an out-of-memory kill; no request
  timeout could interrupt it. The parser now bounds both.

• GeoIP database reader updated past an unsound memory-mapping API. The
  previous library exposed memory-mapped database access as safe even though a
  .mmdb modified on disk while in use could corrupt memory. Maps reads the
  database into memory rather than mapping it, so no instance was exposed, but
  the vulnerable code no longer ships at all.

• Input validation library updated. The version in use carried
  RUSTSEC-2024-0421 through its domain-name parser, which accepted Punycode
  labels that decode to plain ASCII — a mismatch an attacker can use to make two
  different names look like one.

• Database driver updated past an unfixable advisory. The previous line
  pulled in an RSA implementation vulnerable to a timing side-channel
  (RUSTSEC-2023-0071) for which no fix will ever exist. The new line does not
  depend on it at all, and it refuses any SQL string built at run time unless it
  has been audited — every such query here was checked and is now assembled
  at compile time, so none is built at run time at all.

Fixed

• Files kept on the server's local storage are found again on Windows and under symlinked storage
  roots (shared storage layer updated to kubuno-storage 0.1.2).
• Database migrations keep the same checksum on every OS. The repository now
  pins line endings to LF (.gitattributes), so a checkout on Windows no longer
  turns SQL migrations, scripts, manifests or sources into CRLF. A database
  migrated by a Linux build is therefore no longer refused by a Windows or macOS
  build of the same version because its migration checksums differ.