Re: Encrypted connection

On Sat, 19 Oct 2013 09:48:12 -0700
Marc Abramowitz <[email protected]> wrote:

> >> Merge request to make an invalid encryption setting a fatal error:
> >> https://gitorious.org/freetds/freetds/merge_requests/10
> > 
> > Ouch indeed.  I think the next release of FreeTDS should probably
> > reject all incorrect configurations, both invalid keywords and
> > out-of-range values.  Diagnosing configuration errors is easier if
> > the error is obvious, and the remedy is simple.  
> 
> Freddy pointed out that my merge request wasn't acceptable because
> printing to stderr and exit aren't appropriate for a library. 
...
> Is there some middle ground - some way of indicating a config error
> (esp. a serious config error like an invalid encryption setting) that
> is very noticeable but doesn't overstep what a library should do?

The Right Way is to hook into the error handler.  Add something like
this to the table in sybdb.h:

#define SYBECONF	 2501	/* local configuration error */

and to the dblib.c::dblib_error_messages table

and invoke that error with tdserror or dbperror.  

It's not obvious to me that printing to standard error and exiting is
all that bad, though.  

In general, there are two kinds of errors:

1.  logic errors, caused by the programmer getting something wrong.
Examples include off-by-one errors and failure to check for a NULL
pointer.  These kinds of problems can and do cause the library to
exit via  e.g. assert(3).  There is no point in continuing, because the
program has reached an "impossible" state that the program did not
anticipate and thus cannot handle.  

2.  runtime errors, caused by invalid user input or dynamic failures
such as network disconnection or the server not responding.  These
should always return an error to the user, who is the only person in a
position to deal with it.  

Is an invalid configuration a logic or runtime error?  is the
administrator a programmer or a user?  

I would say the configuration file is more like program text.  It is
static data isolated from the program in such a way that it can be
modified without requiring recompilation.  The very first time it is
read -- compiled, if you will -- it will be validated.  If it is
invalid, the library exits.  Once the configuration is valid, no amount
of other invalid input will cause it to become invalid.  

Printing to stderr is unfortunately not robust, because some
applications will not have that descriptor open.  Invoking the error
handler is is more general, but will go unseen if the application
doesn't install and error handler. On the other hand, the problem can be
instantantly diagnosed by using any command-line tool such as tsql.  

So, IMO printing to stderr and exiting is fine, and invoking the error
handler is in some ways friendlier (perhaps in addition to writing to
stderr).  Exiting is OK, too, even if it does force the admin to clean
up errors that might otherwise be innocuous.  

HTH.  

--jkl