Intent to unship: system SQLite support on Linux (--enable-system-sqlite)

[Marco Bonardo]

The Storage support team intends to remove support for building
Mozilla-based applications using the system provided SQLite library on
Linux (--enable-system-sqlite).



When: After the next mozilla-central merge to Nightly 75, February 10th. We
plan to unship support during the 75 cycle.



Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1611386

Why:

1.

We have limited resources available to us. Developing new features that
touch SQLite low level APIs have often required additional resources to
ensure system SQLite keeps working; we are at a point where we can't afford
those development costs.
2.

We had bugs due to it and the most recent of which, tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1607902, is due to a
mistake we made in relying on some Sqlite internal details. The result of
that, due to supporting system Sqlite, is that we requested the Sqlite team
to undo some code improvements in a .1 release, and, in spite of that,
older Firefox versions on a specific new Sqlite version will crash forever.
We don't want to be in this situation where the Sqlite team can't improve
their product freely.
3.

There is risk of losing users due to the kind of crashing bugs this can
cause, because not everyone would be able to connect the misbehavior with
the update of an external library, that may have been updated along with
other packages updates. And downgrading Sqlite may not be an option if
another software requires the new version instead.
4.

For quite some time we ended up enforcing our Sqlite preferences onto
the system library (things like ‘secure_delete’ or ‘fts’, for example);
addressing those cases requires time and resources. We don't want to
enforce our specific choices.
5.

Our Web Storage team will soon start working with Sqlite encryption, in
a way that may not be compatible with system Sqlite. Again, having to cope
with the system library would mean a lot of additional effort, and more
requirements for system Sqlite that may not be well digested.
6.

We have our own custom memory allocator, and hooking it up has
complications we'd prefer to avoid, if possible.
7.

The benefits of using system SQLite so far have been minimal. We wanted
to be good citizens by sharing as much as possible with the system, as it
was common practice. Today the historical packaging strategies on Linux
systems are evolving with the introduction of new packaging systems (Snap,
Flatpak, for example) that changed the relationship with dependencies by
packing them up with the main application.
The remaining benefits (e.g. package size, memory) are negligible on
today's hardware.
The security benefits we get because the system Sqlite may be more
up-to-date are minimal, because we don't expose Sqlite to Web content, nor
to add-ons. Additionally, we actively track and test every new Sqlite
release and apply them as soon as possible.



Thanks,

Marco

[Lina Cambridge]

Thank you very much for sending this out, Marco! I completely agree with
your analysis: allowing system SQLite complicates things for us, and
introduces many sharp edges without benefitting our users. With packaging
conventions changing, it makes even less sense to keep around. I fully
support its removal.

Cheers,
~ lina

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Marco Bonardo]

The unship patch was just merged in mozilla-central in bug 1611386.

Marco