Page MenuHomePhabricator

[native] Set SQLite DB password to `DEBUG` for `DEBUG` builds
ClosedPublic

Authored by atul on Mar 29 2023, 1:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 17, 5:45 AM
Unknown Object (File)
Tue, Dec 17, 5:45 AM
Unknown Object (File)
Tue, Dec 17, 5:45 AM
Unknown Object (File)
Tue, Dec 17, 5:45 AM
Unknown Object (File)
Tue, Dec 17, 5:41 AM
Unknown Object (File)
Thu, Dec 12, 12:09 PM
Unknown Object (File)
Wed, Dec 4, 3:29 AM
Unknown Object (File)
Wed, Dec 4, 3:28 AM
Subscribers

Details

Summary

Interacting with the SQLite DB can be a huge pain since the path and password change on every clean install.

In the past, if you wanted to open a SQLite DB in TablePlus/DataGrip/etc, you needed to add some logging that printed SQLiteQueryExecutor::encryptionKey in addition to the DB PATH. This makes it easier and harcodes the password to DEBUG for DEBUG builds.

Test Plan

Tested iOS debug/release build and observed that DEBUG unlocked the SQLite DB under debug, but NOT under release.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul published this revision for review.Mar 29 2023, 1:50 PM

What happens if you deploy a debug build to an iOS device that previously had a release build? It would be able to keep using the previously determined encryptionKey, right? (And vice versa, going from debug to release?)

This revision is now accepted and ready to land.Mar 29 2023, 2:31 PM

What happens if you deploy a debug build to an iOS device that previously had a release build? It would be able to keep using the previously determined encryptionKey, right? (And vice versa, going from debug to release?)

Yeah:

f7bdac.png (246×1 px, 65 KB)

If DB already exists at path and there's a key for secureStoreEncryptionKeyID in secure store we skip assign_encryption_key altogether.

This revision was landed with ongoing or failed builds.Mar 29 2023, 3:51 PM
This revision was automatically updated to reflect the committed changes.