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
