jra at samba.org
Sat Nov 10 18:22:02 GMT 2001
On Sat, Nov 10, 2001 at 04:34:10PM -0800, Andrew Tridgell wrote:
> yes, I disagree. There are some parameters that are just too evil to
> live. A good example is the old krb4 and krb5 configure
> parameters. They should be removed because:
> 1) they required compile time changes, which very few people do
> 2) they only work with plaintext passwords on the wire, which means
> they need client hacks
> 3) they are completely superceded by our new kerberos code
I would agree with these, but these are *configure* parameters,
not runtime parameters.
> Same goes for the SSL support code. It is a nasty, gross hack that
> makes our code harder to maintain.
Again, mainly configure params.
> What you forget about in your view on keeping parameters is that there
> is a tradeoff between keeping old parameters and keeping the code
> maintained. Leaving in code that nobody actively maintains and that
> makes the code less maintainable increases the number of bugs for
> *everyone*, whereas keeping the parameter helps maybe one person who
> happens to use that parameter. We do not have the resources to
> maintain such patches when so few people use them. If someone pops up
> and (credibly) says that they will maintain and *test* the patch then
> fine, we can keep it, but if there is nobody who will do that then we
> must drop it.
> Having a badly maintained security option is *much worse* than not
> having it at all.
> Andrew and I will be removing some of these unmaintained options from
> the head branch. If you want to put them back in, then fine, but
> please don't do so unless you can guarantee they will be maintained. I
> know you don't have the time to do it yourself, so you'll have to find
> someone willing to do it. If you can't then don't add it back in.
And you're confusing the term "parameters" to try and win
the argument :-) :-) :-).
I don't care at all about configure params. Anyone who compiles
from source can cope with any change we make in loadparm.
I care about the runtime smb.conf parameters. What prompted this
discussion was the suggestion that we completely remove the
"security=" parameter for 3.0. I hope you would agree that would
be a rather too radical change :-) :-).
argument of course was the idea that we remove the "security="
More information about the samba-technical