Security release for the 1.23 line. It fixes three issues found while reviewing the 2.0 work; please upgrade. No migrations, no configuration change, except the note below for instances that reach calendars or resource feeds on private IPv6 or benchmark addresses.
Upgrade note: the private-address check now also treats 64:ff9b:1::/48 (local NAT64) and 198.18.0.0/15 as private, along with every IPv6 private and link-local range. Resource feeds are re-checked on every fetch, so a feed on such an address stops until its host is on the private-host allowlist; CalDAV and EWS sources are only checked when saved.
Security
- New users always get a scheduling account of their own (#371) - Under certain conditions, a new user (registration, single sign-on auto-registration or
calrs user create) could be attached to an existing user's scheduling account, with its event types, bookings and calendars. A new user now always gets a new account. At startup, an account left without a user is only linked to a user with the same address who has no account yet, and gets no new user when its address matches an existing user's except for letter case or spaces; otherwise it stays unlinked and a warning names it in the log for the administrator to review. A single sign-on login that changes a user's address now also updates the copy kept on their account. Registration also stores the email address without surrounding spaces. - The private-address check missed most IPv6 private ranges - It only matched
fc00::/16andfd00::/16, so a unique local address such asfd12:3456::1passed as public, and onlyfe80::/16of the link-local range. It now coversfc00::/7,fe80::/10, site-localfec0::/10, IPv6 multicast, IPv4 multicast, broadcast and240.0.0.0/4,0.0.0.0/8and198.18.0.0/15, and judges IPv4-mapped (::ffff:a.b.c.d), IPv4-translated (SIIT,::ffff:0:a.b.c.d), IPv4-compatible (::a.b.c.d), NAT64 (64:ff9b::/96) and 6to4 (2002::/16) addresses by the IPv4 address they carry. Upgrade note: some addresses that used to pass now need the host on the private-host allowlist (CALRS_ALLOW_PRIVATE_HOSTSor Admin panel, System settings), notably64:ff9b:1::/48(RFC 8215 local-use NAT64) and198.18.0.0/15, which is also the default fake-IP range of Clash and sing-box: a host resolving there through such a proxy is refused. Resource feeds re-check their address on every fetch, so an affected feed stops syncing until its host is allowlisted; calendar source URLs are checked when they are saved (added or edited), so existing sources keep syncing. - SSO linking no longer takes over an account through a recycled address - An SSO login with a verified address belonging to a calrs account already linked to another identity (an address the identity provider reassigned to a newcomer) linked the newcomer to that account, handing them the previous holder's calrs account. Linking by address now only applies to an account no identity is linked to yet; otherwise the login is refused and an administrator decides.