Files @ b9b719fb4774
Branch filter:

Location: kallithea/docs/usage/locking.rst - annotation

b9b719fb4774 1.1 KiB text/prs.fallenstein.rst Show Source Show as Raw Download as Raw
Thomas De Schampheleire
search: fix XSS vulnerability in search results

The search feature did not correctly escape all arguments when displaying
search matches and linking to the corresponding files.

An attacker that can control the contents of a repository could thus cause
a cross-site scripting (XSS) vulnerability.

Fix the problem by removing the overall h.literal call that is only needed
for the HTML entity » and splitting the link instead.

We take the opportunity to improving the destination of the part before
» which is the path to the repository. Instead of pointing to the
search result, point to the repository itself.
The part after » remains linked to the file containing the search
match.

Reported by Bob Hogg <wombat@rwhogg.site> (thanks!).
.. _locking:

==================
Repository locking
==================

Kallithea has a *repository locking* feature, disabled by default. When
enabled, every initial clone and every pull gives users (with write permission)
the exclusive right to do a push.

When repository locking is enabled, repositories get a ``locked`` flag.
The hg/git commands ``hg/git clone``, ``hg/git pull``,
and ``hg/git push`` influence this state:

- A ``clone`` or ``pull`` action locks the target repository
  if the user has write/admin permissions on this repository.

- Kallithea will remember the user who locked the repository so only this
  specific user can unlock the repo by performing a ``push``
  command.

- Every other command on a locked repository from this user and every command
  from any other user will result in an HTTP return code 423 (Locked).
  Additionally, the HTTP error will mention the user that locked the repository
  (e.g., “repository <repo> locked by user <user>”).

Each repository can be manually unlocked by an administrator from the
repository settings menu.