Richard. Were you aware of this paper? http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf
Are you able to put two facts together? What prevents stack busting or other code injection attacks on an otherwise valid pseudo-null pointer by simply decoding the address space and observing where strcmp() loads a register to one of the pointer "keys" you've insisted be conveniently published for hackers in the data segment? On Tue, Jul 25, 2017 at 10:43 AM, Richard Hipp <[email protected]> wrote: > On 7/24/17, petern <[email protected]> wrote: > > Great. But, if this is an ultimate replacement for BLOB'ed pointers, > these > > new pseudo-null pointers must support SQLITE_STATIC and destructor > function > > pointer lifetime disposition for those migrating their code. > > Nobody is forcing you to migrate your legacy code to the new API. > Anything that worked for you in 3.19.3 (or earlier) will continue to > work just as well in 3.20.0. If what you are doing now works for you, > then you are welcomed to keep doing exactly the same in the future. > > > > > Why can't the producer destructor disposition be preserved within a chain > > of application functions by subsequent consumers passing SQLITE_STATIC > > disposition as they do now? > > I cannot say with precision because your proposal is vague. But what > you want to do will very likely use extra memory and extra CPU cycles > for the overwhelmingly common case where pointers are not being > passed. We do not want to burden the common case for the convenience > of an outlier. > > -- > D. Richard Hipp > [email protected] > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
