> On Aug 27, 2019, at 12:21 PM, Keith Medcalf <[email protected]> wrote: > > Everything that has been touched by a third-party is inherently > untrustworthy. Thus it is and thus it has always been.
Yes. I have a lot of experience with network coding and security, so I'm aware of this, thanks. My question was simply whether SQLite itself is considered safe when operating on an untrusted database file. > Even ZIP files have a database schema that can be manipulated as does > everything else. The layout of a Zip file is vastly simpler than a SQLite database. A Zip codec does not include an interpreter for a sophisticated programming language. Zip files do not contain program code that runs when the file is read; SQLite databases can. > And how is this in anyway different from a zip process, or a rar processess > or an uncompress process or any or a number of possibly trustworthy programs > processing data coming from an untrustworthy source? (which includes things > like Web Browsers, Video Players, and on and on) Codecs used in such apps are considered attack surfaces and are screened for vulnerabilities. (For example, Google found and fixed some security holes in the TrueType font renderer when they added web-font support to Chrome.) This is precisely what I'm asking about SQLite — is it engineered with the assumption that a database file may be malicious, or is the assumption "garbage in, garbage out"? > Chrome is a Google product. Google's only revenue source is selling > information that they have obtained from third- [anti-Google ranting removed] This is not only off-topic and inaccurate (Google has many other revenue sources), it's the sort of scenery-chewing conspiracy theorizing that's beneath someone with your level of expertise. Check yo'self. —Jens _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
