making remote git storage work [was Re: Subsurface ans Dropbox]

[Dirk Hohndel]

On Wed, May 27, 2015 at 04:36:09PM -0700, Dirk Hohndel wrote:
> 
> But there is _git_ssh_setup_conn() which parses a full URL with username,
> port, everything. So we should be able to set up a URL like
> 
> "git at git.subsurface-divelog.org:2222/reponame"
> 
> and then from reading more of the code it calls
> 
> _git_ssh_authenticate_session()
> 
> which appears to support public/private key authentication.

Yep it does. I have that working

> What am I missing with this proposed flow:
> 
> Subsurface has a UI "connect to remote storage"
> - asks user for email address
> 
> Subsurface connects to our server with that email address and a REST API
> returns an encrypted private key
> 
> The server sends a PIN to the given email address
> - next Subsurface asks for the PIN (and asks if it should store that in
>   the preference)

Actually, I think I'll change that. The "connect to remote storage" API
will offer the user to set a PIN (which basically is the passphrase used
for the private key) and allows the user to either store that locally or
not.
The email address is used to create a unique repository name on the server
and to be able to recover the PIN/passphrase.
None of that is implemented, yet :-)

> - with the PIN it decrypts the private key
> - now using the infrastructure mentioned above it should be able to push /
>   pull the remote data file

Which is something that Linus is planning to implement in Subsurface (so
far all we do is create a local copy / cache of the remote repository but
we don't do updates in either direction).

> When you add a new instance of Subsurface (on Android, or on a different
> computer), you simply enter the same email address and pin, it once again
> gets the encrypted private key via the rest api, the pin is entered in the
> UI...

That's still the way I envision this.

> No configration file magic, no one ever mentions that this is git, it's
> all just a remote storage that is accessed with email and pin.

And this is key to me. No git, no ssh, no passphrase... all we have is an
email address and a pin.

Right now we simply pass git error messages to the UI. That will need to
change, of course.

I just pushed what I have implemented so far

- Subsurface assumes that there is a private key in 
  system_default_directory()/ssrf_remote.key

- There is a preferences field where the user can enter their email
  address (currently unused) and PIN (that's the passphrase used to
  decrypt the private key)

- If you set your default divelog file to the correct URL then Subsurface
  will open and clone that repository into a local cache.
  This has been tested with
  ssh://git@git.subsurface-divelog.org:2222/dives[branchname]
  which is a private repository. Linus and I have access to that and I'm
  pushing the current code so that he can continue to work on this

While Linus fixes that part, I'll figure out the backend infrastructure
that allows me to create unique repositories out of email addresses,
create custom key pairs for it (using the passphrase provided) and do all
this with a REST api that can be used from within Subsurface (and isn't
easily abused to turn my server into anonymous storage for any criminal on
the internets...)

I'm still interested in feedback on the architecture :-)

BTW: for anyone who wants to play with this it should be quite trivial to
use a github repository, add the correct private key to
system_default_directory()/ssrf_remote.key, add the passphrase via the
preferences UI and set the correct default divelog file URL for this to
work...

We'll continue to support that as "advanced mode" or something for people
who don't want to use the Subsurface infrastructure to store their dive
data.

/D