claude_remediation_prompt.txt

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 user’s 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.
-												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
+								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:
 . `#3`
 . `#4`
 . `#5`
 . `#2`
 . `#6`
 . `#7`
 . `#8`
 . `#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 user’s 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.