[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] [gnome-keyring] Miscellaneous improvements

From: Branko ─îibej <brane_at_xbc.nu>
Date: Wed, 07 May 2008 01:44:02 +0200

Stefan Sperling wrote:
> Making it a compile option makes sense while developing the feature.
> It prevents others from having to install the corresponding
> libraries once the feature hits trunk, but allows people to test
> it easily.

Oh bosh. I bet 2 months from now someone's going to conveniently forget
this discussion and just leave the compile-time thing in. Then when
package maintainers start screaming, we'll do this all over again. Such
is the nature of open-source projects.

> Making the feature a module is a desirable goal, but should not
> be confused with getting the feature to work in the first place.
> Also, kwallet seems to hit more difficulties here than gnome-keyring
> because the C/C++ conundrum. Until we find a suitable solution
> to deal with that at runtime, making it a compile time option is
> better than not having the feature at all. Distro packagers are
> still entitled to simply not compile kwallet support in if it is
> too much of a burden for them. It's not that big of a deal.

Huh? So you want us to brag that "Subversion supports Gnome Keyring and
Kwallet" and then add small print about how most package maintainers
don't compile in either version because it's too much of a burden? Now
that is a truly brilliant security strategy.

Sorry if this is slightly sarcastic but what you propose is quite
contrary to the purpose of the whole exercise.

Of course the proper thing to do would be to get proper crypto support
in on the PAM or libc or some other GUI-agnostic level, so that Linux
would finally get this right -- like Windows does, dammit.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-07 01:44:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.