Unbundle libsqlite3?

Hi

Den man. 17. sep. 2018 kl. 15.16 skrev Christoph M. Becker cmbecker69@gmx.de:

Hi!

We bundle an unmodified libsqlite3 for at least two years. Since then
all updates go into any dev, alpha and beta releases, while security
patches (usually backports from libsqlite3) go into stable branches.

ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
2007-01-04[2] (i.e. more than eleven years ago!). ext/pdo_sqlite has no
specific version requirement; there is a check for sqlite3_open()[3]
which I believe is available since 3.0.0.

So is there any particular reason why we still bundle libsqlite3?

[1]
https://github.com/php/php-src/blob/php-7.3.0RC1/ext/sqlite3/config0.m4#L37-L47
[2] https://sqlite.org/oldnews.html#2007_01_04
[3]
https://github.com/php/php-src/blob/php-7.3.0RC1/ext/pdo_sqlite/config.m4#L55-L58

I don't think there is any paticular reason for bundling it anymore,
at least not from the Windows side of things where we should be easily
able to adapt the build system to link to it instead of building the
bundled version. (Anatol cc'ed)

--
regards,

Kalle Sommer Nielsen
kalle@php.net

So is there any particular reason why we still bundle libsqlite3?

An issue is that users often  don't control the version being used and
SQLite adds features to it's SQL dialect from time to time. At the
moment, with the bundled version you can be quite certain that a PHP
version maps to a SQLite version, so when migrating to a different host
you're going to have the same feature set available.  (Or is that not
true since Linux distros don't like using bundled libs, but prefer
system installed shared libs so they just upgrade that on security
issues?)

Most other libraries don't impact in regards to features as much as
newer library features would often have to be exported to userspace
explicitly.

johannes

On Mon, Sep 17, 2018 at 3:16 PM Christoph M. Becker cmbecker69@gmx.de
wrote:

Hi!

We bundle an unmodified libsqlite3 for at least two years. Since then
all updates go into any dev, alpha and beta releases, while security
patches (usually backports from libsqlite3) go into stable branches.

ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
2007-01-04[2] (i.e. more than eleven years ago!). ext/pdo_sqlite has no
specific version requirement; there is a check for sqlite3_open()[3]
which I believe is available since 3.0.0.

So is there any particular reason why we still bundle libsqlite3?

[1]
<
https://github.com/php/php-src/blob/php-7.3.0RC1/ext/sqlite3/config0.m4#L37-L47

[2] https://sqlite.org/oldnews.html#2007_01_04
[3]
<
https://github.com/php/php-src/blob/php-7.3.0RC1/ext/pdo_sqlite/config.m4#L55-L58

+1 on unbundling libsqlite. If we a) don't patch a library and b) it is
widely available in distros, then we have no business bundling the library.
Bundled libraries are extra maintenance work for us and a security risk for
users (we are slower at updating bundled libraries than distros).

Three more libraries that we (as far as I know) bundle without modification
are:

• libzip: Unbundling was already planned for 7.3 but held up due to some
  CI issues. Next try at https://github.com/php/php-src/pull/3532.
• oniguruma
• pcre

I'm not sure how widely available libonig and libpcre2 are.

Nikita

Le 17/09/2018 à 15:16, Christoph M. Becker a écrit :

Hi!

We bundle an unmodified libsqlite3 for at least two years. Since then
all updates go into any dev, alpha and beta releases, while security
patches (usually backports from libsqlite3) go into stable branches.

ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
2007-01-04[2] (i.e. more than eleven years ago!). ext/pdo_sqlite has no
specific version requirement; there is a check for sqlite3_open()[3]
which I believe is available since 3.0.0.

So is there any particular reason why we still bundle libsqlite3?

+1 to drop the bundled library

Remi

On Mon, 17 Sep 2018 15:16:13 +0200 / "Christoph M. Becker"
cmbecker69@gmx.de said :

Hi!

We bundle an unmodified libsqlite3 for at least two years. Since then
all updates go into any dev, alpha and beta releases, while security
patches (usually backports from libsqlite3) go into stable branches.

ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
2007-01-04[2] (i.e. more than eleven years ago!). ext/pdo_sqlite has
no specific version requirement; there is a check for
sqlite3_open()[3] which I believe is available since 3.0.0.

I believe that SQLite3Stmt::readOnly requires SQLite 3.7.4 released in
2010, bundled since PHP 5.3.6 (!).

There is also a PR patch (from me) that should make it in PHP 7.4 that
implements this feature in pdo_sqlite too.

I believe this is the most recent feature that we are using. But it
should return false if the SQLite version installed is older than that
(IMHO it should throw an exception instead, but that's the current
behaviour anyway).

As for bundling or not, I'm on Devuan and it is using the system
version of SQLite as far as I know so I don't see the need to bundle it
with PHP, but I don't have a good view of whether it might be needed on
other platforms.

We bundle an unmodified libsqlite3 for at least two years. Since then
all updates go into any dev, alpha and beta releases, while security
patches (usually backports from libsqlite3) go into stable branches.

ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
2007-01-04[2] (i.e. more than eleven years ago!). ext/pdo_sqlite has no
specific version requirement; there is a check for sqlite3_open()[3]
which I believe is available since 3.0.0.

So is there any particular reason why we still bundle libsqlite3?

[1]
https://github.com/php/php-src/blob/php-7.3.0RC1/ext/sqlite3/config0.m4#L37-L47
[2] https://sqlite.org/oldnews.html#2007_01_04
[3]
https://github.com/php/php-src/blob/php-7.3.0RC1/ext/pdo_sqlite/config.m4#L55-L58

I have submitted https://github.com/php/php-src/pull/3548.

--
Christoph M. Becker