Justifications presented in the proposal claim hardwired constants for mandatory lock and key style pointer value receiving are a great idea because SQL can't generate constant space strings. And, this is true provided the executable is secret and remote. I know there are a lot of web server jockeys on this forum that are quick with the PHP answers so, perhaps, this assertion makes sense to many.
What I am pointing out is how those same mandatory hardwired secret constants work against security in the domain of local DB on a portable device. On the local device the hacker attack space would be immediately narrowed to constants listed in the executable which, I might add, are guaranteed to work on remote copy of the same application! As well, this particular justification apparently is the reason to make something completely new and utterly parallel with the existing subtype solution which works fine and could be extended to do the job. Did you read the part of the proposal essay where the existing API is mentioned? Now, what about the first part of my reply? No comment on that? You accept what I said there? I'm glad to learn people are coming to their senses. :-) On Mon, Jul 24, 2017 at 1:52 PM, Peter Da Silva < peter.dasi...@flightaware.com> wrote: > On 7/24/17, 3:50 PM, "sqlite-users on behalf of petern" < > sqlite-users-boun...@mailinglists.sqlite.org on behalf of > peter.nichvolo...@gmail.com> wrote: > > BTW, if the hypothetical attacker has a copy of the application, aren't > the constant space pointer access keys' string addresses all there in clear > text > > But that’s not part of the security model, so what’s the problem? > > > _______________________________________________ > 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
