On May 4, 2009, at 4:33 PM, Peter Samuelson wrote:
>
> [Greg Stein]
>> We chose to allow options other than amalgamation because we'd heard
>> feedback, "let the sysadmins upgrade sqlite independently on their
>> system", rather than pinning svn to whatever-we-shipped. IOW, if we
>> ship an amalgamation, then it becomes *our problem* when bugs appear
>> in sqlite, and we need to spin up a new release.
>
> Yes, and this choice is valuable. In Debian, we learned our lesson
> about redundant copies of library code in our binaries. It used to be
> quite common for projects to copy zlib code into their own projects
> ... until a potential security bug was found in it. For weeks
> afterwards, the Debian Security Team was patching random packages and
> releasing advisories for them. Not much fun for them, I think.
>
> Some years later, the same thing happened with xpdf, another popular
> codebase to copy and paste. So these days, we're pretty strict about
> _not_ embedding library code into our binaries, unless the code really
> is specific to the one project.
There are two sides to this coin.
We work very hard at SQLite to make it backwards compatible in every
way: Query language, C/C++ interface, and file format. But sometimes
applications will come to depend on undefined behavior, such at the
output order of SELECT statement that lack an ORDER BY clause. Then
when the library is upgraded and the arbitrary output order changes,
the application breaks.
Sometimes applications depend on buggy behavior. This has recently
hit SQLite hard. There was a bug in the SUBSTR. The function
SUBSTR(x, 1, 5) should return the first 5 characters of string x, and
it does and always has. However SUBSTR(x, 0, 5) was also returning
the first 5 characters of x. That was a bug. It should have only
returned the first 4. Yet, many programmers, accustomed to zero-based
C or javascript code were writing SUBSTR(x, 0, 5) when SUBSTR(x, 1, 5)
was correct. And because of the bug in SQLite they were getting the
right answer. Now that we have fixed the bug, they are getting the
wrong answer. And that is causing a lot of grief for people who are
upgrading their SQLite libraries.
So, even though we can honestly claim that each version of SQLite is
backwards compatible, because of issues such as the above, it is
normally a good idea to retest everything when changing SQLite
versions. If SQLite is a shared library that dozens of applications
use, upgrading it might break one or more of those apps. Is that
really something you want to do?
I hear your point about wanting to do security updates quickly and
efficiency. But consider that zlib and xpdf (and libpng, and libjpeg,
etc) are libraries that are usually handed untrusted and unchecked
inputs for processing. So a bug in them can easily lead to an
exploit. It is much, much less common to feed untrusted and unchecked
inputs into your SQL database engine on the other hand. There is
usually (hopefully) several layers of application in between the
database engine and the black-hat hacker, and those intervening layers
go a long way toward mitigating any potential for exploits. So I
argue that a vulnerability in SQLite is unlikely to effect most
application and most applications need not be recompiled for
security. Hence it is not really necessary to factor out SQLite into
a single shared library.
Do whatever you want at Debian and with my blessings. (www.sqlite.org
runs on Debian, fwiw, so I do trust and admire your product.) But I
will argue that factoring out all uses of SQLite into a single shared
library will likely result in more application breakage, not less, and
so I encourage you to reconsider your policy.
A number of groups are doing as SVN does and building in SQLite but
providing a compile-time option to use a shared library instead.
That's OK. But if it were me, I would include some disclaimer with
the system-shared-library option to the effect that if it breaks, the
user gets to keep both pieces and that the SVN developers will only
debug problems when using the built-in SQLite. But that's just me....
D. Richard Hipp
drh_at_hwaci.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2061553
Received on 2009-05-05 02:26:19 CEST