add clarification to research methodology by including a step for solution comparison and user consultation

_docs/00_research/security_edge_cases_research.md

@@ -0,0 +1,217 @@
+# Security Concerns and Edge Cases Research
+
+**System**: GPS-denied UAV visual navigation — Python backend (FastAPI, PyTorch, OpenCV, GTSAM, JWT auth, SSE streaming)
+
+**Date**: March 14, 2026
+
+---
+
+## Topic 1: PyTorch Model Loading Security
+
+### 1.1 Security Risks of Loading PyTorch Model Weights from Google Drive
+
+| Risk | Description | Confidence |
+|------|-------------|------------|
+| **Supply chain compromise** | Google Drive links can be hijacked, shared publicly, or replaced with malicious files. Authors' accounts may be compromised. | High |
+| **No integrity verification** | Unlike `torch.hub`, Google Drive downloads typically lack built-in checksum validation. | High |
+| **Pickle-based RCE** | `.pth` files use Python pickle; deserialization can execute arbitrary code. | High |
+| **LiteSAM-specific** | LiteSAM weights are hosted by paper authors on Google Drive — not an official PyTorch/Hugging Face registry. Trust boundary is weaker than torch.hub. | Medium |
+
+**Sources**: OWASP ML06:2023 AI Supply Chain Attacks; CVE-2025-32434; CVE-2026-24747; Vulert, GitHub PyTorch advisories.
+
+---
+
+### 1.2 Is `torch.load(weights_only=True)` Sufficient?
+
+**No.** Multiple CVEs show `weights_only=True` can still be bypassed:
+
+| CVE | Date | Severity | Description |
+|-----|------|----------|-------------|
+| **CVE-2025-32434** | Apr 17, 2025 | Critical | RCE possible even with `weights_only=True` in PyTorch ≤2.5.1. Patched in 2.6.0. |
+| **CVE-2026-24747** | 2026 | High (CVSS 8.8) | Memory corruption in `weights_only` unpickler; malicious `.pth` can cause heap corruption and arbitrary code execution. Patched in 2.10.0. |
+
+**Recommendation**: Use PyTorch 2.10.0+ and treat `weights_only=True` as a defense-in-depth measure, not a guarantee.
+
+**Sources**: [GitHub GHSA-53q9-r3pm-6pq6](https://github.com/pytorch/pytorch/security/advisories/GHSA-53q9-r3pm-6pq6); Vulert CVE-2025-32434, CVE-2026-24747; TheHackerWire.
+
+---
+
+### 1.3 Can Pickle-Based PyTorch Weights Contain Malicious Code?
+
+**Yes.** Pickle was designed to serialize Python objects and their behavior, not just data. A malicious pickle can:
+
+- Execute arbitrary code during deserialization
+- Steal data, install malware, or run remote commands
+- Trigger RCE without user interaction beyond loading the file
+
+`safetensors` format eliminates this by design: it stores only numerical tensors and metadata (JSON header + binary data), with no executable code path.
+
+**Sources**: Hugging Face safetensors security audit; Suhaib Notes; DEV Community safetensors article.
+
+---
+
+### 1.4 Recommended Approach for Verifying Model Weight Integrity
+
+| Approach | Implementation | Notes |
+|----------|----------------|-------|
+| **SHA256 checksums** | Compute hash after download; compare to known-good value before `torch.load()`. | PyTorch Vision uses checksums in filenames; `torch.hub.download_url_to_file` supports `check_hash`. |
+| **Digital signatures** | Sign weight files with GPG/Ed25519; verify before load. | OWASP recommends verifying package integrity through digital signatures. |
+| **Safetensors format** | Prefer `.safetensors` over `.pth` when available. | No code execution; Trail of Bits audited; Hugging Face default. |
+| **Vendor pinning** | Pin exact URLs and hashes for LiteSAM, SuperPoint, LightGlue, DINOv2. | Document expected hashes in config; fail fast on mismatch. |
+
+**LiteSAM-specific**: Add a manifest (e.g., `litesam_weights.sha256`) with expected SHA256; verify before loading. If authors provide safetensors, prefer that.
+
+**Sources**: PyTorch Vision PR #7219; torch.hub docs; OWASP ML06:2023.
+
+---
+
+### 1.5 Recent CVEs Related to PyTorch Model Loading (2024–2026)
+
+| CVE | Date | Affected | Fix | Summary |
+|-----|------|----------|-----|---------|
+| CVE-2025-32434 | Apr 2025 | PyTorch ≤2.5.1 | 2.6.0 | RCE via `torch.load(weights_only=True)` bypass |
+| CVE-2026-24747 | 2026 | Before 2.10.0 | 2.10.0 | Memory corruption in weights_only unpickler |
+| CVE-2025-1889 | Mar 2025 | PickleScan ≤0.0.21 | 0.0.22 | PickleScan misses malicious files with non-standard extensions |
+| CVE-2025-1945 | Oct 2025 | PickleScan <0.0.23 | 0.0.23 | ZIP header bit manipulation evades PickleScan (CVSS 9.8) |
+
+**Sources**: GitHub advisories; Vulert; NVD.
+
+---
+
+## Topic 2: GTSAM iSAM2 Edge Cases
+
+### 2.1 Drift Accumulation with Many Consecutive VO-Only Frames
+
+| Finding | Description | Confidence |
+|---------|-------------|------------|
+| **Drift accumulates** | With only VO constraints (BetweenFactorPose2) and no satellite anchors, iSAM2 propagates VO error. No absolute reference to correct drift. | High |
+| **Probabilistic correction** | A 2024 drift-correction module (arXiv:2404.10140) treats SLAM positions as random variables and corrects using geo-spatial priors; ~10× drift reduction over long traverses. | Medium |
+| **iSAM2 design** | iSAM2 is incremental; it does not inherently limit drift. Drift correction depends on loop closures or anchors. | High |
+
+**Recommendation**: Implement drift thresholds (as in your Segment Manager); trigger segment splits when VO-only chain exceeds a confidence/error bound. Use satellite anchors as soon as available.
+
+**Sources**: Kaess et al. iSAM2 paper (2012); arXiv:2404.10140; GTSAM docs.
+
+---
+
+### 2.2 iSAM2 with Very Long Chains (3000+ Frames)
+
+| Finding | Description | Confidence |
+|---------|-------------|------------|
+| **Scalability** | iSAM2 uses Bayes tree + fluid relinearization; designed for online SLAM without periodic batch steps. | High |
+| **Efficiency** | Variable reordering and sparse updates keep cost bounded; used on ground, aerial, underwater robots. | High |
+| **Legacy iSAM** | Original iSAM had slowdowns on dense datasets with many loop closures; iSAM2 improves this. | Medium |
+| **Memory** | No explicit 3000-frame benchmarks found; Bayes tree growth is sublinear but non-trivial. Recommend profiling. | Low |
+
+**Sources**: GTSAM iSAM2 docs; Kaess et al. 2012; MIT iSAM comparison page.
+
+---
+
+### 2.3 Backward Correction When Satellite Anchor Arrives After Many VO-Only Frames
+
+| Finding | Description | Confidence |
+|---------|-------------|------------|
+| **Loop closure behavior** | iSAM2 supports backward correction via loop closures. Adding a PriorFactorPose2 (satellite anchor) acts like a loop closure to the anchor frame. | High |
+| **Propagation** | The Bayes tree propagates the correction through the graph; all frames between anchor and current estimate are updated. | High |
+| **Quality** | Correction quality depends on anchor noise model and VO chain quality. Large drift may require strong anchor noise to pull trajectory; weak noise may under-correct. | Medium |
+
+**Recommendation**: Tune PriorFactorPose2 noise to reflect satellite matching uncertainty. Consider multiple anchors if available.
+
+**Sources**: GTSAM Pose2ISAM2Example; GTSAM docs; Pose2ISAM2Example.py.
+
+---
+
+### 2.4 Edge Cases Where iSAM2.update() Can Fail or Produce Garbage
+
+| Edge Case | Description | Source |
+|-----------|-------------|--------|
+| **Type mismatch** | Mixing Pose3 and Rot3 (or other type mismatches) across factors → `ValuesIncorrectType` exception. | GTSAM #103 |
+| **Double free / corruption** | `isam.update()` can trigger "double free or corruption (out)" during linearization, especially with IMU factors. Platform-specific (e.g., GTSAM 4.1.1, Ubuntu 20.04). | GTSAM #1189 |
+| **IndeterminantLinearSystemException** | Certain factor configurations (e.g., multiple plane factors) can produce singular/indeterminate linear systems. Removing one factor can allow convergence. | GTSAM #561 |
+| **Poor initial estimates** | Bad initial values can cause divergence or slow convergence. | General |
+
+**Recommendation**: Wrap `isam.update()` in try/except; validate factor types and initial estimates; test with IMU-like factors if used; consider GTSAM version upgrades.
+
+**Sources**: [borglab/gtsam#103](https://github.com/borglab/gtsam/issues/103), [#1189](https://github.com/borglab/gtsam/issues/1189), [#561](https://github.com/borglab/gtsam/issues/561).
+
+---
+
+### 2.5 Pose2 Noise Model Tuning for Visual Odometry
+
+| Approach | Description | Confidence |
+|----------|-------------|------------|
+| **Diagonal sigmas** | Standard: `noiseModel.Diagonal.Sigmas(Point3(sigma_x, sigma_y, sigma_theta))`. Example: (0.2, 0.2, 0.1). | High |
+| **Sensor-derived** | Tune from encoder noise, gyro drift, or VO accuracy (e.g., from SuperPoint+LightGlue/LiteSAM covariance if available). | High |
+| **Learning-based** | VIO-DualProNet, covariance recovery from deep VO — noise varies with conditions; fixed sigmas can be suboptimal. | Medium |
+| **Heteroscedasticity** | VO error is not constant; consider adaptive or learned covariance for production. | Medium |
+
+**Recommendation**: Start with diagonal sigmas from VO residual statistics; refine via ablation. Document sigma choices in config.
+
+**Sources**: GTSAM Pose2SLAMExample; GTSAM by Example; arXiv:2308.11228, 2403.13170, 2007.14943.
+
+---
+
+## Topic 3: Segment Reconnection Edge Cases
+
+### 3.1 Reconnection Order for 5+ Disconnected Segments
+
+| Strategy | Description | Confidence |
+|----------|-------------|------------|
+| **Global loop closure** | Position-independent methods (e.g., visual place recognition) can reconnect maps from different sessions without shared reference. | High |
+| **Graph-based** | Build undirected graph of segments; use trajectory matching cost minimization (e.g., Hungarian algorithm) to associate segments. SWIFTraj achieved ~0.99 F1 on vehicle trajectory connection. | Medium |
+| **Robust loop processing** | LEMON-Mapping: outlier rejection + recall strategies for valid loops; spatial BA + pose graph optimization to propagate accuracy. | Medium |
+| **Invalid merge detection** | Compare incoming data with merged scans to detect perceptual aliasing; undo invalid merges. | Medium |
+
+**Recommendation**: Order reconnection by anchor confidence and temporal proximity; validate each merge before committing.
+
+**Sources**: arXiv:2407.15305, 2505.10018, 2211.03423; SWIFTraj (arXiv:2602.21954).
+
+---
+
+### 3.2 Two FLOATING Segments Anchored Near Each Other — Connection Validation
+
+| Approach | Description | Confidence |
+|----------|-------------|------------|
+| **Geometric consistency** | Constellation-based map merging: check geometric consistency of landmark constellations; high confidence required for merge. | High |
+| **Visual verification** | Re-run matching between segment endpoints; require strong feature overlap and pose consistency. | Medium |
+| **Uncertainty propagation** | Use landmark uncertainty from local SLAM; reject merges if combined uncertainty exceeds threshold. | Medium |
+| **Temporal/spatial prior** | If segments are from same flight, use time ordering and approximate location to constrain candidate pairs. | Medium |
+
+**Recommendation**: Do not merge solely on proximity. Require: (1) satellite match confidence above threshold, (2) geometric consistency between segment endpoints, (3) optional visual re-verification.
+
+**Sources**: arXiv:1809.09646 (constellation-based merging); SegMap; PLVS.
+
+---
+
+### 3.3 All Segments Remain FLOATING — Outdated Satellite Imagery
+
+| Finding | Description | Confidence |
+|----------|-------------|------------|
+| **Temporal degradation** | Outdated imagery degrades feature matching; urban/natural changes cause mismatches. | High |
+| **Mitigations** | Oblique-robust methods, multi-stage (coarse + fine) matching, OpenStreetMap + satellite fusion, cross-modal (SAR + optical) matching. | Medium |
+| **Fallback** | If no satellite match: segments stay FLOATING; output relative trajectory only. User manual anchors (POST /jobs/{id}/anchor) become critical. | High |
+
+**Recommendation**: (1) Support multiple satellite providers and tile vintages; (2) expose FLOATING status clearly in API/UI; (3) encourage manual anchors when automatic matching fails; (4) consider alternative references (e.g., OSM, DEM) for coarse alignment.
+
+**Sources**: IEEE 8793558; MDPI oblique-robust; Springer Applied Geomatics; MDPI OpenStreetMap fusion.
+
+---
+
+## Summary Recommendations
+
+### PyTorch Model Loading
+1. Use PyTorch 2.10.0+.
+2. Add SHA256 verification for all model weights, especially LiteSAM from Google Drive.
+3. Prefer safetensors where available; document and pin checksums for pickle-based weights.
+4. Isolate model loading (e.g., subprocess, restricted permissions) if loading from untrusted sources.
+
+### GTSAM iSAM2
+1. Implement drift thresholds and segment splitting for long VO-only chains.
+2. Tune PriorFactorPose2 and BetweenFactorPose2 noise from VO/satellite statistics.
+3. Wrap `isam.update()` with error handling for IndeterminantLinearSystemException and memory errors.
+4. Profile memory/CPU for 3000+ frame trajectories.
+
+### Segment Reconnection
+1. Use geometric + visual validation before merging nearby anchored segments.
+2. Define reconnection order (e.g., by anchor confidence, temporal order).
+3. Handle FLOATING-only scenarios: clear API/UI status, manual anchor support, multi-provider satellite tiles.