Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Nico Williams]

On Fri, Aug 04, 2017 at 10:55:57AM -0500, Bob Friesenhahn wrote:
> Sqlite does not really have a way to know if a module in the current
> directory (the directory which just happened to be current when the request
> was made) should be trusted.  To be secure, sqlite should insist that the
> load request be something other than a bare module name because then the
> responsibility is put on the user of sqlite.

You can always load an absolute path.  That said, using relative paths
and depending on the caller's run-path is not bad per-se -- just
something to be aware of.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Nico Williams]

On Fri, Aug 04, 2017 at 08:20:10AM -0700, J Decker wrote:
> On Fri, Aug 4, 2017 at 8:11 AM, Nico Williams  wrote:
> > No, see, the ".so"/".dll" suffix is used in all cases, and it varies by
> > platform, so it's best if SQLite3 adds it so you can keep your code more
> > portable.  While the "lib" prefix is only ever needed if you want a
> > link-edit to find the thing as -l -- which you almost never ever
> > want when  is a loadable module.
> 
> so does the lib prefix.  You cannot package a .so in an android .apk.
>  but you can include lib.so.

Really?!  Oy.  But still, that would just mean that when building for an
Android platform SQLite3 *must* add the "lib" prefix, not that it should
try it on every Unix-like platform.

> At which point, because I apparently missed that too.  if one is using
> CMake, you get a lib.so without setting additional options.

So?

Nico
-- 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Bob Friesenhahn]

On Fri, 4 Aug 2017, Peter Da Silva wrote:


On 8/4/17, 8:29 AM, "sqlite-users on behalf of Bob Friesenhahn" 
 
wrote:

Lazy programmers who request such things are of the same ilk which use 
programming practices resulting in SQL injection attacks.  Sqlite should not 
promote such practices.


Then require a fully qualified path and extension, and don’t have a search path 
for DLLs at all.

Otherwise you’re just haggling over where to draw the line.


The operating system (insert operating system used here) has an 
operating-system specific algorithm it uses when it searches for 
shared libraries which were specified using only the file name. 
Whether 'lib' at the front of the file name is significant to its 
searching behavior depends on the operating system used.


I have not checked what sqlite actualy does, but for security, it 
should be doing its own 'stat' to find the existing module, and then 
open it via an explicit path in order to defeat any operating-system 
specific behavior.


If sqlite were to simply issue load requests via dlopen() (or 
equivalent) with various permutations, then it would become subject to 
the varying behavior of different systems.  For example, a program 
which uses sqlite as part of a directory indexer which is indexing a 
directory which contains uploads from untrusted users could be 
compromised.


Sqlite does not really have a way to know if a module in the current 
directory (the directory which just happened to be current when the 
request was made) should be trusted.  To be secure, sqlite should 
insist that the load request be something other than a bare module 
name because then the responsibility is put on the user of sqlite.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[J Decker]

On Fri, Aug 4, 2017 at 8:11 AM, Nico Williams  wrote:

> On Fri, Aug 04, 2017 at 10:17:33AM +0200, Dominique Devienne wrote:
> > On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams 
> wrote:
> > > You're mistaken.
> > >
> > > lib.so is NOT "the default naming scheme on many *nix platforms".
> > >
> > > lib.so is the naming scheme when you want the link-editor (e.g.,
> > > ld(1)) to find a library using -l.
> > >
> > > But loadable modules are almost never meant to be used that way.
> > > They're usually meant to be used only through dlopen() and friends.
> >
> > While you're technically correct, Matt's request seems completely
> > reasonable to me.
>
> Not if it's a result of being mistaken.  Now that OP knows about object
> naming, he can reconsider and restate his request.
>
> > If SQLite wasn't doing *any* changes to the filename, not adding the
> > extension for example, you may have had a point, but since it does,
> > trying with the lib prefix on Linux, which is undeniably a common
>
> No, see, the ".so"/".dll" suffix is used in all cases, and it varies by
> platform, so it's best if SQLite3 adds it so you can keep your code more
> portable.  While the "lib" prefix is only ever needed if you want a
> link-edit to find the thing as -l -- which you almost never ever
> want when  is a loadable module.
>

so does the lib prefix.  You cannot package a .so in an android .apk.
 but you can include lib.so.



>
> > naming convention on Linux, seems like a worthwhile addition. [...]
>
> You didn't understand.
>
At which point, because I apparently missed that too.  if one is using
CMake, you get a lib.so without setting additional options.


