It's possible for reviews to not be assiocated with users, when they
were migrated from another forge instance. In the migration code,
there's no sanitization check for author names, so they could contain
HTML tags and thus needs to be properely escaped.
(cherry picked from commit ca798e4cc2)
(cherry picked from commit d3de80b9cc)
- It's possible for reviews to not be assiocated with users, when they
were migrated from another forge instance. In the migration code,
there's no sanitization check for author names, so they could contain
HTML tags and thus needs to be properely escaped.
- Pass `$reviewerName` trough `Escape`.
(cherry picked from commit fe2df46d05)
Conflicts:
templates/repo/issue/view_content/comments.tmpl
trivial context conflict
On the wiki and revisions page, information is shown about the last
commit that modified that wiki page. This includes the time it was last
edited and by whom. Verify it is sanitized.
(cherry picked from commit 565e331238)
(cherry picked from commit 92dae3a387)
- On the wiki and revisions page, information is shown about the last
commit that modified that wiki page. This includes the time it was last
edited and by whom. That whole string is not being sanitized (passed
trough `Safe` in the templates), because the last edited bit is
formatted as an HTML element and thus shouldn't be sanitized. The
problem with this is that now `.Author.Name` is not being sanitized.
- This can be exploited, the names of authors and commiters on a Git
commit is user controlled, they can be any value and thus also include
HTML. It's not easy to actually exploit this, as you cannot use the
official git binary to do use, as they actually strip `<` and `>` from
user names (trivia: this behaviour was introduced in the initial commit
of Git). In the integration testing, go-git actually has to generate
this commit as they don't have such restrictions.
- Pass `.Author.Name` trough `Escape` in order to be sanitized.
(cherry picked from commit d24c37e132)
Conflicts:
templates/repo/wiki/revision.tmpl
templates/repo/wiki/view.tmpl
trivial context conflict
The private Forgejo instance trusted with the release signing keys no
longer requires the installation of the ownca certificate authority.
Refs: https://codeberg.org/forgejo/docs/pulls/338
(cherry picked from commit 72f9ae796d7d7328e87129485e83251708f3d2fb)
- Backport https://codeberg.org/forgejo/forgejo/pulls/1839
- Consider executable files as a valid case when returning a downloadURL
for them. They are just regular files with the difference being the
executable permission bit being set.
- Not integration testing as it's not possible without adding adjusting
the existing repositories to have a executable file.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1825
(cherry picked from commit ca32891d548c302b0f3b3072647058278ffb9cbf)
- Backport https://codeberg.org/forgejo/forgejo/pulls/1849
- Hook Forgejo's `EnsureUpToDate` to Gitea's `EnsureUpToDate`, such that
the Forgejo migrations are also being checked to be up to date.
- I'm not sure how I missed this and if this has caused any problems,
but due to the lack of any open issue about it it seems to not be a big
problem.
(cherry picked from commit 6c65b6dcf6ab0d58e5c2d03a866e4e38294f72ad)
backport #28213
This PR will fix some missed checks for private repositories' data on
web routes and API routes.
(cherry picked from commit dfd511faf35fef68557e53763f9b06e5a139565d)
