Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

tui: local audit log rewrite races with the guard's lock-free append

Open
  • Is something wrong?
#144 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
security

Research direction

Start at tui/locallog.go:204 and trace the TUI rewrite and guard append paths to see how each accesses the audit log. Reproduce the race using the listed steps, then inspect how the two paths can coordinate safely. Done when concurrent appends and rewrites preserve valid log entries; the issue does not name tests to run.

Written by the indexing model from the issue text.

Description

bug help wanted

Problem

In packages/tui/locallog.go:204, the TUI rewrites the local audit log file (e.g. during a delete or export operation) by reading the whole file, modifying it, and writing it back, while the guard process appends new entries to the same file without taking any lock, assuming append-only writers never conflict with another writer rewriting the whole file.

Impact

If the guard appends a new log entry to the file at the same time the TUI is mid-rewrite, the result is a classic TOCTOU/write race: depending on timing, the newly appended entry can be lost (overwritten by the TUI's stale read-then-write), or the file can end up with corrupted/interleaved content if both processes' writes land at overlapping offsets.

Repro

  1. Start the guard process appending to the local audit log continuously (e.g. triggering frequent audit events).
  2. Simultaneously perform a rewrite-triggering operation in the TUI (delete/export) against the same log file.
  3. Observe that entries appended by the guard during the TUI's read-modify-write window can be lost from the file afterward, or that the file ends up with corrupted content.

Suggested fix

Introduce a shared locking mechanism (e.g. an advisory file lock via flock, or a well-known lock file both processes respect) that the guard's append path and the TUI's rewrite path both acquire before touching the log file, so a rewrite cannot proceed while an append is in flight and vice versa. Alternatively, redesign the rewrite operation to re-read and merge any entries appended after the TUI's initial read before writing back, rather than assuming the file is static for the duration of the rewrite.

Dominant language
Go
Stars
157
Forks
19
Avg merge
4h 21m
Merged PRs (30d)
91

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solongate/agent-security

All issues in solongate/agent-security

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.