PackageReference Include="SQLitePCLRaw.bundle_e_sqlcipher" Version="2.1.11 got program alignment (8192) cannot be smaller than system page size (16384)

[Natanael-Oktavian]

Hi , we are preparing our .net android 9 apps (not Maui) to support playstore 16 kb page requirement

So we already update sqlite reference to

	<PackageReference Include="SQLitePCLRaw.bundle_e_sqlcipher" Version="2.1.11" />
	<PackageReference Include="SQLitePCLRaw.core" Version="3.0.2" />
	<PackageReference Include="SQLitePCLRaw.lib.e_sqlcipher.android" Version="2.1.11" />
	<PackageReference Include="SQLitePCLRaw.provider.e_sqlcipher" Version="2.1.11" />

and the 4 KB warning already disappear in Android Studio apk analyzer, but when we run the apps we got
lib/arm64/libe_sqlcipher.so" program alignment (8192) cannot be smaller than system page size (16384) (SS attached)

natanaelmr@natanaels-mbp arm64-v8a % greadelf -l libe_sqlcipher.so

Elf file type is DYN (Shared object file)
Entry point 0x14590
There are 8 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001a5e58 0x00000000001a5e58 R E 0x4000
LOAD 0x00000000001a63b0 0x00000000001aa3b0 0x00000000001aa3b0
0x0000000000007100 0x000000000000f950 RW 0x4000
DYNAMIC 0x00000000001a96e8 0x00000000001ad6e8 0x00000000001ad6e8
0x0000000000000200 0x0000000000000200 RW 0x8
NOTE 0x0000000000000200 0x0000000000000200 0x0000000000000200
0x0000000000000024 0x0000000000000024 R 0x4
NOTE 0x00000000001a5dc0 0x00000000001a5dc0 0x00000000001a5dc0
0x0000000000000098 0x0000000000000098 R 0x4
GNU_EH_FRAME 0x00000000001924c0 0x00000000001924c0 0x00000000001924c0
0x00000000000037b4 0x00000000000037b4 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x00000000001a63b0 0x00000000001aa3b0 0x00000000001aa3b0
0x0000000000003c50 0x0000000000003c50 R 0x1

greadelf also already return 16 KB in the LOAD

But somehow when we run it says program alignment is 8 KB

Please advice is there anything more to be updated beside that package reference? Thanks

[ericsink]

As of SQLitePCLRaw 3.x, I no longer distribute encryption builds of SQLite at no cost. See the release notes for more information:

https://github.com/ericsink/SQLitePCL.raw/blob/main/v3.md

The binaries in SQLitePCLRaw.lib.e_sqlite3.android do not support the Android 16KB page requirement. This package will be marked deprecated soon.

[Natanael-Oktavian]

Hi @ericsink thanks for the reply , so i now have two options cause i have 2 apps that use sqlcipher library now, but 1 doesnt actually use the encyption feature (pragma key)
for that apps, now i can just replace the package reference to this right?

<PackageReference Include="sqlitepclraw.config.e_sqlite3" Version="3.0.1" />
<PackageReference Include="sourcegear.sqlite3" Version="3.50.3" />

and for the second apps that use pragma key feature i should buy the licensed from zeletic or build the open source https://github.com/sqlcipher/sqlcipher.git to support 16 kb page size?

thanks

[ericsink]

Yes, that looks right.

For encryption support, additional options include SEE (proprietary, by the SQLite team) and SQLite Multiple Ciphers (open source).

[Natanael-Oktavian]

ok thanks

[Natanael-Oktavian]

hi @ericsink can i have a follow up question :

1. if i want to get the build service in the form of nuget package, using the 2 options you mentions (SqlCipher by Zetetic, should i just buy the licence from Zetetic, or also from the SEE)?
2. if i want to get the nuget package from SQLite3 Multiple Ciphers (SQLite3MC) (SourceGear’s) , same question, do i need to buy SEE license or just buy the license directly from the SourceGear?
3. Is there a free options available by build the open source code ourselved or that is not possible because it will need paid signature / license?
4. To use the 2 options (SourceGear and Zetetic) nuget package, we can just change the source code by change the nuget package and the DllImport path, or there are another changes required?

Thanks

[ericsink]

