If you’re in a position to perform an attack that address space randomization
can defend against, then you have already successfully performed a code
execution attack.
And so far as I can tell... *any* constant strings in the executable, including
things like elements of the SQL language itself
Ticket https://sqlite.org/src/info/de3403bf5ae5f72ed describes a
problem with column naming, and a proposed solution. Today's
question: Should the proposed solution be merged into the 3.20.0
release?
Pros: (1) The change makes column names more consistent. (2) The
change fixes some breakage c
IMHO the inconsistency is a bug of sorts and so would “vote” for a merge now.
In a sense applications that risk breaking are due to hacking around what is
documented. And if the change is going to happen it might as well be now along
with the major versions change.
--
L: http://uk.linkedin.com/i
On 31 Jul 2017, at 17:21, Richard Hipp wrote:
> Ticket https://sqlite.org/src/info/de3403bf5ae5f72ed describes a
> problem with column naming, and a proposed solution. Today's
> question: Should the proposed solution be merged into the 3.20.0
> release?
+1 yes
--
Robert M. Münch, CEO
M: +41
Any application that depends on column names should be using “AS” anyway, might
as well break them sooner.
Disclaimer: I’m probably guilty of depending on column names without “AS”,
which explains why I’ve been sneezing so much lately.
On 7/31/17, 10:21 AM, "sqlite-users on behalf of Richard Hi
Merge it now.
As stated in documentation: "The SQLite documentation clearly states that,
if there is no AS clause, the names of output columns are indeterminate,
arbitrary, and subject to change." It would be my hope that legacy
applications exploiting the returned column name given said documenta
Richard Hipp wrote:
> Cons: (5) The change might cause breakage for legacy applications that
> depend on the older (arguably buggy) behavior. (6) This seems like a
> big change to receive so little beta exposure prior to the official
> release.
I doubt that there are many applications that both d
Funny. :-) (the sneezing lately...)
I say, let's add the change to 3.20.0.
-Original Message-
From: Peter Da Silva
Sent: Monday, July 31, 2017 11:58 AM
To: SQLite mailing list
Subject: Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in
the upcoming 3.20.0 release?
A
On 7/31/17, jose isaias cabrera wrote:
>
> Funny. :-) (the sneezing lately...)
>
> I say, let's add the change to 3.20.0.
The patch is on the 3.20.0 branch. We are testing the 4th release
candidate now.
Thanks for the feedback.
--
D. Richard Hipp
d...@sqlite.org
___
On Mon, 31 Jul 2017, Peter Da Silva wrote:
Any application that depends on column names should be using “AS”
anyway, might as well break them sooner.
Any unintended change in behavior should be considered to be a bug.
There are a great many existing queries which do not use AS statements
for
On 7/31/17, Bob Friesenhahn wrote:
>
> For our own applications we are often doing a wildcard select and
> using a feature of Python APSW to learn the available column names so
> we know the columns which were available.
That should continue to operate as before with no changes.
Nevertheless, I e
Is there any way to predict what error a (buggy) legacy app will receive, or is
that dependent on the wrapper?
Jeff
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
On 7/31/17, Jeffrey Mattox wrote:
> Is there any way to predict what error a (buggy) legacy app will receive, or
> is that dependent on the wrapper?
Dependent on the wrapper, unfortunately.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing l
13 matches
Mail list logo