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
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
> >
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
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
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
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
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
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.
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
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
>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
>>
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
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
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
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
15 matches
Mail list logo