Research Document: OpenDAL Upgrade Analysis
Status: Review Author: Terraphim AI Date: 2026-03-11 Scope: Investigate upgrading opendal to eliminate transitive security advisories
Executive Summary
Current State: opendal v0.54.1 with sled v0.34.7 backend brings in:
fxhashv0.2.1 (RUSTSEC-2025-0057)instantv0.1.13 (RUSTSEC-2024-0384)
Finding: OpenDAL 0.55 still includes sled service with same dependency chain. The advisories are in transitive dependencies (sled → parking_lot → instant/fxhash) and cannot be eliminated without:
- Sled upgrading its dependencies (unlikely - sled is in maintenance mode)
- OpenDAL removing sled support (not planned)
- Using non-sled backends only
Recommendation: Accept risk and document, or disable sled feature if not used.
Essential Questions Check
| Question | Answer | Evidence | |----------|--------|----------| | Energizing? | Yes | Security debt elimination | | Leverages strengths? | Yes | Dependency management | | Meets real need? | Partial | Advisories are in transitive deps, not our code |
Proceed: Partial - investigate alternative backends
Current Dependency Chain
opendal v0.54.1 (current)
└── sled v0.34.7
├── fxhash v0.2.1 (RUSTSEC-2025-0057) ← advisory
└── parking_lot v0.11.2
└── instant v0.1.13 (RUSTSEC-2024-0384) ← advisoryOpenDAL 0.55 Analysis
From changelog (2025-11-11):
refactor: migrate sled service from adapter::kv to impl Access directly- Sled service still exists - just implemented differently
- No indication that sled or its dependencies were removed
Breaking Changes in 0.55
Schemeenum → string-based (major API change)- Removed deprecated
Operator::from_map/via_map - Migrated from chrono to jiff
- MSRV bumped to 1.85, edition 2024
Backend Analysis
What backends do we currently use?
From terraphim_persistence/Cargo.toml:
services-memory(always enabled)services-sqlite(optional)services-dashmap(optional)services-s3(optional)services-redis(optional)services-redb(optional)services-ipfs(optional)
No explicit sled feature - sled is pulled in as a transitive dependency of opendal core.
Where is sled used in opendal?
- Sled is a default-enabled service in opendal
- Even if we don't use it, it's compiled in
Options for Resolution
| Option | Effort | Risk | Impact | |--------|--------|------|--------| | Upgrade to opendal 0.55 | Medium | High (breaking changes) | Low (sled still present) | | Disable sled in opendal | Medium | Medium | High (if we can patch) | | Use alternative backend | Low | Low | Medium (sqlite/dashmap/redis) | | Accept risk | None | Low | Document advisories |
Recommendation
Short-term: Accept the transitive dependency risk. The advisories are:
instant: Unmaintained but functional (used by parking_lot)fxhash: Unmaintained but functional (used by sled)
Neither affects our code directly - we use std::time::Instant and no fxhash.
Long-term:
- Monitor sled/parking_lot for updates
- Consider switching to
redborsqlitebackend if persistence needs change - Open issue upstream with sled to update dependencies
Code Locations
OpenDAL Usage
| File | Purpose |
|------|---------|
| crates/terraphim_persistence/src/lib.rs | Core persistence with Operator |
| crates/terraphim_persistence/src/settings.rs | Device settings persistence |
| crates/terraphim_service/src/lib.rs | Service layer integration |
| crates/terraphim_config/src/lib.rs | Config persistence |
Backends Used
Based on Cargo.toml features:
- Default: memory, sqlite, dashmap
- Optional: s3, redis, redb, ipfs
Upgrade Path (if needed)
If upgrading opendal becomes necessary:
- Bump version in 4 Cargo.toml files
- Fix API changes:
Scheme::Memory→"memory"(string-based)- Remove
from_mapusage
- Test all backends
- Verify no regressions
Estimated effort: 2-4 hours
Appendix
Verification Commands
# Check sled dependency
# Check opendal features
|
# Check opendal usage
OpenDAL Changelog
- v0.55.0 (2025-11-11): https://github.com/apache/opendal/releases/tag/v0.55.0
- Key: sled service migrated but still present