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.
<rant>
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.
</rant>
-- 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