gitea panics on a markdown syntax error (nested links) #2339

New Issue

GiteaMirror · 2025-11-02T04:33:20-06:00

GiteaMirror commented

2025-11-02 04:33:20 -06:00

Originally created by @earwig on GitHub (Sep 16, 2018).

Gitea version (or commit ref): master (acb6f8a), also 1.5.1
Git version: Tested 2.10.1, 2.18.0
Operating system: Tested Ubuntu, macOS
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL): https://try.gitea.io/earwig/markuptest
- No
- Not relevant
Log gist: https://gist.github.com/earwig/f44165540933bbe277a4704136ba80b9

Description

The syntax is this: [\[\[foobar\]\]](https://example.org)

Expected result: [[foobar]]

I noticed it when trying to mirror one of my repos.

Originally created by @earwig on GitHub (Sep 16, 2018).  - Gitea version (or commit ref): master (acb6f8a), also 1.5.1 - Git version: Tested 2.10.1, 2.18.0 - Operating system: Tested Ubuntu, macOS - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL): https://try.gitea.io/earwig/markuptest - [ ] No - [ ] Not relevant - Log gist: https://gist.github.com/earwig/f44165540933bbe277a4704136ba80b9 ## Description The syntax is this: `[\[\[foobar\]\]](https://example.org)` Expected result: [\[\[foobar\]\]](https://example.org) I noticed it when trying to mirror [one of my repos](https://github.com/earwig/tfdclerk).

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 04:33:20 -06:00

GiteaMirror closed this issue

2025-11-02 04:33:20 -06:00

GiteaMirror commented

2025-11-02 04:33:21 -06:00

@SagePtr commented on GitHub (Sep 19, 2018):

I don't get why "visitLinksForShortLinks" logic in modules/markup/html.go is used, where it's used at all. Why nested links should be processed, any working example where they are needed. I cannot remember any example where <a> tag is included into another <a> tag in production, and how the broswers should handle this mess.
Probably over-engeneering?

@SagePtr commented on GitHub (Sep 19, 2018): I don't get why "visitLinksForShortLinks" logic in modules/markup/html.go is used, where it's used at all. Why nested links should be processed, any working example where they are needed. I cannot remember any example where ```<a>``` tag is included into another ```<a>``` tag in production, and how the broswers should handle this mess. Probably over-engeneering?

GiteaMirror commented

2025-11-02 04:33:21 -06:00

@earwig commented on GitHub (Sep 19, 2018):

Agreed, I looked through the code myself while trying to debug and couldn’t understand it either. None of tests seem to go through that code path, unless I’m missing something.

On Sep 19, 2018, at 4:54 PM, SagePtr notifications@github.com wrote:

I don't get why "visitLinksForShortLinks" logic in modules/markup/html.go is used, where it's used at all. Why nested links should be processed, any working example where they are needed.
Probably over-engeneering?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@earwig commented on GitHub (Sep 19, 2018): Agreed, I looked through the code myself while trying to debug and couldn’t understand it either. None of tests seem to go through that code path, unless I’m missing something. > On Sep 19, 2018, at 4:54 PM, SagePtr <notifications@github.com> wrote: > > I don't get why "visitLinksForShortLinks" logic in modules/markup/html.go is used, where it's used at all. Why nested links should be processed, any working example where they are needed. > Probably over-engeneering? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread.

GiteaMirror commented

2025-11-02 04:33:21 -06:00

@stale[bot] commented on GitHub (Mar 6, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 6, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:33:21 -06:00

@earwig commented on GitHub (Mar 6, 2019):

This bug still causes an uncaught internal server error in production, as you can see from the reproduction I linked in the original post. This issue should not be closed.

@earwig commented on GitHub (Mar 6, 2019): This bug still causes an uncaught internal server error in production, as you can see from the reproduction I linked in the original post. This issue should not be closed.

GiteaMirror commented

2025-11-02 04:33:21 -06:00

@mrsdizzie commented on GitHub (Mar 6, 2019):

I was looking at all of the link generating code recently and can see whats causing this here. This happens because of a few things:

First, the markdown processor does correctly render this and outputs

<p><a href="https://example.org">[[foobar]]</a></p>

However, then gitea runs its own processors and this happens to match the following regex:

https://github.com/go-gitea/gitea/blob/master/modules/markup/html.go#L53

It does that because it sees anything inside double brackets as a possible MediaWiki/Github style short link like

[[link|example]]
[[example|link]]

Relevant comments/function here:

https://github.com/go-gitea/gitea/blob/master/modules/markup/html.go#L389

That function seems to assume too much about the text match, and fails when it isn't actually what was expected. This also does other bad things like turn this bogus text into a link:

[[]]example

See: https://try.gitea.io/mrsdizzie/test/issues/2

A quick test of changing shortLinkPattern to

shortLinkPattern = regexp.MustCompile(`\[\[(.+?\|.+?)\]\](\w*)`)

Makes the offending example (and my test) in this issue work as expected, but is complicated because this code is also used for the (imo) separate case of matching basic Test style wiki links as well.

Setting visitLinksForShortLinks: false doesn't seem to affect any of the current tests, and is perhaps an option for fixing this particular issue as well. As mentioned above, I can't imagine the case where it makes sense to try and process an existing link and render another link inside of it (and apparently nobody who wrote the current tests imagined that either).

@mrsdizzie commented on GitHub (Mar 6, 2019): I was looking at all of the link generating code recently and can see whats causing this here. This happens because of a few things: First, the markdown processor does correctly render this and outputs ``` <p><a href="https://example.org">[[foobar]]</a></p> ``` However, then gitea runs its own processors and this happens to match the following regex: https://github.com/go-gitea/gitea/blob/master/modules/markup/html.go#L53 It does that because it sees anything inside double brackets as a possible MediaWiki/Github style short link like ``` [[link|example]] [[example|link]] ``` Relevant comments/function here: https://github.com/go-gitea/gitea/blob/master/modules/markup/html.go#L389 That function seems to assume too much about the text match, and fails when it isn't actually what was expected. This also does other bad things like turn this bogus text into a link: ``` [[]]example ``` See: https://try.gitea.io/mrsdizzie/test/issues/2 A quick test of changing shortLinkPattern to ``` shortLinkPattern = regexp.MustCompile(`\[\[(.+?\|.+?)\]\](\w*)`) ``` Makes the offending example (and my test) in this issue work as expected, but is complicated because this code is also used for the (imo) separate case of matching basic [[Test]] style wiki links as well. Setting visitLinksForShortLinks: false doesn't seem to affect any of the current tests, and is perhaps an option for fixing this particular issue as well. As mentioned above, I can't imagine the case where it makes sense to try and process an existing link and render another link inside of it (and apparently nobody who wrote the current tests imagined that either).

GiteaMirror commented

2025-11-02 04:33:22 -06:00

@techknowlogick commented on GitHub (Mar 7, 2019):

Closed per merged PR.

@techknowlogick commented on GitHub (Mar 7, 2019): Closed per merged PR.

GiteaMirror referenced this issue

2025-11-02 12:08:35 -06:00

[PR #2339] [CLOSED] Do not hard-code PostgreSQL credentials in tester file #16351

Sign in to join this conversation.