On Sat, Jul 31, 2010 at 10:22:42PM -0400, Nico Kadel-Garcia wrote:
> On Sat, Jul 31, 2010 at 9:12 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > Fortunately, today, we have support for KDE Wallet and Gnome Keyring.
> > So you can set up a secure password cache on *nix, if you have KDE
> > or Gnome, at least.
>
> Unfortunately, both are X session based, and don't work well with
> command line sessions. X.... is a useful technology, but a painful
> resource pig in many remote development environments. The "keychain"
> tool works reasonably well for keeping access to an encrypted SSH key
> for command line work.
AFAIK it's possible to run gnome-keyring without X.
This works similar to the ssh-agent, which prints a couple of
environment variables which help with contacting the running daemon.
eval `gnome-keyring-deamon --some-magic-option-maybe`
Never tried it myself though.
> Actually, while being somewhat rude, Linus made some good points about
> the flaws of centralized source control systems, and the inferior
> performance of Subversoin for merging.
But those problems were well known before his talk.
- It's always been clear that svn isn't the answer to the question "I am
Linus Torvalds and I get too much email with patches. How do I automate
this?" which is what git is all about. This was known even before git came
into existence: http://subversion.tigris.org/subversion-linus.html
- It's clear that you can merge faster if you only have local i/o
rather than http. And if you don't attempt to track merges
at the granularity Subversion does; git cannot track subtree merges
(merge from /trunk/dir to /branches/dir) nor cherry picking merges
(svn merge -c42 ^/trunk). I think that in practice svn could do with
less merge-tracking granularity for better performance, but meh.
Now we have the current merge-tracking implementation and we need to
support it for backwards compat.
His talk contained a lot of interesting polemics and making fun of
others in order to make himself look better, but that's all that I
found entertaining about it. Content-wise, the talk didn't provide
anything new, unless you didn't already know what git was.
> > If you use svn+ssh:// on unix, the password store in ~/.subversion/auth/
> > is not used. I've been under the impression that SSH does not store passwords
> > in plaintext. It can store passphrases for pubkeys in plaintext.
>
> Didn't it used to do this?
AFAIK it never did that.
> Testing with 1.4 and 1.6 just now doesn't
> show this behavior. *GOOD*. I'm glad it's turned off and consider it
> a significant
Great.
> Getting X servers deployed and configured is.... a separate
> issue in many development environments.
Yeah, but see above. It should be possible to run gnome-keyring without X.
> >> If Subversion is to lose its justified reputation as having
> >> unfortunate security,
> >
> > If you were to lose the fun in making completely over-the-top
> > statements like this...
>
> I've given a few specific examples. While it's gotten better and
> you've addressed some of my concerns, my overall concerns still stand.
> Cleartext password storage is a big problem, frequently ignored by
> deployers and developers who don't realize it's still there and who've
> never had to clean up the mess when someone leave passwords on a
> laptop or an NFS fileshare.
Yes. But I'm not convinced adding another config knob to enable it
will fix that. People who favour comfort over security will just
enable it.
> > Please raise the issue again when Subversion 2.x comes around.
>
> What is the timetable for that?
None so far :)
> LDAP is normally used in one of 2 modes:
>
> * Authentication only (which relies on the Kerberos backend normally
> asociated with a good LDAP environment and even with Windows Active
> Directory). This does not work for any OpenSSH clients before version
> 5.x due to its use of GSSAPI, and it's not in the standard release of
> Putty tools, and it's not in a bunch of current enterprise operatins
> systems such as RHEL 5.x.
>
> * Account management. This normally provides authentication and the
> typical "/etc/passwd" type of user information, including uid, gid,
> home directory, comments, and the login shell. While it's
> theoretically possible to publish LDAP data to force a dedicated login
> utility to then run a specified command set as a user configuration
> environment, that's precisely what a restricted shell is for.
Thanks for the insight.
> The difficulty lies in *preventing* people with such password based
> access from using the command line "svn" tool and storing the
> passwords behind your back, in the face of such education.
Well, that's a social problem to be solved, not a technical one.
No amount of technical lock-down will fix the social problem.
> It's
> feasible on an individual level, but unenforceable in most
> environments. As soon as you use passwords that are used for anything
> else, you face this risk of password storage.
One outstanding item on the svn roadmap is server-supplied client
configuration. With that feature, unless developers temper with their
svn client's code, the server will be able to tell the client not to
store the password in clear text (among other things, it's also useful
for configuring auto-props). This is a higly desirable feature, and will
improve deployment of Subversion in enterprise environments once available.
Current plan is adding this post-1.7. Maybe 1.8?
> > If you ported SSH to SunOS, you should be able to take the anoncvs.shar
> > I linked you to as an example, and hack it to do svnserve only.
>
> No. I know my limitations and engineering time available. Anoncvs is
> only acceptable for CVS because CVS essentially has no security,
> anyway. Replicating it and calling it a "restricted shell" would be an
> unfortunate misclaim.
If you're saying that a special restricted shell would be a useful
thing to be published in Subversion's standard distribution, that's
certainly something we could talk about. I"d be interested to work
on that if it really helps making svn+ssh:// deployments easier to secure.
Stefan
Received on 2010-08-01 11:24:12 CEST