mirror of
https://github.com/R0m1k3/Loki.git
synced 2026-10-16 11:49:43 +02:00
Jauge de contexte, espace disque sur partage agrégé, panneau Fichiers
Trois défauts sans rapport entre eux, tous visibles à l'écran. Jauge de contexte bloquée à « 0 / N (0 %) » : le comptage exact vient de usage.prompt_tokens (include_usage), qu'un llama-server récent a cessé de renvoyer. On note désormais si l'usage est arrivé ; sinon la fin de tour publie l'estimation qui pilote déjà la compaction — approximative, mais jamais absente. Et la souscription envoie la valeur courante juste après le rattrapage : une page rechargée affichait zéro sur une discussion pourtant pleine, faute d'événement ctx_used dans la fenêtre rejouée. Espace disque : « il ne reste que 11,9 Go » sur un partage Unraid qui en a des centaines. /mnt/user est servi par shfs, un FUSE qui agrège plusieurs disques — statfs y renvoie l'espace d'un seul, et ce chiffre REFUSAIT l'installation du modèle. Les systèmes de fichiers qui approximent (FUSE, overlay, NFS, CIFS, Ceph, Gluster) sont reconnus par leur magie : leur chiffre reste affiché, précédé d'un « ~ », mais ne bloque plus rien. Panneau Fichiers : le panneau entier défilait, emportant vers le haut l'en-tête, le fil d'Ariane et le pied (occupation disque, bouton .zip) dès qu'il y avait quelques fichiers. Seule la liste défile maintenant ; le pied reste en bas et l'état vide se centre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
895ff92ed8
commit
b405adea6c
5118 files changed
+1264007
-23
No files matched your search
+74
@@ -0,0 +1,74 @@
|
||||
## Threat Model for resolve (module path resolution library)
|
||||
|
||||
### 1. Library Overview
|
||||
|
||||
- **Library Name:** resolve
|
||||
- **Brief Description:** Implements Node.js `require.resolve()` algorithm for synchronous and asynchronous file path resolution. Used to locate modules and files in Node.js projects.
|
||||
- **Key Public APIs/Functions:** `resolve.sync()` / `resolve/sync`, `resolve()` / `resolve/async`
|
||||
|
||||
### 2. Define Scope
|
||||
|
||||
This threat model focuses on the core path resolution algorithm, including filesystem interaction, option handling, and cache management.
|
||||
|
||||
### 3. Conceptual System Diagram
|
||||
|
||||
```
|
||||
Caller Application → resolve(id, options) → Resolution Algorithm → File System
|
||||
│
|
||||
└→ Options Handling
|
||||
└→ Cache System
|
||||
```
|
||||
|
||||
**Trust Boundaries:**
|
||||
- **Input module IDs:** May come from untrusted sources (user input, configuration)
|
||||
- **Filesystem access:** The library interacts with the filesystem to resolve paths
|
||||
- **Options:** Provided by the caller
|
||||
- **Cache:** Used to improve performance, but could be a vector for tampering or information disclosure if not handled securely
|
||||
|
||||
### 4. Identify Assets
|
||||
|
||||
- **Integrity of resolution output:** Ensure correct and safe file path matching.
|
||||
- **Confidentiality of configuration:** Prevent sensitive path information from being leaked.
|
||||
- **Availability/performance for host application:** Prevent crashes or resource exhaustion.
|
||||
- **Security of host application:** Prevent path traversal or unintended filesystem access.
|
||||
- **Reputation of library:** Maintain trust by avoiding supply chain attacks and vulnerabilities[1][3][4].
|
||||
|
||||
### 5. Identify Threats
|
||||
|
||||
| Component / API / Interaction | S | T | R | I | D | E |
|
||||
|-----------------------------------------------------|----|----|----|----|----|----|
|
||||
| Public API Call (`resolve/async`, `resolve/sync`) | ✓ | ✓ | – | ✓ | – | – |
|
||||
| Filesystem Access | – | ✓ | – | ✓ | ✓ | – |
|
||||
| Options Handling | ✓ | ✓ | – | ✓ | – | – |
|
||||
| Cache System | – | ✓ | – | ✓ | – | – |
|
||||
|
||||
**Key Threats:**
|
||||
- **Spoofing:** Malicious module IDs mimicking legitimate packages, or spoofing configuration options[1].
|
||||
- **Tampering:** Caller-provided paths altering resolution order, or cache tampering leading to incorrect results[1][4].
|
||||
- **Information Disclosure:** Error messages revealing filesystem structure or sensitive paths[1].
|
||||
- **Denial of Service:** Recursive or excessive resolution exhausting filesystem handles or causing application crashes[1].
|
||||
- **Path Traversal:** Malicious input allowing access to files outside the intended directory[4].
|
||||
|
||||
### 6. Mitigation/Countermeasures
|
||||
|
||||
| Threat Identified | Proposed Mitigation |
|
||||
|--------------------------------------------|---------------------|
|
||||
| Spoofing (malicious module IDs/config) | Sanitize input IDs; validate against known patterns; restrict `basedir` to app-controlled paths[1][4]. |
|
||||
| Tampering (path traversal, cache) | Validate input IDs for directory escapes; secure cache reads/writes; restrict cache to trusted sources[1][4]. |
|
||||
| Information Disclosure (error messages) | Generic "not found" errors without internal paths; avoid exposing sensitive configuration in errors[1]. |
|
||||
| Denial of Service (resource exhaustion) | Limit recursive resolution depth; implement timeout; monitor for excessive filesystem operations[1]. |
|
||||
|
||||
### 7. Risk Ranking
|
||||
|
||||
- **High:** Path traversal via malicious IDs (if not properly mitigated)
|
||||
- **Medium:** Cache tampering or spoofing (if cache is not secured)
|
||||
- **Low:** Information disclosure in errors (if error handling is generic)
|
||||
|
||||
### 8. Next Steps & Review
|
||||
|
||||
1. **Implement input sanitization for module IDs and configuration.**
|
||||
2. **Add resolution depth limiting and timeout.**
|
||||
3. **Audit cache handling for race conditions and tampering.**
|
||||
4. **Regularly review dependencies for vulnerabilities.**
|
||||
5. **Keep documentation and threat model up to date.**
|
||||
6. **Monitor for new threats as the ecosystem and library evolve[1][3].**
|
||||
Reference in new issue
Block a user