Given that SQLite is intended as a replacement for fopen(), I'm not sure how many normal files an application uses (or should use) are (or should be) encrypted. I cannot think of a lot of use cases.
At work we need to because we are distributing map data that was licensed to use under the condition that we don't ship the data unencrypted to the clients, however nonsensical that is, given that you have to distribute the encryption key the same way.
But for use cases like Lightroom which stores its catalog in an SQLite database or Far Manager which stores the config there I very much doubt they should be encrypted by default.
> Given that SQLite is intended as a replacement for fopen(), I'm not sure how many normal files an application uses (or should use) are (or should be) encrypted. I cannot think of a lot of use cases.
SQLite has been under development for thirteen years and has hundreds of releases. I don't think the "feature X? you're doing it wrong, we're just a simple replacement for fopen()!" refrain holds a lot of water at this point.
FTR when you work in the financial industry, all kinds of files and databases get encrypted. I agree that encrypting a file or database is not extremely secure since the decryption key is sure to be nearby, but it's still an important need, there are security audits and all kinds of things that call for encryption when available.
That said, it's the financial industry. If the encryption feature is offered as a paid one, that's not so terrible.
Personally I don't like it when projects mix money with opensource.