You're trying to change the topic to the security model. This thread is supposed to be about a lengthy beyond the pale proposal that named all manner of hypothetical boogie men before concluding the only way is a "nuclear solution" as in: "Let's just nuke it, that's only way to be safe". I'll ask again. Did you read the proposal itself? If not, why are you responding on this thread? What is your expertise exactly?
Also, where is your critique of my suggestion to simply and logically expand the well proven and secure subtype mechanism? Why do you presume that Richard's idea to suddenly create a parallel API is automatically the best plan? What is your expertise on the main issue of how to pass around runtime object pointers? If you reply to this thread again, please demonstrate some expertise on the issue at hand. Now I'll address the question of remote attack path in case somebody mistakes a superficial question for a valid point. I don't know any exact attack path, local or remote, and neither does Richard. That's the point. However, all unknowns being equal, if there is a local way to inject pointers then there could be a remote way. Whatever the method, the attacker can then use the supposedly secure constant space names everywhere the application is deployed without further opposition. If you recall, I pointed out that the programmer is free to rotate or randomize integer subtypes of the current API at runtime if it's keeping them from sleep. So in this vein of these hypothetical threats, constant space names are no magic bullet. They have drawbacks too. That being said, let me be very clear once again for short attention spans. There is no attack path in the current API. It works fine and that was proven in the field! So please, BEFORE RESPONDING TO THIS POST, DO READ THE PROPOSAL WHERE THIS IS CLEARLY STATED! On Tue, Jul 25, 2017 at 6:11 AM, Peter Da Silva < peter.dasi...@flightaware.com> wrote: > On 7/24/17, 7:20 PM, "sqlite-users on behalf of petern" < > sqlite-users-boun...@mailinglists.sqlite.org on behalf of > peter.nichvolo...@gmail.com> wrote: > > 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. > > This has nothing to do with the secrecy or otherwise of these strings, but > to prevent developers from _even in principle_ implementing a mechanism for > passing these strings in from SQL. If it is not possible to inject the > string, then it doesn’t matter if they’re secret or not. Think of it as > preventing the creation of a “cross domain” attack from an insecure module. > > You might as well complain that the names of internal functions in SQLite > are known. There’s no way from SQL to call them, so it’s not an attack > surface. > > > 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! > > How do you figure? What is the attack path you’re postulating? > > > _______________________________________________ > 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
