On Fri, Jul 30, 2010 at 11:55:20PM -0400, Nico Kadel-Garcia wrote:
> No, it's harsh experience since version 1.2 (when I started helping
> rebuild it and rebundle it for Dag's RPM repository, now RPMfoge). The
> UNIX/Linux clients should *never* have been permitted to store
> passwords.
You forgot "in cleartext'. I agree. I wasn't around at the time when that
decision was made, and adding a prompt was the only way to fix this
without breaking existing setups. Not everyone has a huge problem
with Subversion passwords on disk, really. I do, you do, but others don't.
That's just the way it is.
> That's a genuinely unfortunate legacy from its heritage as
> the logical upgrade path from CVS, and that was CVS behavior that
> should have been jettisoned at the design stage.
Well, CVS had poor password encryption due to funky US law regulations
at the time, and Karl Fogel later admitted that the entire pserver stuff
was a design fault. See here for the full story:
http://producingoss.com/en/contracting.html#cvs-pserver
That's why it was decided later that Subversion had to store passwords
in cleartext on Unix, rather than pretend to be storing them securely.
On Win and Mac, Subversion has always been encrypting passwords when
storing them to disk, because there are standard APIs for that on
those platforms. So it's not like Subversion's developer's didn't care.
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.
Does anyone feel like hacking up support for a password store backed
by GPGme? I'd love to review patches for that.
> It's that sort of
> misfeature that led to Linus Torvald's infamous presentation comparing
> Subversion and git at Google. I wish he'd had enough time to examine
> the security ramifications.
Blah, Linus, blah.... yawn... I already know that according to Linus, I'm
both "ugly and stupid" (Subversion developer) and a "masturbating monkey"
(OpenBSD developer). Your comment above doesn't add any value to
this discussion, much like a lot of what Linus says doesn't.
> I continue, even now, to have to display to people that just because
> it's using HTTPS doesn't mean it hasn't stored their passwords in
> cleartext, or just because they've switched to ssh+svn it doesn't do
> so.
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.
> This last educational demonstration was one week ago, and I've had
> to demonstrate the issue 3 times in the past year. The programmers in
> question believed that becuase it used an encrypted protocol, it must
> be handling passwords safely. I had to show them where it was storing
> their own passwwords in clear text, including one programmer I had to
> email his password and email it to his supervisor along with the
> company security policy to get him to stop doing it. (He didn't
> believe it was *possible* that Subversion sould have been written to
> do this.)
Well, it's possible to set Subversion up in a way that makes it store
passwords in KDE Wallet or Gnome Keyring. Did you show your client
how to do that?
> 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...
> password storage should be permanently deleted
> from the code base, not merly papered over with a warning before doing
> so.
We can't just delete it.
We will remain backwards compatible during the 1.x line of releases.
Please raise the issue again when Subversion 2.x comes around.
We can lobby for getting the plaintext password storage feature
removed then. But it will depend on how many people would rather like
to keep it.
> At a minimum, the system and personal configuration defaults
> should disable password storage by default, not enable it at all.
Well, that's kind of what we did by making the default a prompt.
We gave people a choice. You can choose "no", others can choose "yes".
> OpenSSH does support public key credentials, quite effectively. It's
> the difficulty of using LDAP credentials to allow login as the a
> designated subversion repository owner, with restricted access to
> svnserver or a similarly restricted access, and not as a shell capable
> user with file system acces.
Why is this difficult? Is it just a matter of "not supported", or
is there a technical reason restricting commands run within an SSH
session authenticated via LDAP will never work? Honest question.
> LDAP is normally activated for SSH or HTTPS access to ease management,
> not to support a service specific set of add-on configurations.
What about combining https with KDE Wallet / Gnome Keyring when
you really need LDAP auth, use UNIX clients, and don't want passwords
in plaintext on disk?
> Unfortunately, there is not a restricted shell for Subverson or
> svnserve access that I've been able to find. It's certainly not in the
> publicly available source code. Do you have one?
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.
Stefan
Received on 2010-07-31 15:13:46 CEST