fix: harden calendar public sendmail against phishing via server-side link generation (OC10-123)

[DeepDiver1975]

Summary

Supersedes #1362. Hardens the public calendar "send mail" endpoint
(POST /v1/public/sendmail, EmailController::sendEmailPublicLink) against
being abused to send phishing mail from the ownCloud server identity — but
fixes the phishing link vector at the trust boundary instead of by
inspecting an attacker-supplied URL.

Why this instead of URL validation

#1362 accepted the link target as a verbatim url parameter and then tried to
prove, by string inspection, that it pointed at a public calendar route on this
instance. That validator needed three rounds of bypass patches (backslash
normalisation, percent-decoded traversal, an anchored route regex) and remained
inherently fragile against client-side URL normalisation. Validating untrusted
input by inspection is the wrong design here.

The only input actually needed to build the link is the public sharing
token — everything else the client sent was derived from it. So the API
contract changes from {to, url, name} to {to, token, name}:

• EmailController builds the absolute link itself via
  IURLGenerator::linkToRouteAbsolute('calendar.view.public_index_with_branding', ['token' => $token]).
  The result is same-origin and a genuine public sharing route by
  construction, and the token is URL-encoded by the generator — no injection
  or traversal surface remains.
• The entire isValidPublicCalendarUrl() inspection logic is deleted
  (~50 lines). An empty/missing token yields 400 Bad Request and no mail.
• The client (mailerservice.js / calendarlistcontroller.js) now sends
  calendar.publicToken instead of the pre-built publicSharingURL.

The HTML-escaping of the calendar name / user display name in the mail body
(the other half of #1362) is retained — that fix is still correct and
unrelated to the link vector.

Tests

tests/unit/controller/emailcontrollerTest.php:

• a valid token produces the router-generated public link and a mail carrying
  exactly that link is sent;
• an empty / null token is rejected with 400 and no mail is sent;
• injected markup in name and in the user display name is escaped in the
  rendered body (retained from fix: harden calendar public sendmail against phishing (OC10-123) #1362).

Full calendar unit suite passes locally (62 tests, 355 assertions).

Notes / follow-up

The residual, lower-severity behaviour flagged in #1362 is unchanged: an
authenticated user can still email a link to a legitimately public calendar
to an arbitrary recipient, because the token is still caller-supplied. Fully
binding the recipient/link to a calendar the caller actually published would
require a new public (OCP) API in core to resolve a public token to its owner
(the token→owner mapping lives in the dav app's private CalDavBackend), which
is out of scope for this app-level fix.

🤖 Generated with Claude Code

[jvillafanez]

Do we need any protection for the token? I'm not sure if I could send an almost-random token and get a valid link for the calendar of another user. Maybe it isn't a big problem because the calendar would be either public (so anyone can access) or be protected via access.

Maybe creating the token like <token><hash_data> where the hash_data is the hash of the token + user might help

newtoken = token + hash(token + user)

In the server, we use the user in the session to verify the token. The original token can be inferred because at least the hash has a fixed length. If the server creates the same "newtoken" from the original inferred token and the session user, then we can proceed to send the email.
It isn't perfect, but it should be easy to implement, and it should provide some protection.

[DeepDiver1975]

Good question — I dug into what the token actually is before deciding, and I don't think it needs extra protection in this PR:

• The publish token is a secure-random 16-char [A-Z0-9] value (~82 bits, generated via ISecureRandom in CalDavBackend::setPublishStatus() in the dav app), and the /p/{token} route (view#public_index_with_branding) is a @PublicPage. So the token is the access capability: anyone holding it can already view the calendar unauthenticated.
• The caller must already possess the token to send it (the client only ever derives it from the calendar's own publish-url), so this endpoint can't disclose a calendar that wasn't already reachable by that token. Guessing a valid token is a ~2^82 brute force — infeasible.

On the newtoken = token + hash(token + user) idea: it binds to the session user (the sender), not the calendar owner, so it wouldn't actually stop B from emailing A's public link — the server would just recompute the same hash for B's session with any token. To actually bind sender→owner, the composite would have to be minted by the owner at publish time, which changes the token format and breaks every already-published URL. That's exactly the cross-app work (the token→owner mapping lives in dav's private CalDavBackend) I flagged as out-of-scope in the Notes/follow-up section. I'd also rather not layer a home-grown HMAC over a value that's already a strong bearer secret.

So I'd keep this PR focused on the attacker-controlled-URL phishing vector (fixed at the trust boundary) and file a follow-up to properly bind the recipient/link to a calendar the caller actually published, via a new OCP API to resolve a public token to its owner. WDYT?