Skip to Content.
Sympa Menu

freetds - Re: [freetds] Encrypted connection

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Marc Abramowitz <msabramo AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Encrypted connection
  • Date: Mon, 21 Oct 2013 13:48:47 -0700

That makes sense.

OK, I took another stab at creating a louder notification when the
encryption setting is incorrect:

*https://gitorious.org/freetds/freetds/merge_requests/16* ("Improve
handling of invalid encryption setting")

The goal here is to make it much more noticeable when there is an invalid
encryption setting. I do this by:

- calling tdserror with a new error code (TDSECONF = 20214 = "Local
configuration error")
- print a message to stderr in case in case someone is looking there
- exiting the process if the ENABLE_EXIT_ON_INVALID_CONFIG is defined
(defined by passing --enable-exit-on-invalid-config to./configure).



On Sat, Oct 19, 2013 at 11:49 AM, James K. Lowden <jklowden AT freetds.org>wrote:

> On Sat, 19 Oct 2013 09:48:12 -0700
> Marc Abramowitz <msabramo AT gmail.com> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>




Archive powered by MHonArc 2.6.24.

Top of Page