(Linked to issue #1799 )

Yeah, it sounds like something needs a bit of tweaking in the SQLCipher vs SQLite attachment code. 😦

@MKleusberg This one's probably also related to #1758. 😉

Thanks @mtissington! Looks like I didn't read the SQLCipher documentation carefully enough 😉 This is the problem here:

If no KEY paramater is specified then the attached database will use the exact same raw key and database salt as the main database

It should be fixed in tomorrow's nightly build. Can you double check it's working for you? We can then include the fix in our 3.11.2 release 😄

@MKleusberg - great, thanks - I know the problem 😉

I'll launch the Win64 nightly build script again in a minute, so there's something to test sooner (~1/2 hour) rather than later. Hopefully that helps. 😄

@justinclift Wait a second - if things go well I will have a patch for #1799 too 😄

No worries, just let me know. 😄

Just committed the second fix 😄

Cool. Just restarted the Win64 build. I'll do the Win32 one afterwards too, just to keep them even. 😄

Ugh. Something has gone wrong with the VM. It can't see the outside network at all. 😦

Investigating...

k. Win64 build is running again now. This time it should run ok. 😉

Wind64 build for testing:

• https://nightlies.sqlitebrowser.org/latest/DB.Browser.for.SQLite-win64.msi
• https://nightlies.sqlitebrowser.org/latest/DB.Browser.for.SQLite-win64.zip

Hmm, still getting both the errors.

(I did a complete uninstall of previous version first)

Very strange. Especially the problem from issue #1799 seems so obvious in hindsight that I'm pretty sure it should be fixed.

@justinclift Are you sure the latest commits are included in the build? I just downloaded the zip file from the latest nightly link, unpacked it, and tried this:

$ strings DB\ Browser\ for\ SQLCipher.exe  | grep kdf_iter
PRAGMA sqlitebrowser_edit_encryption.kdf_iter = %1
PRAGMA kdf_iter = %1;
PRAGMA %1.kdf_iter = %2

While this isn't really the safest method, it looks like there is no mention of cipher_default_kdf_iter which should be in there since this commit.

Hmmm, it does sound like something went wrong.

I'll manually run the Win64 build again, watching as it does so. Gimme a few mins...

Wrong branch maybe?

Nope. That particular script file is hard coded to master. Something truly bizarre would have to have gone wrong for it to be the wrong branch. That being said... we are talking computers after all, so I won't say "impossible". 😉

Heh heh, I'm curiously awaiting your results then 😄 I have just updated issue #1777 because it could suffer from the same problem. In that case the problem would be at least 20 days old or so.

Just noticed something interesting. On the VM itself, in the directory the builds get saved to prior to upload... the Win32 .msi and .zip, and the Win64 .zip have correct looking timestamp entries.

The Win64 .msi has a timestamp that's wrong. It's a timestamp from the morning run.

Something seems to have gone wrong with that Win64 build. The .zip version might be ok, but not sure. Nuking then running things again now. 😉

I tried the zip version too, same issues ...

Try the Win32 build. The timestamp on that looks ok.

I've just watched the new Win64 build pull down the source and change branches. So far it's grabbed the right pieces. If 😉 the build completes ok, then the potential fixes will be in it. 😄

Win64 build finished without issue. Hopefully this does fix the problem. 😄

• https://nightlies.sqlitebrowser.org/latest/DB.Browser.for.SQLite-win64.msi
• https://nightlies.sqlitebrowser.org/latest/DB.Browser.for.SQLite-win64.zip

Looks promising 👍

$ strings DB\ Browser\ for\ SQLCipher.exe  | grep kdf_iter
PRAGMA sqlitebrowser_edit_encryption.kdf_iter = %1
PRAGMA kdf_iter = %1;
PRAGMA cipher_default_kdf_iter = %1

Looking very good 😄 ... initial testing seems to fix #1777 #1814 and #1799 ...
Good job guys ... I'll test more but I think this is it.

Yay! Good stuff everyone! 🕺

Awesome! Let's hope the build problem was just a transient thing 😄

Closing this now, as it seems fixed. 😄