mhoennigandClaude
a4c995592f
Finishes the small items of the security audit in docs/prs/2026-07-08-PR#000: TODO 3, 4 and 7. The three mutating endpoints of BuildsApiController no longer accept the control token as a `token` query parameter — only the X-GitTally-Token header, which the bundled UI has always used. URLs end up in access logs, proxy logs, browser history and Referer headers, and the token never expires, so a historical log capture would yield a valid credential. `config:print` masks git.token as `***` on both the raw and the --full path and names the new --show-secrets flag in a leading YAML comment, so the output stays parseable when piped. The setup script points at --show-secrets where it used to steer the operator to the plain token. `server.bindAddress` now defaults to 127.0.0.1: neither the UI nor the API authenticates read access, so reaching GitTally should require the host's reverse proxy. Existing .gittally.yml files keep their explicit value; the managed nginx container needs `0.0.0.0` set deliberately, which is noted in the release notes, docs/configuration.md and docs/deployment.md. Released as v0.9.9, which also carries the previous two commits. Co-Authored-By: Claude <noreply@anthropic.com>
Pull-Request Documentations in doc/PR
This directory contains documentation for each pull request (PR).
IMPORTANT: The PR-documentation documents the change which was applied in that PR. Such documentation might be outdated right after the next PR was merged. Historic PR-documentation is not maintained along with new PRs.
Naming Convention
YYYY-MM-DD-PR#999-short-description-of-pr
- Date of the PR in the format
YYYY-MM-DD - followed '-PR#' followed by the number of the pull request in GitEA,
- a short description of the PR with dashes between the words,
- '.md'
Yes, to get the PR-number, you need to open a pull request first,
but initially prefix its title with WIP: to mark it as a work in progress until it is ready for review.
Guidelines
- Documentations must be written in Markdown format.
- Use Englisch, it's a public open source project.
- Use clear and concise language and keep it short.
- Include relevant details and context, explain the "why".
- Mark reference to Taiga or any other tool that is not public as "Hostsharing-internal".
- If necessary, copy important parts of the ticket description.
- One sentence or statement per line to make diffs easier to read.
Structure
The main (##) sections have to appear in exactly this order, omitting sections which do not apply:
- Related Links (optional)
- The Problem (required)
- Non-Goals (required)
- The Scenarios (optional for maintenance or bug fixing PRs, required for features)
- The Solution (required)
- Open Questions (optional)
- Additional Changes (optional)
- Prerequisite PRs (optional)
- Follow-up PRs (optional)
- Attachments (optional)
For details, see template