Re: sasl mechanisms order
On 2010-07-27 09:14, Victor Sudakov wrote: [chop] Thank you for having found this out. This is truly amazing. This means that if perchance I touch a file in /usr/local/lib/sasl2/, my Kerberos SSO can stop working? [chop] Well, that's pretty unlikely. It's moderately difficult to re-arrange the order of files in a directory. Assuming you're installing using a packaging system that removes old version prior to installing new ones and only does reasonable things with file creation order, your /usr/local/lib/sasl2 directory should start empty and then get the gssapi module installed after the digest-md5 module (probably because of the order they're declared in the Makefile for Cyrus sasl). Now if you were creating and deleting a bunch of other files in that directory and then installing sasl into that directory... bad things might happen to you. It's even possible if you have some perverse backup software. But anyway it's still definitely not a good thing. I'd dread the day someone changed the Cyrus SASL Makefile and got them installed in reverse order. -- alec.kl...@oracle.com The views expressed are my own and do not necessarily reflect the views of Oracle. PGP key at http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14 pgp2mKKCwCWXI.pgp Description: PGP signature
Re: sasl mechanisms order
On 2010-07-26 14:30, Victor Sudakov wrote:
Daniel Shahaf wrote:
I have the following line in /usr/local/lib/sasl2/svn.conf:
mech_list: gssapi digest-md5 anonymous
How can I guarantee that the subversion client/server will always use
GSSAPI before DIGEST-MD5? Or a more generic question, how can I change
the order of mechanisms if I have to?
Looking at subversion/libsvn_ra_svn/{client.c,cyrus_auth.c}, it seems
that the
following order is used:
* EXTERNAL (i.e., ssh tunnel)
* ANONYMOUS
* ${server-reported mechanisms, in the order suggested by the server}
* CRAM-MD5 (used via internal_auth.c even if SASL doesn't support it)
I don't see a knob that lets you manipulate the order.
Then how can I manipulate the order suggested by the server? The
server is svnserve.
Looking in subversion/svnserve/cyrus_auth.c, the list of mechansms is
obtained
directly from SASL:
[dd]
so you'd have to look up in the SASL docs how to configure the ordering of
mechanisms. (I don't know offhand how to configure that.)
I was unable to find this in the SASL docs. It only says that
mech_list is a Whitespace separated list of mechanisms to allow (e.g.
'plain otp'). Used to restrict the mechanisms to a subset of the
installed plugins.
While googling I found even such statements as
http://www.techienuggets.com/CommentDetail?tx=188636
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
As far as I can tell (and as amazing as this sounds), the order of the
offered mechanisms from Cyrus sasl is, by default, the reverse of the
order that the library finds them. This would be, in effect, the
reverse physical directory order of the modules in
/usr/[local]/lib/sasl2/ which you can find with ls -U. I've confirmed
this by making copies and deletes of the .so files in that directory to
rearrange the ordering. The list is reversed from the order they're
found in because mechanism list is a linked list and new entries are
prepened (around server.c:392).
As the link your provided mentions, Cyrus SASL believes it's the client
that should select the preferred mechanism from the list offered by the
server, not just the first one.
--
alec.kl...@oracle.com The views expressed are my own and
do not necessarily reflect the views of Oracle. PGP key at
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14
pgpza8fWuT7Mj.pgp
Description: PGP signature
Re: How to choose between svn http?
On 2010-07-08 17:04, David Brodbeck wrote: On Jul 8, 2010, at 4:49 PM, Nico Kadel-Garcia wrote: A local comparison is often best, especially when operating over HTTPS or svn+ssh for security reasons: Because of the continuing storage of HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux versions of Subversion, I don't trust anything but the svn+ssh public key based access for public use. Unfortunately, this does cause a noticeable performance hit. It's worth pointing out that the private key has to have a passphrase, for this to be a security improvement. Otherwise all you've accomplished is to leave the password-equivalent in ~/.ssh instead of in ~/.svn. ;) I mention this only because a lot of the applications for SSH public keys involve passwordless login. [chop] I feel a little like a broken record, but... using GSSAPI (or Negotiate for HTTPS) substantially reduces the security issues by integrating authentication into the rest of a managed single-sign-on system. GSSAPI/Negotiate also has the feature of working in all four remote access protocols for Subversion. The downside is difficulty in configuration and poor support in some (or many or perhaps all) binary distributions of Subversion. I have to admit, I don't think very highly of ssh public-key authentication; I have a hard time believing very many users or administrators carefully protect, rotate, and revoke RSA keys in a timely manner, which seems to me to substantially reduce the security of ssh public-key infrastructure. -- alec.kl...@oracle.com Oracle Middleware The views expressed are my own and do not necessarily reflect the views of Oracle PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14 pgpNbYROMon9k.pgp Description: PGP signature
Re: Subversion with LDAP - Display description
On 2010-07-02 08:13, Maxter wrote: Hi, We did all necessary for the deployment of LDAP with Apache/Subversion but I found a little thing that arrass me a little bit. When we do commit, the user displayed is the username in the AD. The problem is that the username is a sequetial number so not really userful for knowing fast who did the commit the last time. So my question is pretty simple... Is there a way to display the Description found in the AD other than the username for the UserID field in the commit information? If yes, how could we do that? I use a post-commit hook to save the authentication ID as another property and then reset the svn:author. -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14 pgpYnclc3P7tC.pgp Description: PGP signature
Re: svnserve and ldap status ?
On 2010-03-23 15:22, Stefan Sperling wrote: On Tue, Mar 23, 2010 at 02:44:55PM +0100, Remi wrote: I've also found a patch to use svnserve directly with ldap ( http://svn.haxx.se/dev/archive-2008-01/0719.shtml). Why this one as not been included in svnserve ? My guess is lack of developer competence regarding LDAP, which translates to lack of developer time (i.e. having enough time to learn enough about LDAP to understand the patch). Actually I think I've looked at that patch before but decided I wasn't competent enough to understand it and moved on. It's a bit unfortunate that most of our developers lack expertise in external authentication mechanisms Subversion is hooked up to. The reason is probably that our developers tend to focus on version control problems rather than system administration and security. There are so many problems to solve in version control already that patches like this get overlooked (or put aside for some time later) easily. It would help to have a developer focused on authorisation mechanisms, the ones inside of Subversion as well as integration with external ones. Right now we have no such developer. Stefan Stefan: I'm not trying to be snyde, but I've tried getting the SASL cross-realm support in svnserve fixed in the past and not had much success. It's a little demotivational. Remi: I got this working on a test instance this morning. Do heed warnings from others about how this is all clear-text (passwords easily sniffiable on the wire) authentication. 1. Configure svnserve.conf. I believe you have this correct: use-sasl = true 2. Configure svn's sasl configuration in $SASLCONFDIRDIR/svn.conf. I believe you said yours is in /usr/lib/sasl2 or someplace like that I should look like this: mech_list: PLAIN pwcheck_method: saslauthd I believe you had sasl_pwcheck_method, which is incorrect. 3. Configure saslauthd.conf. The location of this seems to be a little mystical (which I was stuck on for a while). I figured it out using strace but using strings `which saslauthd` is probably easier. Anyway, when you figure out where it is (mine's at /etc/saslauthd.conf) it should contain: ldap_servers: ldap://ldapserver/ ldap_search_base: dc=yourdomain,dc=com saslauthd.conf is pretty thoroughly documented in the cyrus sasl source tarball in the file salauthd/LDAP_SASLAUTHD. There are lots of options in here. 4. Start saslauthd: root# saslauthd -a ldap -d 5. Test with testsaslauthd: you% testsaslauthd -u someuser -p somepassword 6. Start svnserve: you% svnserve -X -r /your/svn/repository 7. Test svn: you% svn info svn://youhost/ Try someuser and somepassword from above. Hope that helps. Note also that saslauthd is a password-checking engine, so you should take steps to avoid malicious people from using it to try to brute-force passwords. The security of all of this is really weak if you're not using SSL or GSSAPI binds for LDAP and there's nothing you can do about the cleartext passwords for svnserve protocol. If you want something that keeps your passwords safe, you should really be using svn+ssh, svnserve with GSSAPI authentication (which is also very ldap-friendly if you have your kerberos database in your ldap directory), or anything you like over https. -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14 pgpLyF2AlzDc0.pgp Description: PGP signature
Re: svnserve and ldap status ?
On 2010-03-23 17:11, Stefan Sperling wrote: Hi Alec, I remember your patch. It looked pretty simple and OK to me, but I didn't feel confident enough about my own understanding of what the patch really does. I understand that not receiving much response to your patch won't exactly encourage you to contribute further, so I will try to take a look at it again. I'd like to be able to test it though. First I'll need to find time to read about SASL and realms (ie. figure out what we're really talking about). If you can speed this up by giving me a hint as to what to read, that would be great. If you can also help me with setting up a proper test environment that would be even nicer! I will try to get something set up with the instructions you gave Remi. If I run into problems I'll get back to you. Oh, and if one of you feels like doing a proper write up, a patch to the svnbook which documents how to set this up would be most lovely. If your patch gets lost again please feel free to keep pinging me about it. I will eventually get to it. If the patch is not already in the issue tracker please feel free to add it there, to an issue with milestone 1.7.0. Sure thing. I'll try to write up a giant setup script for the whole deal. Note that my patch is mostly important in cross-realm cases which are more likely to occur in GSSAPI authentication cases rather than the ldap cases, so it'll be a big setup script (build two test Kerberos realms, configure cross-realm principals, configure svnserve, etc.). It'll be my shell scripting exercise for the week and it'll stand as permanent documentation for how to get GSSAPI+svnserve working. :) -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEBD1FF14 pgpLGyhVLskOy.pgp Description: PGP signature
Re: How to make an encrypted svnsynced repository
On 2010-01-16 08:06, Ton Boelens wrote: [chop] I don't think this is built into subversion. I've asked about a similar feature in the past and not gotten anywhere. It would be pretty slick to have a repository session key that is pgp-encrypted for the committers/reviewers of the repository that all files (and network traffic) is encrypted with. If the svn clients managed it all well, it could be pretty seamless. A new committer would be added to the repository session key, and revoking a committer would require generating a new key and encrypting new revisions with it. It would be a great feature because you could distribute a secure repository onto a public subversion server and only send private data to and from it. I agree, that would be great functionality. However, I would like to have the encrypted remote copy this winter :-) What about using exposing a device on the server with iscsi and then running OS encryption on the clients on top of that device? The remote repository would be live for use but only for clients that have the encryption key for the filesystem. -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x432B9956
Re: How to make an encrypted svnsynced repository
On 2010-01-15 22:23, Ton Boelens wrote: Hi, At the moment, my SVN repository is snvsynced to a server in another location. I would like to make this remote repository encrypted on the file level, so that even somebody who has physically access to this server, cannot read the contents of the files. I have searched in the svn manual, with Google and in the past couple of months posts I have of this mailing list, but I could find no reference. Does that mean that there is no way to design a solution to this requirement? I don't think this is built into subversion. I've asked about a similar feature in the past and not gotten anywhere. It would be pretty slick to have a repository session key that is pgp-encrypted for the committers/reviewers of the repository that all files (and network traffic) is encrypted with. If the svn clients managed it all well, it could be pretty seamless. A new committer would be added to the repository session key, and revoking a committer would require generating a new key and encrypting new revisions with it. It would be a great feature because you could distribute a secure repository onto a public subversion server and only send private data to and from it. -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x432B9956 pgpwtHRj5tcGa.pgp Description: PGP signature
Re: Subversion 1.6.6 doesn't appear to allow adding files with @ in the name
On 2009-12-18 15:01, John Beranek wrote: 2009/12/18 Alec Kloss alec.kl...@oracle.com: Subject pretty much says it all. My 1.6.4 client does allow adding files with an @ in their name. $ svn add a...@a@ A a...@a ;) John. Thanks everyone, I should have thought of that. -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x432B9956 pgpgB0m70LVTx.pgp Description: PGP signature
