RE: svn+ssh long-lived daemon

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;dev_at_subversion.apache.org
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 <bert_at_qqmail.nl> 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;dev_at_subversion.apache.org
Subject: Re: svn+ssh long-lived daemon
 
 
Ivan Zhakov <ivan_at_visualsvn.com> 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/