On Fri, Jan 03, 2014 at 10:04:25PM -0500, Richard Hipp wrote: > 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
I'll check with others but I'm not sure reliability is really the concern. We imported SQLite into our base tree. Because of this we try, when possible, to limit duplicating libraries in ports to reduce having to patch multiple versions of the same libraries. A good example of this is Firefox and newer software that uses WebKit. These projects like to ship their own copies of libraries to make their building process easier. For us, it just increases our headaches when it comes to maintaining required patches. SQLite is clearly a different case. I believe the only major patch we have in our tree relates to adding arc4random(3) support. If fossil removes --disable-internal-sqlite I highly doubt I'll be asked to maintain this feature in our ports tree (again I'll check with others and get back with you). -- James Turner _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
