Files
platform/claude_remediation_prompt.txt
Yusuf Suleman d700ba7569 fix(trips): enforce password protection on shared trips (#3)
- handle_share_api now checks X-Share-Password header against bcrypt hash
  before returning trip data. Returns 401 with {protected: true} if password
  required but not provided/incorrect
- share_password now stored as bcrypt hash, not plaintext
- All plaintext password logging removed from handle_share_verify
- handle_share_verify uses bcrypt.checkpw instead of string equality
- Migration invalidates existing plaintext share passwords (< 50 chars)
- Removed dead hash_password function (used hashlib.sha256)
- Added bcrypt to trips Dockerfile

Closes #3
2026-03-29 08:50:45 -05:00

67 lines
3.1 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
You are acting as a senior staff engineer and security remediation lead on the `platform` repository.
Use the existing Gitea issues as the source of truth for scope and acceptance criteria.
Repository:
- Name: `platform`
- Gitea repo: `yusiboyz/platform`
Primary tracking issue:
- `#1 Production Security and Readiness Remediation`
Immediate issues:
- `#2 Auth Boundary: Registration and Default Credentials`
- `#3 Trips Sharing Security: Enforce Protection and Remove Plaintext Secrets`
- `#4 Fitness Authorization: Eliminate Cross-User Data Access`
- `#5 Gateway Trust Model: Protect Internal Services and Service-Level Data`
- `#6 Repository Hygiene: Remove Tracked Secrets and Runtime Databases`
- `#7 Transport Security: Finish Cookie Hardening, TLS Verification, and Proxy Controls`
- `#8 Dependency Security and CI Enforcement`
Next issues:
- `#9 Performance Hardening: Cache and De-risk Summary Endpoints`
- `#10 Deployment Hardening: Containers, Health Checks, and Production Readiness`
Required execution order:
1. `#3`
2. `#4`
3. `#5`
4. `#2`
5. `#6`
6. `#7`
7. `#8`
8. `#9`
9. `#10`
Instructions:
- Start by reading the codebase and the linked Gitea issues.
- Treat the repo as production-bound and internet-exposed.
- Make real code changes, not just recommendations.
- After each issue-sized chunk, verify the fix with tests, targeted checks, or direct code-path validation.
- Update the relevant Gitea issue with:
- what was changed
- exact files touched
- how it was verified
- any remaining risk
- Keep changes minimal but correct. Do not do broad refactors unless required for security or correctness.
- Do not close an issue unless its acceptance criteria are actually satisfied.
- If an issue is only partially fixed, comment with exactly what remains.
- Preserve user changes and do not revert unrelated work.
- If you need to rotate secrets or remove tracked `.env` / `.db` artifacts, make the code and repo changes needed, but clearly separate anything that requires a manual operational rotation step.
- Prioritize correctness and security over speed.
Specific expectations:
- For `#3`, fully eliminate the Trips share-token bypass. Password protection must actually gate access. No plaintext password storage or logging.
- For `#4`, eliminate all normal-user cross-user access in Fitness. `user_id` must not let one user read another users data.
- For `#5`, remove the implicit trust model for service-global data exposure where required.
- For `#2`, remove default credential seeding/fallbacks and make startup fail fast where appropriate.
- For `#6`, stop tracking live env/db artifacts and harden ignore rules.
- For `#7`, restore TLS verification by default and finish cookie hardening cleanly.
- For `#8`, resolve the budget dependency vulnerability and add CI checks for dependency/security scanning.
Reporting format:
- At the start: brief plan tied to issue numbers.
- During work: short progress updates.
- At the end of each issue: `fixed`, `partial`, or `blocked`, with exact file references.
- Final output: summarize which issue numbers were completed, which remain open, and what manual ops actions are still required.