Audit log cannot distinguish a legitimate publish from an injected one
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- security
Research direction
Start with src/audit/audit-logger.ts, especially lines 40-41, and read docs/live-acceptance.md step 13 plus docs/setup.md. Trace the submitted title and description into the audit entry, then verify the log remains non-sensitive while distinguishing different published content; also resolve the file and parent-directory permission behavior documented in the issue.
Written by the indexing model from the issue text.
Description
Summary
Audit entries record {timestamp, osUsername, clientName, clientVersion, tool, groupUrlname, eventId, result} and nothing about what was actually written. If an agent is induced to publish a defaced event, that log line is byte-identical to a legitimate publish.
Context
The redaction is deliberate and the instinct is right: descriptions, tokens and keys should not be in the log, and docs/live-acceptance.md step 13 checks for exactly that. The gap is that the log now cannot answer the one question it exists to answer.
Suggested fix
Record a SHA-256 of the submitted title and description rather than the values themselves. That stays non-sensitive, keeps the acceptance check passing, and makes it possible to prove after the fact whether what was published matched what the operator approved.
Related, smaller point in the same file
src/audit/audit-logger.ts:41 passes mode: 0o600, which only applies when the file is first created and is effectively a no-op on Windows, currently the only supported platform. The parent directory is created with default permissions at line 40. Either set an appropriate ACL or adjust docs/setup.md so it does not imply the log is access-controlled.
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SSWConsulting/SSW.MeetupMCP
-
Area: Backend Type: Bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Type: DevOps
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Area: Backend Type: Bug
Difficulty 3/5 1-2 days Newbie friendliness 78/100
-
Type: Bug Type: DevOps
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Area: Backend Type: Bug
Difficulty 5/5 Over a week Newbie friendliness 45/100
All issues in SSWConsulting/SSW.MeetupMCP
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
bcgov/bc-wallet-mobile#4761 · 1 comment ·
-
external-issue to-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
refactor
Difficulty 2/5 1-3 hours Newbie friendliness 84/100