Infrastructure

We can easily patch the source to remove the parameters in the ICS links if desired. Download will work as long as the user is authenticated, but it won't work to import from a standalone ical client or similar.

We can also change auth medod for the /icalendar segment to use Basic HTTP Authentication (with the key as username and a dummy password) or pass the RSS key via a custom header, like what Redmine does at https://www.redmine.org/projects/redmine/wiki/Rest_api#Authentication . But that's a more disruptive change and doesn't offer much gain much IMHO.

We can easily patch the source to remove the parameters in the ICS links if desired. Download will work as long as the user is authenticated, but it won't work to import from a standalone ical client or similar.

How would that work from a calendar client then, e.g. Lightning in
Thunderbird? Would Thunderbird show me the auth dialog then?

I mean only in the <a href=…/>, so people don't share calendar links by mistake. (The RSS key can be found in the Atom links at the the bottom of this page.) Visiting /icalendar/all_projects/all/open/issues.ics?key=… would be processed like they are right now.

So that means when I add it to my calendar client, anytime I'm on an
untrusted network, there's a decent risk someone takes my key and has
access to my ticket feed?

Uh? Not if you use https:// , which you should anyway.

Maybe I'm lost, but if I use HTTPS with GET URLs, that's transmitted
cleartext still, and visible in logs, isn't it?

Maybe I'm lost, but if I use HTTPS with GET URLs, that's transmitted cleartext still,

Nope :-) HTTPS is HTTP over TLS, so first you connect to the INET socket and perform a TLS handhake (passing the hostname for SNI), then start speaking HTTP over the secure channel. So the request method, path, query string, header and body are all protected from eavesdropping (and authenticated assuming the peer cert was verified or pinned). Try MiTMing curl https://https://redmine.documentfoundation.org/foo?bar&bar and see what leaks :-)

and visible in logs, isn't it?

See what I wrote in message #1: “These parameters have also the downside of being passed on GETs, so they're showing up in the HTTPd logs. Not a big deal right now though, as only infra team members have access to these logs and we also have access to the database.”

Try MiTMing curl https://https://redmine.documentfoundation.org/foo?bar&bar and see what leaks :-)

Namely the hostname leaks to the DNS resolver (and is also visible on the wire when encrypted SNI isn't used), IP addresses and ports leak too, and that's pretty much it. This is the case whenever TLS is used as original transport on a dedicated port, so it applies to $FOO over TLS (such as imaps:// and submissions://): first the client establishes a secure channel, then start speaking $FOO. OTOH protocols using upgrades via the STARTTLS directive leak more data.

Ah, I learned something new, didn't know that :-)

See what I wrote in message #1: “These parameters have also the downside
of being passed on GETs, so they're showing up in the HTTPd logs. Not a
big deal right now though, as only infra team members have access to
these logs and we also have access to the database.”

So, if I get it right, from your POV, having the iCal plugin active with
forced HTTPS is safe, right? Then we can enable it

Fair enough, thanks! :)