Completely blocking longer running math rendering within Markdown is not cool.

Problem to solve

This is a follow up from gitlab-foss#61410 (closed), where we solved a security issue in such a way that it made Issues/Wikis completely unusable for those in the wider community that relied upon them to house large amounts of katex.

I am in the same place as you. In my case I use the GitLab Wiki to document the mathematical/physical background of a library developed in a GitLab repository. I would consider the is-taking-too-long-to-respond approach as a regression if it is applied on any rendered text in GitLab without distinction at all. The current solution prevents from loading a valid GitLab Wiki entry that was possible to load when it was created two years ago. ref

Proposal

We can follow the solution we used for a similar problem with Mermaid charts (https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/1059#note_441363524).

• Enable the progressive rendering of math equations such that the original security flaw is not reintroduced and those that use larger math equations can use Issues/Wikis as they once could.
• Original Proposal Suggestion: gitlab-foss#61410 (comment 292612809)
• Can we render only equations that appear on-screen, and render the rest as the user scrolls? This lets us establish an upper bound on render time per screen, and avoid the case where an attacker can do a DoS with several thousand smaller equations.
• Iterating on your idea: For cases where there are many small equations (say: mathematical symbols) scattered around the text, I think it would be useful to have a control that allows to "continue rendering" from the point where the timeout was triggered.