SQLCipher & SQLite update


#1

I understand that the current version of SQLCipher uses SQLite 3.4.1. Our scanning tools report certain vulnerabilities in this embedded library and recommends to upgrade to SQLite 3.21.0. Is there any plan when SQLCipher will support this version of SQLite?


#2

Hello @Deepak_D_C

Thank you for your interest in SQLCipher. The current release of SQLCipher is 3.4.1 which is based on SQLite 3.15.2. We are currently updating SQLCipher for all of our supported platforms which will include an update to the SQLite upstream based on 3.20.1. SQLite 3.21.0 was just released a few weeks ago. Historically we allow for a stabilization period before integrating a new upstream SQLite release. Please let us know if you have any further questions. Thanks!


#3

Hi @developernotes
We have also problem with the SQLite vulnerabilities, which probably blocks our product delivery.
Is there any chance that this SQLite update will be ready by January? Do you have a target date?
Thanks!


#4

Hello @strehli

We anticipate a new release of SQLCipher will be available soon. Unfortunately, I can not comment on a specific date however we are nearing completion of our release cycle.


#5

Thanks for the quick response @developernotes.
Good to see SQLite 3.20.1 is already merged, bad news for us that this version brings a new vulnerability:
https://nvd.nist.gov/vuln/detail/CVE-2017-15286
Looking forward to the next version! :slight_smile:


#6

Hello @strehli Thanks for keeping an eye out and following up. The next release of SQLCipher will likely occur in the new year, and will probably be based on 3.21.0 or 3.22.0 (depending on timing). Upstream fixes in SQLite would be merged in then. A few other comments with regard to the CVE in question: it specifically deals with the SQLite shell, which is not used by applications linking SQLCipher (though the underlying problem may still pertain), it’s not clear whether that issue has been fixed upstream at this point, and finally, SQLCipher likely reduces the risk / impact, at least for the class of applications that is not dealing with untrusted plaintext databases from third parties (given that a specifically corrupted database and processing logic is required).


#7

Same here. Looking forward to a new release.


#8

@developernotes Can you provide some information on how to perform an upgrade.
What steps do I need to follow to perform my own upgrade to SQLite 3.21.0 ?


#9

Hello @GJRTimmer - Unfortunately we don’t support ad hoc migrations to different versions of SQLite like that. Each release is integrated and tested specifically to avoid differences between SQLCipher and SQLite upstream, and to minimize the risk of breaking changes to SQLCipher. The next release will likely be based on 3.23.0 once that is available and has stabilized.


#10

@developernotes @sjlombardo I’m not talking about a official release. I would like to know how to do it my self for my own projects at my own risk.

I’ve already obtained the fossil repository of SQLite, and the github repo of SQLCipher. I ust would like to learn how to integrate a new SQLite version within SQLCipher and get a succesful build.

I also understand that you are not looking towards people submitting a PR on Github with a new SQLite upgrade, because that would defeat the purpose of testing as you explained earlier.

I just would like to know for my own projects how to integrate SQLite3 into SQLCipher.

Hope you guys can put me in the right direction.


#11

Hello @GJRTimmer - In that case, one option would be to take a diff between the current upstream SQLite 3.20.1 source tree and the new SQLite 3.21.0 source tree. Then take the results of that diff and apply it to the SQLCipher 3.4.2 sources, resolve any merge failures, etc. You could then build and run the crypto.test locally to perform some basic validation and do your own testing as needed. For clarity, this is not the approach we use internally, but would probably yield similar results. Again, I’d just caution that there are some risks involved here, so use caution / discretion as appropriate.


#12

@sjlombardo

Thank you very much. Thanks for pointing me in the right direction.


#13

@GJRTimmer no problem at all, I hope it works well for you. One other clarification with regard to crypto.test - that would involve make testfixture and ./testfixture test/crypto.test in order to perform a basic validation of sqlcipher functionality.