v0.1.9

Changed

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

• Runs on PostgreSQL, MySQL/MariaDB or SQLite. The module now talks to the
  database through the shared kubuno-db foundation, so an administrator can
  pick the engine in configuration (database.engine) and the same build
  connects to whichever is named — no per-engine binary. The delta-sync layer
  (the local-first pull for calendars, events and time blocks) moved off
  PostgreSQL sequences and triggers onto a portable, application-driven change
  journal; array columns (event exception dates and cross-module links, time
  block weekdays) are stored as JSON arrays; and time-of-day columns round-trip
  identically on the three engines. Existing PostgreSQL installations migrate in
  place.

Security

• Meeting polls, bookings and RSVP answers are validated. A public poll answer
  can no longer name a time slot of another poll (which allowed overwriting
  someone's vote there), must carry a valid e-mail address and a known
  availability, and is refused once the poll is closed or expired. The public
  poll page no longer shows voters' e-mail addresses. A signed-in voter always
  votes under their own address. Public booking fields (name, e-mail, note,
  answers) and RSVP comments now have size limits.

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

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

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.