SEE, SQLCipher, and SQLite3MC are three different implementations of SQLite with encryption support. You ordinarily need only one of the three.

SEE is developed by the SQLite core team, and is proprietary licensed software. Details of the license can be found at sqlite.org.

SQLCipher (developed by Zetetic) and SQLite3MC (developed by @utelle) are open source alternatives to SEE.

None of these implementations were developed by SourceGear, my company.

All three of them are provided as source code. After you purchase a SEE license, you get its source code. SQLCipher and SQLite3MC are open source.

In all three cases, you can just build the source code and use it if you are comfortable building and integrating native code into .NET projects. Because SQLCipher and SQLite3MC are open source, that means you can use them without cost.

AFAIK, none of the three options are provided as nuget packages without cost. I stopped doing this (for SQLite3MC and SQLCipher) with the SQLitePCLRaw 3.0 release.

For SQLCipher, you can buy nuget packages from Zetetic. Their packages work with SQLitePCLRaw.

For SEE, you can buy nuget packages from SourceGear through our SQLite build service. We can also provide nuget packages for SQLite3MC (contact me to discuss that if you are interested). These packages work with SQLitePCLRaw as well.

[ErikEJ]

@ericsink Maybe above is a good topic for a wiki / FAQ?

[ericsink]

Yes. Sometime this week I plan to get this information organized so I can just point people to it.

[utelle]

SEE, SQLCipher, and SQLite3MC are three different implementations of SQLite with encryption support. You ordinarily need only one of the three.

It's not quite that simple: all 3 provide encryption support - but in different ways. That is, they are not interchangeable.

• SEE is published by the SQLite core team and is a commercial product available for a one-time fee. It is closed source, and therefore the details of the used encryption algorithms (i.e. key derivation) are not publicly known. Thus, the encryption is not compatible with any other implementation.
• SQLCipher is published by the Zetetic company. The main implementation is open source under a BSD-like license, but Zetetic offers commercial support and add-ons. The encryption is based on AES-256 - not compatible with SEE.
• SQlite3MC is published by me. It is open source under an MIT license. SQLite3MC has support for various encryption schemes (all not compatible with SEE), among them reading and writing all variants of SQLCipher from version 1 up to the current version 4. However, it is not a drop-in replacement for SQLCipher - for example, PRAGMA names differ and not all SQLCipher PRAGMAs are supported.

AFAIK, none of the three options are provided as nuget packages without cost. I stopped doing this (for SQLite3MC and SQLCipher) with the SQLitePCLRaw 3.0 release.

When I contacted @ericsink about 2 years ago regarding support for SQLite3MC in his SQLitePCLRaw project, I had hoped for long term support, and I'm really sad that he decided against supporting it officially any longer.

There is a discussion about the situation regarding SQLitePCLRaw and NuGet packages. It is planned to provide some sort of solution, but I can't tell yet when that will happen.

However, @tranb3r confirmed that the binaries usually generated in my test environment after a release work (see SQLiteMultipleCiphers-cb, branch sqlite3mc) for Android and iOS. And I'm pretty sure that the binaries for the other platforms should also work.

[ericsink]

all 3 provide encryption support - but in different ways. That is, they are not interchangeable

That's a good clarification.

sad that he decided against supporting it officially

To be clear, I do still support SQLite3MC -- I just don't do it for free. We have customers of our Zumero product who use SQLite3MC, and we still support them. We will continue to offer SQLite3MC nuget packages in our SQLite build service, and each customer who chooses that option will result in a GitHub sponsors contribution to @utelle

It's an issue of sustainability and priorities. I've been maintaining SQLitePCLRaw for 10 years, and I served as a Microsoft MVP for 5 of those years. I feel like I've given a lot of service to "the community". But I've reached a point where I want to be more careful about how I spend my time.

Suppose I were to make a list of all the possible ways I could donate my time and resources, and then sort that list according to my own beliefs about how "deserving" they are. Things like "impoverished children" would be toward the top of the list, and things like "companies that employ software developers" would be toward the bottom.

Folks who want SQLite encryption represent a large percentage of the questions I get. I'm happy for someone else to provide all that free tech support to benefit companies. I'm choosing to shift a bit more of my professional attention toward folks who are willing to pay for my time and effort.