On 2008-04-19 10:35, Stefan Küng wrote:
> >
> > thank you for reaction at first. I have talked about the patch with
> >neon developer Joe and he said he dislike runtime linked gssapi in neon
> >becouse it adds more complexity for unix users without additional value.
> >He pointed me the way TSVN should use neon dll (instead staticaly linked).
> >Then the end users should choose between two neon.dll (one SSPI, another
> >GSSAPI enabled). Is it acceptable solution for TSVN?
I've been following this thread with great interest as I don't
particularly like that I need to build my own entire TortoiseSVN to
have interoperability with Subversion using Kerberos infrastructure
for authentication. In general, I think neon should always
runtime link kerberos libraries, on Windows or Unix. That way, you
can distribute neon binaries that support Kerberos without
requiring it. This doesn't affect source-based Linux/BSD
distributions, but for people who rely on pre-built packages,
adding Kerberos support (especially Heimdal rather than MIT) to
Subversion is a hassle right now as you have to require a Kerberos
implementation to include Kerberos support, which puts a lot of
strain on package-based systems.
As far as I can tell, the only two meaningfully secure, reasonably
scalable, and cross-platform security solutions (until SVN 1.5
with SASL is released) are mod_dav_svn with mod_auth_kerb or
mod_dav_svn or mod_dav_svn with PKI client authentication. PKI
has issues I'm sure I don't need to go into but for those of us
with existing Kerberos infrastructure, the mod_auth_kerb solution
is a great choice *except* for how difficult it is to support
TortoiseSVN.
> Sorry, no. I won't create separate dlls if I can link that stuff
> statically. Especially something that uses any kind of security
> (openssl, sspi authentication, ...). The risk of malware interferring
> with dlls is too high, and I also really hate the problems which arise
> from using dlls (ever heard of "dll hell"?).
I have mixed feeling about these observations. On one hand, DLL
hell is very real and I've found myself resorting to statically
linking lots of things I wouldn't otherwise like to (especially on
Linux) to deal with these sorts of problems. On the other hand,
TortoiseSVN is a bit unusual in the Windows world for being
statically linked, and it's not exactly ideal that TortoiseSVN is
always coupled to a specific build of Subversion. If it
dynamically linked Subversion, we wouldn't need a new build of
TortoiseSVN every time Subversion makes a security update, and
dynamically linking Subversion would make it easier to do things
like include your own authentication mechanisms in Tortoise.
But the issues Stefan mentioned are very real. And beggars can't
be choosers.
> I don't understand the problems Joe mentioned: it would be a compile
> time option. So why is he concerned about unix users? They simply won't
> compile that stuff in!
I guess I'm on board with Stefan here. I've toyed with supplying
patches to neon to runtime link Kerberos, but never got around to
writing them and when I saw someone else working on it, I was very
happy. Joe's probably watching, and if not, maybe we can convince
him, as I really think runtime linking Kerberos is the best
solution.
Right after that, maybe we can convince him about adding support
for cookies. :)
--
Alec.Kloss_at_oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
- application/pgp-signature attachment: stored
Received on 2008-04-19 14:16:08 CEST