apr_dbd_freetds

[Nick Kew <ni...@apache.org>]

PR 53666 tells us apr_dbd_freetds doesn't work with Sybase,
and very probably never did.  The reporter attaches a patch,
but it's one I'm not happy with, even if I had access to any
FreeTDS backend to test-drive (which I don't).  The basic
objection is that FreeTDS doesn't support prepared statements,
and the emulation in the driver opens big security issues.

We've had a bit of a thread on the subject on dev@httpd.

Is anyone in a position to take up the baton on FreeTDS?

If not, perhaps it's time we dropped that driver in favour
of the ODBC one.

-- 
Nick Kew

Re: apr_dbd_freetds

[Nick Kew <ni...@apache.org>]

On Thu, 7 Mar 2013 18:56:38 +0200
Graham Leggett <mi...@sharp.fm> wrote:


> There is a workable alternative driver for end users in the form of the ODBC driver (to my understanding), so removing it doesn't leave end users in the lurch.
> 
> Can we make sure the removal is documented, and people pointed at the alternative solution?

Yep, that's the general intention.

Thanks for mentioning the ODBC.  I meant to say that,
but forgot when I posted.


-- 
Nick Kew

Re: apr_dbd_freetds

[Graham Leggett <mi...@sharp.fm>]

On 07 Mar 2013, at 6:50 PM, Nick Kew <ni...@apache.org> wrote:

>> Is anyone in a position to take up the baton on FreeTDS?
>> 
>> If not, perhaps it's time we dropped that driver in favour
>> of the ODBC one.
> 
> In addition to this thread, I recently raised this on the PMC list.
> 
> I'm now proposing to turn talk into action.  That is to say, unless
> someone comes up with a reasoned argument to retain it,
> I'll delete it from SVN.  It'll still be in the archives for anyone
> who wants it, and it is of course open to anyone to step up
> as maintainer from your own site, or from a general-purpose
> developer site like sourceforge or github.
> 
> I'd expect an argument to retain it to address current bugs,
> future maintenance, and the problem of prepared statements.

There is a workable alternative driver for end users in the form of the ODBC driver (to my understanding), so removing it doesn't leave end users in the lurch.

Can we make sure the removal is documented, and people pointed at the alternative solution?

Regards,
Graham
--

Re: apr_dbd_freetds

[Nick Kew <ni...@apache.org>]

On 22 Aug 2012, at 18:18, Nick Kew wrote:

> Is anyone in a position to take up the baton on FreeTDS?
> 
> If not, perhaps it's time we dropped that driver in favour
> of the ODBC one.

In addition to this thread, I recently raised this on the PMC list.

I'm now proposing to turn talk into action.  That is to say, unless
someone comes up with a reasoned argument to retain it,
I'll delete it from SVN.  It'll still be in the archives for anyone
who wants it, and it is of course open to anyone to step up
as maintainer from your own site, or from a general-purpose
developer site like sourceforge or github.

I'd expect an argument to retain it to address current bugs,
future maintenance, and the problem of prepared statements.

-- 
Nick Kew

Re: apr_dbd_freetds

[Stefan Fritsch <sf...@sfritsch.de>]

On Wednesday 22 August 2012, Graham Leggett wrote:
> On 22 Aug 2012, at 7:18 PM, Nick Kew wrote:
> > PR 53666 tells us apr_dbd_freetds doesn't work with Sybase,
> > and very probably never did.  The reporter attaches a patch,
> > but it's one I'm not happy with, even if I had access to any
> > FreeTDS backend to test-drive (which I don't).  The basic
> > objection is that FreeTDS doesn't support prepared statements,
> > and the emulation in the driver opens big security issues.
> > 
> > We've had a bit of a thread on the subject on dev@httpd.
> > 
> > Is anyone in a position to take up the baton on FreeTDS?
> > 
> > If not, perhaps it's time we dropped that driver in favour
> > of the ODBC one.
> 
> Am I right in understanding that a user of the freetds driver could
> realistically use the ODBC driver instead? (I am assuming this is
> Windows).
> 
> If so, I would be in favour of deprecating the freetds driver and
> dropping the driver in v2.0, as a driver that doesn't support
> prepared statements suffers higher security risks.

I think the FreeTDS driver should either emulate prepared statements 
by using a known secure escaping function from FreeTDS. If that does 
not exist, it should be removed.

Also, apr_dbd_escape currently returns the unchanged string for 
FreeTDS. I would be more comfortable if it returned NULL (or if there 
was a way to return ENOTIMPL).

Re: apr_dbd_freetds

[Graham Leggett <mi...@sharp.fm>]

On 22 Aug 2012, at 7:18 PM, Nick Kew wrote:

> PR 53666 tells us apr_dbd_freetds doesn't work with Sybase,
> and very probably never did.  The reporter attaches a patch,
> but it's one I'm not happy with, even if I had access to any
> FreeTDS backend to test-drive (which I don't).  The basic
> objection is that FreeTDS doesn't support prepared statements,
> and the emulation in the driver opens big security issues.
> 
> We've had a bit of a thread on the subject on dev@httpd.
> 
> Is anyone in a position to take up the baton on FreeTDS?
> 
> If not, perhaps it's time we dropped that driver in favour
> of the ODBC one.

Am I right in understanding that a user of the freetds driver could realistically use the ODBC driver instead? (I am assuming this is Windows).

If so, I would be in favour of deprecating the freetds driver and dropping the driver in v2.0, as a driver that doesn't support prepared statements suffers higher security risks.

Regards,
Graham
--