FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Wed, 14 Sep 2011 12:49:31 -0400
Mike Slifcak <slif AT bellsouth.net> wrote:

>    Would you consider the auto login feature not be compiled in
> unless the package builder specifies a configure option to use it?

Consider, sure.  But to do it, I need to be convinced.  What I've heard
so far isn't compelling.   

I think there may be some misunderstanding of what I'm proposing.
Doubtless that's my fault; let me try to remedy.  

As of today, if you run ./configure with no options and run tsql with
no freetds.conf and no environment variables, you'll connect if the
name you provide resolves to an IP address and uses TDS 5.0.  Those are
what I call the "default defaults".  

If you configure --with-tdsver that becomes the built-in default.  I
know that's used in some homogeneous environments.  It's very nice not
to have to maintain a freetds.conf on every machine.  

If you have build scripts that apply configure options -- I keep mine
in .build_options -- then you'll continue to be able to use them, and
they'll keep doing just what they did.  

What I'm proposing is to change the "5.0" default, above, because the
external reality has changed.  From what I read about market share and
see on this mailing list, Sybase is a minor player.  No offense
intended to Sybase fans, just to say they're outnumbered.  

In its place I propose "auto", which would seek down from 7.3 or
whatever is the highest implemented version.  I think that would work
very well and confine --with-tdsver to the dustbin for most
installations.  

Automatic version selection will work for a large fraction of
installations.  freetds.conf etc. will continue to be available, not
least because there's a clear use-case: for some applications, login
time dominates, and failed login packet exchanges would hamper
throughput.  

A theoretical objection was raised that some sites might
interpret that "seeking" behavior as an attack.  For me to believe
that, I need more than hypothesizing.  If you're running a 7.0 server,
it will see 7.3, 7.2, 7.1, 7.0.  Three attempts is an attack?  I don't
believe it.  

Remember, there's no user validation being attempted.  The server sees
and immediately rejects invalid login packets.  The firewall doesn't
know a TDS login packet from a potato.  I highly doubt a Windows server
will be configured to trigger an alarm just because a broken login
packet shows up at its door.  

But even if I'm wrong I'm right.  (I try to make sure things end up
that way.)   Someone running a super-controlled setup, if such
exists, is perfectly safe.  He's already using --with-tdsver or
freetds.conf, which continue to work as before.  The rest of us get to
ignore the problem and go home early.  

If someone reading this list *knows* of an environment where this would
cause a problem, please raise your hand so we can discuss it.  If
you're speculating, we can still discuss it, but you need more
than hand-waving to affect the outcome.  

I hope that puts any concerns to rest.  If I've overlooked something,
I'm happy to be educated.  But as of now, I'm convinced "auto" is the
right default default, and it's likely I've given this miniscule
question more thought than any living soul on the planet.  Involving
packagers and admins in more configure knobs is fobbing off the
decision on someone who (if I may be so bold) knows less and cares less
about the issue. Making the right default-default choice for him is a
service and makes FreeTDS a better library.  

Oh, one more thing:  The bikeshed must be destroyed!  

--jkl