On Fri, Jan 3, 2014 at 9:33 PM, James Turner <ja...@calminferno.net> wrote:
> > I won't begin to tell you how to develop fossil but I do want to throw > out there that OpenBSD has been providing fossil with > --disable-internal-sqlite via it's ports tree and packages fairly > successfully (and with 'fossil sqlite3' support) for the last year+. > > I am the maintainer if you have any questions. > > How much push-back are we going to get from the OpenBSD community if --disable-internal-sqlite goes away due to reliability concerns? I appreciate the desire to keep libraries like libz and libjpeg as shared libraries so that if security problems are encountered they can be fixed in one place. But those libraries are dealing with unvetted input from untrusted sources. SQLite does not work that way. Any application that allows unvetted SQL text through from untrusted sources has way worse problems than any bugs in SQLite. For this reason, while there have been many bugs reported against SQLite from the field in its 14 year history, no security vulnerabilities have ever been reported. Not one. This in spite of SQLite being using in over 1 million different applications with over 2 billion deployments. Security vulnerabilities are just not an issue like they are with libraries that process raw user input. Fossil also uses libz, but we have no issue with using a shared library for that. A version of libz is included in the Fossil source tree, but that is merely to simplify compilation on windows systems which do not commonly have libz handy. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