>
> > I really don't see what's controversial with Matt's request :)
>
> a) it's borne of a mistake
> b) it's not necessary
> c) it's more code and more docs
> d) it's more likely to lead to accidents
>
>
a) It's born of 'I want to load 'myExtension'" and sqlite already does
substitutions.
b) maybe.
c) so?  it's not like a whole path is specified that you'd get
/usr/lib/myextension  and then try lib/usr/lib/myextension.so
d) and more likely to cause scripting configuration issues;   There's no
.if or .goto commands to be able to handle error conditions.  So you have
to maintain at least 2 scripts instead of just 1.  Leading to more
accidents in updating one and not the other.


> > It's not like load-extension is a performance-critical operation, that
> > trying an extra load is that expensive.
>
> This is true, but also irrelevant :)
>
> > And the security consideration that an "attacker" could make it load
> > his own library instead, but using a different name tried before the
> > actual one is moot IMHO, since extension loading is by nature unsafe.
> >
> > In short, I support Matt's request and I hope DRH considers it seriously.
> > FWIW :). --DD
>
> What problems does this solve?  None.
>
> Wrong, it adds the ability to code a single script to execute.


> Nico
> --
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[J Decker]

On Fri, Aug 4, 2017 at 6:29 AM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Fri, 4 Aug 2017, Dominique Devienne wrote:
>
>>
>> I really don't see what's controversial with Matt's request :)
>>
>> It's not like load-extension is a performance-critical operation, that
>> trying an extra load is that expensive.
>> And the security consideration that an "attacker" could make it load his
>> own library instead, but using a
>> different name tried before the actual one is moot IMHO, since extension
>> loading is by nature unsafe.
>>
>> In short, I support Matt's request and I hope DRH considers it seriously.
>> FWIW :). --DD
>>
>
> It is true that sqlite normally only needs to load an extension once per
> invocation.  However, loading an extension incurs a cost in that
> several/many 'stat' operations on the filesystem are necessary in order to
> find the module unless the full path to it was given (use 'strace',
> 'truss', or 'dtruss' to see this in action).  The security implications can
> be severe on some popular operating systems.
>
> As I mentioned before, two very popular desktop OSs (Microsoft Windows and
> Apple's OS X) have a defined pattern in that they will search the current
> directory for a module by default.


And then search the whole path.  certainly not a cost savings, don't see
the point.


> Hopefully it should sink in that if one requests loading the extension
> while the process current directory is currently in a potentially 'hostile'
> directory that this may lead to the compromise of the account of the user
> ID executing sqlite because arbitrary binary code can be injected.
>

And how does this help avoid that?  export LD_LIBRARY_PATH=. and it is the
same behavior as windows...


>
> Lazy programmers who request such things are of the same ilk which use
> programming practices resulting in SQL injection attacks.  Sqlite should
> not promote such practices.
>
> Probably the extension is not in a well known place, so a path of possible
places is still going to be checked.


> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Nico Williams]

On Fri, Aug 04, 2017 at 10:17:33AM +0200, Dominique Devienne wrote:
> On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams  wrote:
> > You're mistaken.
> >
> > lib.so is NOT "the default naming scheme on many *nix platforms".
> >
> > lib.so is the naming scheme when you want the link-editor (e.g.,
> > ld(1)) to find a library using -l.
> >
> > But loadable modules are almost never meant to be used that way.
> > They're usually meant to be used only through dlopen() and friends.
> 
> While you're technically correct, Matt's request seems completely
> reasonable to me.

Not if it's a result of being mistaken.  Now that OP knows about object
naming, he can reconsider and restate his request.

> If SQLite wasn't doing *any* changes to the filename, not adding the
> extension for example, you may have had a point, but since it does,
> trying with the lib prefix on Linux, which is undeniably a common

No, see, the ".so"/".dll" suffix is used in all cases, and it varies by
platform, so it's best if SQLite3 adds it so you can keep your code more
portable.  While the "lib" prefix is only ever needed if you want a
link-edit to find the thing as -l -- which you almost never ever
want when  is a loadable module.

> naming convention on Linux, seems like a worthwhile addition. [...]

You didn't understand.

> I really don't see what's controversial with Matt's request :)

a) it's borne of a mistake
b) it's not necessary
c) it's more code and more docs
d) it's more likely to lead to accidents

> It's not like load-extension is a performance-critical operation, that
> trying an extra load is that expensive.

This is true, but also irrelevant :)

> And the security consideration that an "attacker" could make it load
> his own library instead, but using a different name tried before the
> actual one is moot IMHO, since extension loading is by nature unsafe.
> 
> In short, I support Matt's request and I hope DRH considers it seriously.
> FWIW :). --DD

What problems does this solve?  None.

Nico
-- 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Nico Williams]

On Fri, Aug 04, 2017 at 06:05:53AM +, Hick Gunter wrote:
> >Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
> >Auftrag von Nico Williams
> >But loadable modules are almost never meant to be used that way.
> >They're usually meant to be used only through dlopen() and friends.
> 
> Which other method apart from dlopen() would you recommend for
> dynamically loaded extensions?

