31 lines
3.5 KiB
Markdown
31 lines
3.5 KiB
Markdown
# FUTURE_WORKS.md
|
|
|
|
> **Purpose**: Track future work candidates for the `advanced_multi_agent` project.
|
|
> For completed items, see `DONE.md`.
|
|
> **Last Updated**: 2026-06-21
|
|
|
|
---
|
|
|
|
## Future Improvements Roadmap
|
|
|
|
Below is the list of pending future work items. These items were proposed based on the security and concurrency analysis in the `Understand_Anything_Analysis.md` report.
|
|
|
|
| ID | Task | Priority | Effort | Domain / Description | Dependencies |
|
|
|---|---|---|---|---|---|
|
|
| **FW-N5** | Update `job-protocol.md` security protocol spec (to HMAC signatures) | P1 (High) | Small (Doc) | **Documentation/Design Consistency**: Fix the official protocol document which incorrectly guides users to use an insecure plaintext token transmission scheme (`data.auth_token`), aligning it with the actually implemented HMAC signature scheme. | None (conduct in parallel with FW-N6) |
|
|
| **FW-N6** | Support auto-generated `auth_token` and CLI integration in `registry.py` | P1 (High) | Small~Medium | **Activate Security Features**: Resolve the bug where all jobs registered via CLI (`registry.py register`) have `auth_token` set to `null` (unauthenticated mode), which bypasses HMAC security. Add the `--auth-token` argument to the CLI, and automatically generate a token when a secure environment (TLS/Username, etc.) is detected. | None (Highest Priority) |
|
|
| **FW-N7** | Prevent Replay Attacks via sequence monotonic increase validation in `job_subscriber.py` | P2 (Medium) | Small~Medium | **Security Hardening (Defense in Depth)**: To prevent cryptographically signed non-terminal events (`progress`, `permission_required`) from being intercepted on the network and retransmitted (Replay Attack), add logic to verify that the sequence number (`seq`) of incoming messages is monotonically increasing. | **FW-N6 is a prerequisite** (only meaningful after authentication/HMAC is active) |
|
|
| **FW-L4** | Migrate Job Registry to SQLite to overcome NFS flock limitations | P3 (Low) | Large | **Concurrency/Infrastructure Scalability**: Similar to the Session Registry, migrate the individual JSON file lock (`fcntl.flock`) registry structure into an integrated SQLite database transaction structure, guaranteeing full reliability in distributed/network file systems like NFS. | **Conditional** (commence only when multi-host/NFS deployment is required) |
|
|
|
|
---
|
|
|
|
### Detailed Discussion Results & Directions (Reviewer Consensus)
|
|
|
|
1. **Prioritize R2 (FW-N6) to Enable HMAC Security**:
|
|
* Although the HMAC signature code (verify/sign) is implemented, registering a job via the normal CLI lacks a way to generate or inject a cryptographic token, forcing jobs into unauthenticated PoC mode. Thus, **FW-N6** is the prerequisite for all security improvements.
|
|
2. **Document Synchronization (FW-N5)**:
|
|
* Since the current document details an insecure design (plaintext token transmission), it should be updated immediately to prevent development confusion.
|
|
3. **Scope of Replay Attack Prevention (FW-N7)**:
|
|
* Implement sequence monotonic check (`last_seq` tracking) on the receiving side. Pay careful attention to handling subscriber restarts (initializing `last_seq`) and coordinate this with terminal event duplicate controls.
|
|
4. **Conditional Deferral of SQLite Integration (FW-L4)**:
|
|
* Unlike the session registry, maintaining individual job data in JSON files is highly intuitive for management and debugging. Since the current deployment is constrained to a single-host local file system, `fcntl.flock` locks are sufficient. Thus, this is assigned a low priority (P3) and will be tackled conditionally. |