tursodatabase
Enable encryption for mobile targets
Why?
#1423 introduced support for React Native however encryption was disabled due to the difficulty in getting successful builds with encryption enabled:
- Encryption seems to be compiling sqlcipher (?) via cmake, which also includes OpenSSL flags, the problem the compilation step is hard to integrate with Android (and that's why I had to disable it). Someone else that knows the internals of libsql should give it a try.
– https://github.com/tursodatabase/libsql/pull/1423#issuecomment-2186259989
With encryption disabled, libSQL on React Native does not have feature parity with other platforms.
What?
This PR enables encryption for builds against mobile targets. However, while the encryption feature is enabled, there is additional work to get the encryption feature fully complete:
P.S. if you do turn on encryption, it will require a modification to the bindings to send the encryption key from JS, so, open a PR when the time comes and I will take a look.
– https://github.com/tursodatabase/libsql/pull/1423#issuecomment-2186259989
How?
- The encryption feature of the libSQL dependency in the C bindings package has been enabled for all targets.
- Build scripts and configurations in the libSQL FFI package have been updated so that libSQL products for each target and the OP SQLite Example App build successfully; and the tests against the OP SQLite Example App pass.
I'm not actually familiar with Android/iOS/C/Rust build systems, or libSQL / OP SQLite internals so configuration decisions were based on a feedback loop of running make <android|ios> in bindings/c and making updates until builds in libSQL and the OP SQLite Example App were successful. I'm unsure if there's anything else to check and will have to defer to Turso team members and @ospfranco for their knowledge.
@ospfranco: given my unfamiliarity, would you mind expanding on this comment on #1423 please?
P.S. if you do turn on encryption, it will require a modification to the bindings to send the encryption key from JS, so, open a PR when the time comes and I will take a look.
I see there's some logic for cross compilation: https://github.com/tursodatabase/libsql/blob/c6ebbe1b23a5dc7d950b2a4ad33fc33c849e462f/libsql-ffi/build.rs#L457-L509
Would it be better to somehow work within this, instead of the changes currently proposed (79ff682)?
@penberg, because it was hard to cross-compile sqlite3mc to mobile targets. But apparently, its possible with a few tweaks.
Thank you @winghouchan, for picking this up. libsql is fantastic on mobile devices (thanks to op-sqlite), but the lack of database encryption is definitely problematic. I would love to see this get merged in.
Just a small comment in passing, I had difficulties building 0.9.19 with encryption for Android, but by adapting some of the changes from this PR in lbsql-ffi's build.rs with the new cmake based build, I got it to work. This PR should be updated and merged
@Geal: interesting comment. Out of curiosity, what issues did you have? I thought #2099, released in 0.9.11, made this PR obsolete but I haven't had confirmation from @levydsa when I sought to confirm.
Would you be able to share what you needed to make it work? I haven't tested with the latest libSQL versions since #2099 was released because this isn't a priority for me. Additionally, I'd need interest from the libSQL team in merging this or letting me know they plan on resolving it themselves – otherwise my effort will be a waste.
The issues were related to cmake not finding the NDK and toolchain. I am using the gradle rust android plugin. I'll try to make a reproducer and share it. Apparently it was working with 0.9.17 but the update to 0.9.19 broke it
@Geal: interesting, thanks for sharing those details. Looking at a diff/blame between 0.9.17 and 0.9.19 might be interesting. Btw, if you think it's suitable, it may be worth making a PR that supersedes this PR with your changes. Your changeset is probably smaller than mine and will work with the changes introduced by #2099.