Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File is not a database #1814

Closed
mtissington opened this Issue Mar 22, 2019 · 28 comments

Comments

Projects
None yet
4 participants
@mtissington
Copy link

mtissington commented Mar 22, 2019

I'm using the latest nightly build from 22/3/19 with Windows 10

I have a main encrypted database and an plain database.

I open the encrypted database and try to attach the plain database.
After choosing the name for the attached database I get back an error "File is not a database"

As a side note - it seems there are several errors working with attached database.

@chrisjlocke

This comment has been minimized.

Copy link
Contributor

chrisjlocke commented Mar 23, 2019

(Linked to issue #1799 )

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 23, 2019

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. 😉

MKleusberg added a commit that referenced this issue Mar 25, 2019

Fix attaching an unencrypted database to an encrypted database
When opening a plain database and trying to attach an unencrypted
database we need to explicitly specify that there is no key for the
attached database. Otherwise SQLCipher is going to use the same key as
for the main database which results in an error.

See issue #1814.
@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

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 😄

@mtissington

This comment has been minimized.

Copy link
Author

mtissington commented Mar 25, 2019

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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. 😄

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

No worries, just let me know. 😄

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

Just committed the second fix 😄

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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

Investigating...

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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

@mtissington

This comment has been minimized.

Copy link
Author

mtissington commented Mar 25, 2019

Hmm, still getting both the errors.

(I did a complete uninstall of previous version first)

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

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.

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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...

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

Wrong branch maybe?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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". 😉

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

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.

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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. 😉

@mtissington

This comment has been minimized.

Copy link
Author

mtissington commented Mar 25, 2019

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

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. 😄

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 25, 2019

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
@mtissington

This comment has been minimized.

Copy link
Author

mtissington commented Mar 25, 2019

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.

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 25, 2019

Yay! Good stuff everyone! 🕺

@justinclift justinclift referenced this issue Mar 26, 2019

Closed

3.11.2 - outstanding pieces #1773

13 of 13 tasks complete
@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Mar 27, 2019

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Mar 30, 2019

Closing this now, as it seems fixed. 😄

MKleusberg added a commit that referenced this issue Mar 30, 2019

Fix attaching an unencrypted database to an encrypted database
When opening a plain database and trying to attach an unencrypted
database we need to explicitly specify that there is no key for the
attached database. Otherwise SQLCipher is going to use the same key as
for the main database which results in an error.

See issue #1814.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.