Fusion
4e2edb1d93
- Add backend API for git repository CRUD (create, list, delete) - Support bare repository initialization and mirror cloning - Add cascade delete for repositories when project is deleted - Add frontend page for repository management per project - Update project page with link to repositories - Add repo_base_path to config - Quality gates: ruff, mypy, typecheck, lint, build all pass
1.6 KiB
1.6 KiB
Context
The SSHKey model exists in the database but there's no API to create, list, or manage SSH keys. Users need SSH keys for git operations with external providers.
Goals / Non-Goals
Goals:
- Generate Ed25519 SSH key pairs via API
- Encrypt private keys with Fernet before storage
- List user's SSH keys with public key display
- Support copying public keys to clipboard
- Allow deletion of SSH keys
Non-Goals:
- RSA key generation (Ed25519 only)
- Private key display/decryption to users
- SSH key editing (name changes only via update)
- Integration with git operations (separate feature)
Decisions
-
Use cryptography library for key generation
- Ed25519 keys via
cryptography.hazmat.primitives.asymmetric.ed25519 - Fernet symmetric encryption for private keys
- Already in project dependencies
- Ed25519 keys via
-
Store private keys encrypted
- Never expose private keys through API
- Fernet key derived from application secret
- One-way encryption, no decryption endpoint
-
Frontend uses simple table/list view
- Name, created date, public key preview
- Copy button for full public key
- Generate and delete actions
Risks / Trade-offs
- [Fernet key rotation loses access to old keys] → Document that rotating JWT_SECRET effectively locks old SSH keys
- [Private key storage is only as secure as Fernet key] → Store Fernet key securely, use strong application secret
Migration Plan
- Create API endpoints
- Add frontend page
- Register router
- Run tests
Open Questions
- Should we allow SSH key naming during generation?