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
add option to automatically sync #277
Comments
Hey, just a thought about this feature. Yes truly this would be a nice function. But currently you need a password for the sync. And i highly discourage from running a password less sync, as then somebody could overwrite your passwords.... So in a way the app has to ask for your password. Maybe the app could look when you open it, if there is a connection and suggest a sync, if the last one is older than a certain amount of time, or the local version has unsynced commits. Greetings |
Well, I don't need a password for syncing as I have a ssh-key without a password. I'd rather have the ssh-key encrypted with the same password as the password for the GPG key and have them linked but that doesn't seem to be an option at the moment. |
Yes, you have that :D My humble opinion was more a general point. |
A bit puzzled here. I have generated an ssh-key within the app, uploaded it to github. When I sync, I always get asked for the ssh password. Is there a way to avoid this? |
@ruvido You get asked for a passphrase automatically because we do not keep any information about your passphrase. We could add an option to remember the ssh-key passphrase, by storing it encrypted using the gpg key. But we wont' encrypt the ssh-key itself using gpg. In the future we'd like to use a gpg subkey for ssh authentication, but that's another story. |
Why not pull upon launch, and push whenever changes are made? |
@ibrokemypie This is the way I'm imagining it to be. It would also have a time limite such as one pull every hour or so. |
In a comment in #378, I suggest allowing the user the select an password entry in the store which is the SSH passphrase. Once this is done, whenever the GPG key is unlocked we have the SSH passphrase. So when the GPG key is unlocked we can push if there is something to push and to pull if a timeout has expired (we could have two timeouts: one for WiFi and the other for data). |
Hi. Is there any news about this feature ? I'm using qtpass on an everyday basis : it automatically refreshes updates and pushes whenever a change occurs and works great for me (git server with ssh key, no password as ssh key is for headless access) |
Not at the moment, and it's unlikely to make it into the June release regardless — we have a lot of changes ongoing and don't have the development bandwidth. I'll consider this for the July release when the time for that comes around. |
@msfjarvis we discussed an option to sync every time the app is launched. Want to implement it that way? |
I can get behind that. |
Cool, I can take a look at it later today. |
Do you guys do 1 git repo per password sharing group/org? |
Should this be re-opened since the feature was reverted? |
Yep. |
Closing as part of issue tracker cleanup. |
It would be great if Android-Password-Store automatically synced the git respository. This is for two reasons. I'm not always connected and would like to have any changes pushed automatically when I next connect. Also, I will never remember to sync when I am connected and so will find myself with stale passwords or conflicts if I edit the same password entry on two devices.
A possible specification: if the local store is dirty Android-Password-Store should sync immediately if connected otherwise at next connection. Otherwise Android-Password-Store should pull every time the app is opened (with a minimum time between pulls). It should also pull at least once a day if connected or at the next connection. It would be good if the sync at opening could be in the background and just update the display if new data arrives.
Perhaps this should be two tickets. One which pushes if dirty and another to implement background pulling.
This should not be implemented before #276 is fixed.
The text was updated successfully, but these errors were encountered: