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

agit only stores host keys while session is active #107

Open
jwir3 opened this issue Mar 20, 2014 · 4 comments
Open

agit only stores host keys while session is active #107

jwir3 opened this issue Mar 20, 2014 · 4 comments

Comments

@jwir3
Copy link
Contributor

jwir3 commented Mar 20, 2014

The following code, at the beginning of CuriousHostKeyRepository, initializes the knownKeys hashmap for the application:

    Map<String, byte[]> knownKeys = newHashMap();

Unfortunately, as soon as the application closes, this knownKeys hashmap is removed. This forces the user to accept a prompt for a host key that is deemed "curious" the next time the app is run. This degrades sync on these repos, because it requires the user to accept the host key if agit wasn't previously running (thus it can't happen in the background).

My suggestion would be (as a naive implementation) to store accepted host keys in the preference store. The down side to this, though, is that when a repository is removed, the associated keys should also be removed from the preference store for the host on which the repo was located (unless there exists another repo with the same host).

@jwir3
Copy link
Contributor Author

jwir3 commented Mar 21, 2014

After looking into how connectbot does this, I think that we should utilize a similar approach, with an SQLite database dedicated to hosts (rather than prefs):
https://github.com/connectbot/connectbot/blob/master/src/org/connectbot/util/HostDatabase.java

Perhaps we could actually leverage connectbot to keep track of these for us, so we don't have to keep track of our own hosts? It would be really great if, when querying for an ssh connection, we simply determined if the host to which we're connecting is among the known hosts of our ssh client.

@rtyley
Copy link
Owner

rtyley commented Mar 21, 2014

Hi @jwir3 - apologies for not getting back to you, will review PRs this weekend with any luck. Regarding saving HTTP credentials, bear in mind the user /can/ put them into the clone url: https://github.com/rtyley/agit/wiki/HTTP

...given that, is there a good argument for putting another persistence path into place?

One possible action might be to amend the remote url with the credentials after they're supplied by the user.

@rtyley
Copy link
Owner

rtyley commented Mar 21, 2014

Whoops, your post was about trusted SSH hosts, not HTTP. Apologies again.

It would be really great if, when querying for an ssh connection, we simply determined if the host to which we're connecting is among the known hosts of our ssh client.

Agreed, this is exactly what we would want. Requires an additional patch to ConnectBot though

@jwir3
Copy link
Contributor Author

jwir3 commented Mar 31, 2014

Agreed, this is exactly what we would want. Requires an additional patch to ConnectBot though

I can look into this, but one thing that is suboptimal about this approach is that we're going to be tying ourselves specifically to ConnectBot. I'm not particularly opposed to this, but it might be nice for a user who wanted to use some other SSH client to be able to. (I suppose this would require some type of system-level manager of keys, which probably is beyond the scope of this issue).

At any rate, perhaps we should consider adding support for SQLite. The rationale being that preference storage isn't really designed for storing things like host keys, and we'd need to persist them somehow. If we really don't want to add the logic to agit, then perhaps we should consider shipping a version of ConnectBot with agit so that we don't have users thinking they can use a separate client when they actually can't.

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