There's only two methods for loading an object dynamically: because you
demanded it at link-edit-time, or because you used dlopen() or similar.

There are no others, full stop.

(You could write your own run-time loader, but you'd still be
implementing a dlopen().)

> We are using virtual tables to interface with diverse data stores and
> make them queryable with SQL. The general interactive shell needs
> access to a certain subset of functions, and some speciality tools
> have dedicated loadable extensions that should not be accessible
> outside of that scope.

So?

Nico
-- 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Peter Da Silva]

On 8/4/17, 8:29 AM, "sqlite-users on behalf of Bob Friesenhahn" 
 wrote:
> Lazy programmers who request such things are of the same ilk which use 
> programming practices resulting in SQL injection attacks.  Sqlite should not 
> promote such practices.

Then require a fully qualified path and extension, and don’t have a search path 
for DLLs at all.
 
Otherwise you’re just haggling over where to draw the line.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Bob Friesenhahn]

On Fri, 4 Aug 2017, Dominique Devienne wrote:


I really don't see what's controversial with Matt's request :)

It's not like load-extension is a performance-critical operation, that
trying an extra load is that expensive.
And the security consideration that an "attacker" could make it load his
own library instead, but using a
different name tried before the actual one is moot IMHO, since extension
loading is by nature unsafe.

In short, I support Matt's request and I hope DRH considers it seriously.
FWIW :). --DD


It is true that sqlite normally only needs to load an extension once 
per invocation.  However, loading an extension incurs a cost in that 
several/many 'stat' operations on the filesystem are necessary in 
order to find the module unless the full path to it was given (use 
'strace', 'truss', or 'dtruss' to see this in action).  The security 
implications can be severe on some popular operating systems.


As I mentioned before, two very popular desktop OSs (Microsoft Windows 
and Apple's OS X) have a defined pattern in that they will search the 
current directory for a module by default.  Hopefully it should sink 
in that if one requests loading the extension while the process 
current directory is currently in a potentially 'hostile' directory 
that this may lead to the compromise of the account of the user ID 
executing sqlite because arbitrary binary code can be injected.


Lazy programmers who request such things are of the same ilk which use 
programming practices resulting in SQL injection attacks.  Sqlite 
should not promote such practices.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Dominique Devienne]

On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams  wrote:

> On Tue, Aug 01, 2017 at 10:56:47AM -0700, Matt Chambers wrote:
> > load_extension() has the very sensible behavior of:
> > > So for example, if "samplelib" cannot be loaded, then names like
> > > "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried
> > > also.
> >
> > I would like to see that extended to include "libsamplelib.so" since
> that is
> > the default naming scheme on many *nix platforms. This simple change
> would
> > allow me to use the same base library name for my extension on both
> Windows
> > and Linux. Otherwise I have to modify my build system to override its
> > default behavior of adding the lib prefix on Linux.
>
> You're mistaken.
>
> lib.so is NOT "the default naming scheme on many *nix platforms".
>
> lib.so is the naming scheme when you want the link-editor (e.g.,
> ld(1)) to find a library using -l.
>
> But loadable modules are almost never meant to be used that way.
> They're usually meant to be used only through dlopen() and friends.


While you're technically correct, Matt's request seems completely
reasonable to me.
If SQLite wasn't doing *any* changes to the filename, not adding the
extension for example,
you may have had a point, but since it does, trying with the lib prefix on
Linux, which is
undeniably a common naming convention on Linux, seems like a worthwhile
addition. It is
true after all most build system will be default use that "ld-based" naming
convention, and
that there's no distinction for a shared lib meant to be loaded explicitly
via dlopen/LoadLibrary
or one that's implicitly linked with an executable. If fact, you can have
the same shared lib
SQLite "extension" used both ways, explicit-loading by sqlite3.exe, and
implicit-loading by
custom-app.exe.

I really don't see what's controversial with Matt's request :)

It's not like load-extension is a performance-critical operation, that
trying an extra load is that expensive.
And the security consideration that an "attacker" could make it load his
own library instead, but using a
different name tried before the actual one is moot IMHO, since extension
loading is by nature unsafe.

In short, I support Matt's request and I hope DRH considers it seriously.
FWIW :). --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Hick Gunter]

>Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
>Auftrag von Nico Williams
>
>On Tue, Aug 01, 2017 at 10:56:47AM -0700, Matt Chambers wrote:
>> load_extension() has the very sensible behavior of:
>> > So for example, if "samplelib" cannot be loaded, then names like
>> > "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be
>> > tried also.
>>
>> I would like to see that extended to include "libsamplelib.so" since
>> that is the default naming scheme on many *nix platforms. This simple
>> change would allow me to use the same base library name for my
>> extension on both Windows and Linux. Otherwise I have to modify my
>> build system to override its default behavior of adding the lib prefix on 
>> Linux.
>
>You're mistaken.
>
>lib.so is NOT "the default naming scheme on many *nix platforms".
>
>lib.so is the naming scheme when you want the link-editor (e.g.,
>ld(1)) to find a library using -l.
>
>But loadable modules are almost never meant to be used that way.
>They're usually meant to be used only through dlopen() and friends.
>

Which other method apart from dlopen() would you recommend for dynamically 
loaded extensions?

We are using virtual tables to interface with diverse data stores and make them 
queryable with SQL. The general interactive shell needs access to a certain 
subset of functions, and some speciality tools have dedicated loadable 
extensions that should not be accessible outside of that scope.


___
 Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: h...@scigames.at

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Nico Williams]

On Tue, Aug 01, 2017 at 10:56:47AM -0700, Matt Chambers wrote:
> load_extension() has the very sensible behavior of:
> > So for example, if "samplelib" cannot be loaded, then names like
> > "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried
> > also.
> 
> I would like to see that extended to include "libsamplelib.so" since that is
> the default naming scheme on many *nix platforms. This simple change would
> allow me to use the same base library name for my extension on both Windows
> and Linux. Otherwise I have to modify my build system to override its
> default behavior of adding the lib prefix on Linux.

You're mistaken.

lib.so is NOT "the default naming scheme on many *nix platforms".

lib.so is the naming scheme when you want the link-editor (e.g.,
ld(1)) to find a library using -l.

But loadable modules are almost never meant to be used that way.
They're usually meant to be used only through dlopen() and friends.

Nico
-- 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[J Decker]

On Thu, Aug 3, 2017 at 10:42 AM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Tue, 1 Aug 2017, Matt Chambers wrote:
>
> load_extension() has the very sensible behavior of:
>>
>>> So for example, if "samplelib" cannot be loaded, then names like
>>> "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried
>>> also.
>>>
>>
>> I would like to see that extended to include "libsamplelib.so" since that
>> is
>> the default naming scheme on many *nix platforms. This simple change would
>> allow me to use the same base library name for my extension on both
>> Windows
>> and Linux. Otherwise I have to modify my build system to override its
>> default behavior of adding the lib prefix on Linux.
>>
>
> These conveniences tend to lessen the security of sqlite since this is
> arbitrary executable code capable of doing anything the user is able to do
> (e.g. delete all files or add a virus).  If the user is willing to be
> precise, then there is less risk of a compromised module/library from being
> introduced.
>
>
then it shouldn't try any alternatives.  OR it should always be
'lib.so' which would also be acceptable.



> It should be obvious that calling sqlite3_load_extension() without an
> absolute path, or other safeguards, exposes the program to accidentally
> loading a file from whatever happens to be the current directory (perhaps a
> writeable directory that an attacker was able to write into).
>
> Apple's OS X and Microsoft Windows always try to load from the current
> directory.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature request: check for 'lib' prefix for load_extension()

[Bob Friesenhahn]

On Tue, 1 Aug 2017, Matt Chambers wrote:


load_extension() has the very sensible behavior of:

So for example, if "samplelib" cannot be loaded, then names like
"samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried
also.


I would like to see that extended to include "libsamplelib.so" since that is
the default naming scheme on many *nix platforms. This simple change would
allow me to use the same base library name for my extension on both Windows
and Linux. Otherwise I have to modify my build system to override its
default behavior of adding the lib prefix on Linux.


These conveniences tend to lessen the security of sqlite since this is 
arbitrary executable code capable of doing anything the user is able 
to do (e.g. delete all files or add a virus).  If the user is willing 
to be precise, then there is less risk of a compromised module/library 
from being introduced.


It should be obvious that calling sqlite3_load_extension() without an 
absolute path, or other safeguards, exposes the program to 
accidentally loading a file from whatever happens to be the current 
directory (perhaps a writeable directory that an attacker was able to 
write into).


Apple's OS X and Microsoft Windows always try to load from the current 
directory.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Feature request: check for 'lib' prefix for load_extension()

[Matt Chambers]

load_extension() has the very sensible behavior of:
> So for example, if "samplelib" cannot be loaded, then names like
> "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried
> also.

I would like to see that extended to include "libsamplelib.so" since that is
the default naming scheme on many *nix platforms. This simple change would
allow me to use the same base library name for my extension on both Windows
and Linux. Otherwise I have to modify my build system to override its
default behavior of adding the lib prefix on Linux.



--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Feature-request-check-for-lib-prefix-for-load-extension-tp96658.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users