- 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
67 lines
3.1 KiB
Plaintext
67 lines
3.1 KiB
Plaintext
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.
|