design

doc/design/assistant/sshpassword.mdwn

@@ -10,3 +10,39 @@ securely?
 This might come down to a simple change to the webapp to prompt for the
 password, and then rather a lot of pain to make the webapp use HTTPS so we
 can be pretty sure noone is sniffing the (localhost) connection.
+
+## ssh-askpass approach
+
+* If ssh-askpass is in PATH, do nothing. (Unless webapp is run remotely.)
+* Otherwise, have the assistant set `SSH_ASKPASS` to a command that will
+  cause the webapp to read the password and forward it on. Also, set
+  DISPLAY to ensure that ssh runs the program.
+
+Looking at ssh.exe, I think this will even work on windows; it contains the
+code to run ssh-askpass.
+
+### securely handling the password
+
+* Maybe force upgrade webapp to https? Locally, the risk would be that
+  root could tcpdump and read password, so not large risk. If webapp
+  is used remotely, require https.
+* Use hs-securemem to store password.
+* Avoid storing password for long. Erase it after webapp setup of remote
+  is complete. Time out after 10 minutes and erase it.
+* Prompt using a field name that does not trigger web browser password
+  saving.
+
+### ssh-askpass shim, and password forwarding
+
+`SSH_ASKPASS` needs to be set to a program (probably git-annex)
+which gets the password from the webapp, and outputs it to stdout.
+
+Seems to call for the webapp and program to communicate over a local
+socket (locked down so only user can access) or environment.
+Environment is not as secure (easily snooped by root).
+Local socket probably won't work on Windows.
+
+Note that the webapp can probe to see if ssh needs a password, and can
+prompt the user for it before running ssh and the ssh-askpass shim.
+This avoids some complexity, and perhaps some attack vectors,
+if the shim cannot requst an arbitrary password prompt.