AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 33 Monero

use SAF (lol) for some android stuff

Public commit record

What the developer wrote

Authored by julian

45/100 · Thin
use SAF (lol) for some android stuff
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how the Stack Wallet app on Android reads and writes files. It replaces a workaround that directly reached into shared phone storage with the proper Android Storage Access Framework (SAF), which asks the user to pick a folder or file before the app can use it. That is generally a security improvement because it reduces the app's direct access to files it does not own. However, the change is large, touches backup/restore code, and some backup paths still appear to use direct file access on non-Android platforms, so it should be reviewed carefully rather than treated as purely safe.

Recommended action

Treat this as a hardening/refactoring change rather than an active vulnerability. Review the new FS helper for edge cases: ensure content:// URIs are validated before use, confirm that backup restore paths cannot be tricked by malicious content:// URIs or path traversal in file names, and verify that the switch from a forked file_picker to the upstream package does not reintroduce permission issues. Test backup creation and restore on Android 10+ scoped-storage devices.

Security signals we found

01

Removal of hard-coded Android shared-storage path helper (wtfAndroidDocumentsPath)

02

Adoption of Android Storage Access Framework (SAF) via saf_util / saf_stream

03

User-mediated directory/file picking on Android replaces direct filesystem access

04

Backup creation now writes encrypted backups through a shared FS helper

05

Validation logic special-cases content:// URIs when checking directory existence

06

Desktop and iOS paths still use direct File I/O and file_picker

Risk score

Why this scored 33/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 7/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.