v0.1.9

Changed

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

• Runs on PostgreSQL, MySQL/MariaDB or SQLite. The module moves off a
  PostgreSQL-only stack onto the runtime-dispatch kubuno-db foundation, so a
  single binary connects to whichever engine the administrator chooses at run
  time ([database] engine). Existing PostgreSQL instances are unaffected: their
  migrations are unchanged and re-used as-is.

Fixed

• 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.

• The no-code data engine's filters work identically on every engine. The
  dynamic "Things" search (equals / contains / greater-than / in / is-empty …),
  which addresses arbitrary JSON keys chosen by the app builder, previously used
  PostgreSQL's ->> operator, whose path semantics differ on MySQL. Every JSON
  access now goes through a portable extraction that binds the key as data and
  emits the right form for the running engine, so the same app behaves the same
  everywhere. A record update's field merge (formerly PostgreSQL's data || patch) is computed in Rust so a null-valued key is treated identically on all
  three engines.

Security

• Data written by visitors and shared users is checked against the app's data
  types. On a published or shared app, a new or changed record must belong to a
  declared data type and contain only its declared fields, each with a value of
  the right type (text, number, yes/no, date, or one of an option's choices) and
  within size limits; anything else is refused. Changing or deleting a record
  through a published or shared app now only works on a record of the type named
  in the request, so a visitor can no longer alter or delete records of other
  (for example private) data types.

• Images, video and audio in apps and reports, PDF report images and collaborative editing no longer
  rely on the access-token cookie the web client used to keep readable by page scripts, nor put the access
  token in a WebSocket URL. Private addresses are signed when they are displayed and stay plain in the
  app definition; published apps viewed anonymously behave as before. 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.

• Dynamic queries stay parameterised across engines. The no-code query
  builder (filters, sort, pagination) is rebuilt on kubuno-db's DbQueryBuilder
  under SqlSafeStr: the query structure is fixed text and every value — the
  JSON key included — is a bound placeholder, never interpolated, closing any
  path to SQL injection through a builder-supplied field name.

Security

• 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. An unsoundness in the event-listener it relies on
  (RUSTSEC-2026-0221) is closed at the same time.
• 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.