On Fri, May 25, 2012 at 8:27 AM, Pavel Ivanov <paiva...@gmail.com> wrote:
> > With regard to the second issue, several experienced people, including > > Richard Hipp, have expressed the opinion in more than one occasion > > that statically linking sqlite avoids some problems that can happen > > otherwise. > > OTOH, all people involved in supporting Linux distributions advocate > against static inclusion and for use of dynamic libraries all the time > so that if some bug or security vulnerability is fixed in SQLite it > could be easily updated for everybody by upgrading only one package. The security argument makes some sense for libraries like libz.so or libjpeg.so, which are operating on unchecked content received from untrusted sources, since a bug in those libraries could result in a security breach. Notice, however, that this is not the case with SQLite. SQLite gets its inputs from the application, not the user. If your applications is feeding unchecked content into SQLite from the open internet, then you have way more serious problems (SQL injection) than any bug in SQLite. Because of this, and our rigorous testing, SQLite has never caused a security vulnerability to my knowledge, even with over 2 billion (2e9) deployments. So I reject that Linux distributors arguments that all libraries should be dynamic. In the case of SQLite, that merely leads to unwanted and troublesome dependencies in the application. It is far better to statically link, so that your application uses exactly the same version of SQLite on the end-users machine as was used during testing. "Fly what you test and test what you fly." -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
