But in case of git you have git-ssh like servers implemented as a combination of two tools which avoid these problems. (Sometimes in java though). Perhaps we could also look in that direction instead of looking at a new protocol between svnserve and ssh.
Or checking if ssh style public key authentication could be introduced directly in the svnserve protocol. Both these options would also fix the problems raised. Bert Sent from Outlook Mail for Windows 10 phone From: Mark Phippard Sent: vrijdag 20 november 2015 15:20 To: Bert Huijben Cc: Philip Martin;Ivan Zhakov;Daniel Shahaf;[email protected] Subject: Re: svn+ssh long-lived daemon I've always felt the same, but now that I've used SSH more (with Git) I kind of question it. Are HTTP client certs much better than passwords? The cert itself still has to be physically secured and if you protect the cert with a passphrase then you have all of the same cache problems that passwords do. With SSH there is infrastructure like ssh-agent that just does not exist for HTTP. Mark On Fri, Nov 20, 2015 at 9:16 AM, Bert Huijben <[email protected]> wrote: With the right tooling both operations should be equivalent. Perhaps it is easier to spend time on that. Bert Sent from Outlook Mail for Windows 10 phone From: Philip Martin Sent: vrijdag 20 november 2015 12:21 To: Ivan Zhakov Cc: Daniel Shahaf;[email protected] Subject: Re: svn+ssh long-lived daemon Ivan Zhakov <[email protected]> writes: > 5. HTTPS authentication using client certificates Client certificates are a possibility. There are some drawbacks: the signing authority has to be maintained, revoking a certificate is more complicated than removing a key from the authorized_keys file. -- Philip Martin WANdisco -- Thanks Mark Phippard http://markphip.blogspot.com/
