Anyone on Windows have time to test a SQLCipher enabled beta?

Hi all,

A few days ago, we (the “DB Browser for SQLite” team) released the first beta for our next release:

    https://github.com/sqlitebrowser/sqlitebrowser/releases/tag/v3.9.0-beta1

The proper release (should be this weekend) will be our first supporting SQLCipher on Windows. :smiley:

Does anyone here (hopefully SQLCipher experts) have some time to try it out and verify things in the beta are ok, before the full release?

We’re not encryption experts by any means… so we’re more doing our best and hoping it turns out ok. :wink:

With luck, this upcoming 3.9.0 release will be really good promo for SQLCipher. Our current one (3.8.0) has a shade over 700,000 downloads for Windows so far (yay!). :slight_smile:

Regards and best wishes,

Justin Clift

1 Like

As an additional data point, the changes we made to the SQLCipher Makefile.msc so it compiles on Windows are described in detail here:

    https://github.com/sqlitebrowser/sqlitebrowser/wiki/Win64-setup-—-Compiling-SQLCipher

The change of -DSQLITE_TEMP_STORE from 1 to 2 was done as recommended, though I’m personally curious why that’s not 3 to force them to always be in memory. 2 sounds like it could write to disk on occasion anyway, though I’m unsure.

Hi @justinclift - excellent work. I just gave it a try on windows and it worked very well for me. It’s nice to see a new windows option out there for SQLCipher database management. Let us know when you release the final version and we’ll update our article on management interfaces to indicate that Windows is now supported. Out of curiosity, will you supply signed builds for the final releases? Windows SmartScreen under Windows 10 won’t install the package without a manual override, which might be either concerning or confusing to users.

With regard to the question about SQLITE_TEMP_STORE, we’ve typically used 2 since it forces everything to memory by, but still allows a developer or user to override that decision at runtime using a pragma if necessary. This can be useful in some circumstances, for instance:

  1. If there is limited memory available on the system, and there is an explicit decision to use temp storage on disk
  2. You are using SQLCipher to work with unencrypted databases (as is often the case when SQLCipher is compiled into an application)
  3. If you are dealing with truly large data sets where in memory temp tables aren’t feasible, and again there is an explicit decision to use on disk temp storage

This approach satisfies the criteria of having the database library never write secure data in an unencrypted form to permanent storage without explicit consent without locking the developer in.

That said, for the vast majority of typical SQLCipher use cases, SQLITE_TEMP_STORE=3 is just as good and perhaps better. We’ll consider this a bit further, and may adjust our recommendations in the future.

Thanks @sjlombardo. :smiley:

The final version should be released this weekend. No new major bugs turned up in the beta, so we’ve just been tidying some things up and waiting for outstanding translations. (99% done now)

Signing releases is on our ToDo list, for both Windows and OSX. But it won’t happen for the release this weekend.

We’re fairly committed to getting back into shorter release cycles (eg 6-8 weeks), and it’s likely the ones after this will be signed. eg: 3.10.0 onwards

Thanks for the info re: SQLITE_TEMP_STORE too. That’s useful. :slight_smile:

Well, it turns out the certificate signing might happen for this release after all. The cheapest place for the Windows ones seems to be through StartCom.

Already had a basic account with them (they give out free SSL certificates :slight_smile:), so going to try out for their code signing certificates too.

We just released “DB Browser for SQLite 3.9.0”:

    https://github.com/sqlitebrowser/sqlitebrowser/releases/tag/v3.9.0

All builds (Win32, Win64, OSX) include SQLCipher, and the downloads are even digitally signed too. :smiley:

Thanks for highlighting the signing thing as an issue @sjlombardo. It meant we bumped up it’s priority and got it done for this release. :slight_smile:

Hi @justinclift - that’s great news, congrats. We’ve just updated our Management Interfaces article to reflect that DB Browser for SQLite now supports SQLCipher on Windows, and we included a screenshot as well.

Excellent, thank you heaps @sjlombardo. :smile: