I was thinking about this, even though, I have never looked at the
code, it seems to me that the server is much easier to secure than the
individual clients, so if the symmetric key were kept on the server and
was requested before each command that accessed the server, it could be
used to decrypt the authentication cache before executing the command.
This would make the command line client pretty secure so long as it
never cached the symmetric key locally. The server could generate real
the key out of a config file when it launched. I am not sure how
feasible this is just wanted to suggest it.
On Aug 25, 2004, at 1:52 PM, <email@example.com> wrote:
> Travis P <firstname.lastname@example.org> writes:
> > It can lead to something entirely sensible like ssh-agent or AFS
> > The key is then cached in memory only (locked, non-pageable memory
> > the OS allows for that).
> Yes -- we've talked about doing that, it's just that it's a
> non-trivial project.
> You could conceivably implement it as a wrapper around the 'svn'
> client, one that communicates with its own agent and passes the
> --username and --password options to svn every time.
> > A system like this is more complicated, but would have significant
> > advantages over what is currently available.
> No one disagrees, it's just a question of priorities.
Received on Sat Aug 28 05:10:04 2004