On Sat, Jul 31, 2010 at 9:12 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
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.
> Does anyone feel like hacking up support for a password store backed
> by GPGme? I'd love to review patches for that.
Not on my to-do list, although I'd love to see it as well.
>> 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.
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.
> 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? 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
>> 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?
No, that was a layer of complexity I didn't have an opportunity to
approach. Getting X servers deployed and configured is.... a separate
issue in many development environments.
>> 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.
>> 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.
It's a client change, not a sserver change. As such, I'd like to
suggest that it's completely reasonable as part of any significant
client release. But that's not my call.
> Please raise the issue again when Subversion 2.x comes around.
What is the timetable for that? I don't see a 2.x branch in the
primary repository, so I'd assume it's at least post 1.7.
> 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.
I'll be happy to toss in a vote. Note that it is *not* a change to the
protocol: it's a simple feature of the client.
>> 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".
This helps. It should be deactivated entirely in the default user
configuration files, and require manual intervention to enable.
>> 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 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.
>> 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?
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. 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.
>> 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.
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.
Received on 2010-08-01 04:23:17 CEST