github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 07:04:23 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #7894] [Feature] Add At-Rest Encryption for Local SQLite Databases #92849

New Issue
Closed
opened 2026-05-26 04:48:02 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-05-26 04:48:02 -05:00
Owner
Copy Link

Originally created by @crazykid95 on GitHub (May 19, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7894

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

Actual Budget currently stores local SQLite database files in plaintext on user devices. Because the application contains sensitive financial information, this creates a risk where transaction history and other accounting data may be exposed if local files are accessed by malware, backup systems, shared devices, or other unintended parties.

While securing the local device is ultimately the user’s responsibility, Actual Budget handles highly sensitive financial records, and stronger default protection for data at rest would significantly improve the overall security posture of the application.

At the moment:

  • Every synced device contains a readable local copy of the ledger/database
  • SQLite database files can potentially be inspected directly
  • Sensitive financial data remains exposed when the application is not running
  • Multi-device usage increases the number of plaintext copies stored locally

This is especially concerning for:

  • Shared computers
  • Lost or stolen devices
  • Unencrypted backups
  • Malware or opportunistic data collection

Describe your ideal solution to this problem

Please add optional (or default) encryption for local SQLite databases used by Actual Budget.

Suggested requirements:

  • Encrypt all financial data stored locally at rest
  • Decrypt data only in memory while the application is running
  • Protect the SQLite database file itself from direct inspection
  • Integrate with OS-native secure credential/key storage where possible
  • Provide a secure migration path for existing plaintext databases

Possible implementation approaches:

  • SQLCipher
  • SQLite encryption extensions
  • Application-layer encryption before persistence

Teaching and learning

No response

Originally created by @crazykid95 on GitHub (May 19, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7894 ### Verified feature request does not already exist? - [x] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? Actual Budget currently stores local SQLite database files in plaintext on user devices. Because the application contains sensitive financial information, this creates a risk where transaction history and other accounting data may be exposed if local files are accessed by malware, backup systems, shared devices, or other unintended parties. While securing the local device is ultimately the user’s responsibility, Actual Budget handles highly sensitive financial records, and stronger default protection for data at rest would significantly improve the overall security posture of the application. **At the moment:** - Every synced device contains a readable local copy of the ledger/database - SQLite database files can potentially be inspected directly - Sensitive financial data remains exposed when the application is not running - Multi-device usage increases the number of plaintext copies stored locally **This is especially concerning for:** - Shared computers - Lost or stolen devices - Unencrypted backups - Malware or opportunistic data collection ### Describe your ideal solution to this problem Please add optional (or default) encryption for local SQLite databases used by Actual Budget. **Suggested requirements:** - Encrypt all financial data stored locally at rest - Decrypt data only in memory while the application is running - Protect the SQLite database file itself from direct inspection - Integrate with OS-native secure credential/key storage where possible - Provide a secure migration path for existing plaintext databases **Possible implementation approaches:** - SQLCipher - SQLite encryption extensions - Application-layer encryption before persistence ### Teaching and learning _No response_
GiteaMirror added the featureneeds votes labels 2026-05-26 04:48:03 -05:00
GiteaMirror commented 2026-05-26 04:48:07 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 19, 2026):

✨ Thanks for sharing your idea! ✨

This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don't forget to upvote the top comment with 👍!

<!-- gh-comment-id:4487122612 --> @github-actions[bot] commented on GitHub (May 19, 2026): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don't forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature needs votes
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#92849
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?