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

Transferring vault to a different machine #60

Closed
hrishikeshrt opened this issue May 18, 2021 · 3 comments
Closed

Transferring vault to a different machine #60

hrishikeshrt opened this issue May 18, 2021 · 3 comments

Comments

@hrishikeshrt
Copy link

Is it possible to transfer the vault to a different machine? I tried copying my ~/.vault directory, however on a new machine it does not accept the master key

@gabfl
Copy link
Owner

gabfl commented May 18, 2021

@hrishikeshrt copying the directory is the correct way to migrate
Are you sure the correct dependencies are installed? https://github.com/gabfl/vault#installation-and-setup
This could explain your issue

@hrishikeshrt
Copy link
Author

hrishikeshrt commented May 18, 2021

Installation is correct (or at least I feel so, because I can have a local vault on both the systems, but if I transfer one .vault folder to the other machine, it no longer accepts master key.)

To elaborate,
machine A: pyvault 2.4, local vault exists and works (sqlalchemy 1.3.22, sqlcipher3 0.4.5)
machine B: pyvault 2.4, local vault exists and works (sqlalchemy 1.3.22, sqlcipher3 0.4.5)

Transfer .vault from A to B, the entry screen that asks for master key, says that master key is incorrect.
Same, the other way around.

Both systems are Ubuntu 18.04. One has python 3.8.8, the other has 3.8.5, but I didn't think that would be an issue.

Edit: I updated the python version, and did not make a difference.

@hrishikeshrt
Copy link
Author

hrishikeshrt commented May 18, 2021

Okay, it seems like the version of apt package libsqlcipher-dev was different on both systems, one was 3.4.1 while the other was 4.3.0.
I upgraded the 3.4.1 system to 4.3.0 and now it opens the vault. (Needless to say, now it breaks the local vault, but that is okay for my use case since I wanted to transfer the vault anyway)

Still, I feel like this was somewhat unexpected behaviour, potentially breaking vault across versions without any clear indication of why (since no error is thrown, just key isn't accepted). I am wondering if it's a good idea to note the system's libsqlcipher-dev version (and any other versions which might affect) in the config file, so that replication is possible.
(Another one of the sad scenarios could be an apt upgrade breaking the vault)

On further reading, it seems like newer versions can open older databases. More about the incompatibility and workarounds mentioned here: https://www.zetetic.net/blog/2018/11/30/sqlcipher-400-release/ in the Compatibility section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants