Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 825274 - www-client/seamonkey: system-sqlite default is harmful
Summary: www-client/seamonkey: system-sqlite default is harmful
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Myckel Habets
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks:
 
Reported: 2021-11-20 10:52 UTC by Michał Górny
Modified: 2022-11-03 12:59 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-11-20 10:52:34 UTC
www-client/seamonkey[system-sqlite] forces enabling secure-delete flag on sqlite.  Setting this flag is a bad idea since it means performance penalty and increased disk wear for all application using SQLite.  Unfortunately, system-sqlite is the default on Seamonkey, effectively meaning that:

1) seamonkey is not cleanly installable by default,

2) users installing it are recommended to enable harmful flags on sqlite.

Therefore, I believe that the system-sqlite flag should be disabled by default.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-21 23:58:01 UTC
Alternatively, could mozilla@ investigate fixing the use of secure-delete so it’s not required system-wide? (This is why Firefox dropped it AFAIK)
Comment 2 Myckel Habets 2022-01-29 11:37:34 UTC
(In reply to Michał Górny from comment #0)
> Setting this flag is a bad idea since it means performance penalty
> and increased disk wear for all application using SQLite.

Is there any real live data on this, that backs this claim that it is a real issue that people care about? Do people (gentoo seamonkey users?) use SQLite for large scale databases that do a lot of delete/update actions?

(In reply to Sam James from comment #1)
> Alternatively, could mozilla@ investigate fixing the use of secure-delete so
> it’s not required system-wide? (This is why Firefox dropped it AFAIK)

https://sqlite.org/pragma.html#pragma_secure_delete

Using the schema.secure_delete pragma would be an option for this. This would require patching the seamonkey source code, that this pragma is set to "on"  (alternatively "FAST"), where needed.

As a reference, here is the Firefox/Mozilla bug report that led to the removal of the system sqlite support:

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

I think that with the next release, dropping the enabled default for system-sqlite is nothing more than fair (if you want to keep using it, you'll have to enable it by yourself), optional with a warning for people that enable it. For the long term, I think there should be further discussion if we want to keep it, as the current patch that is applied still requires that the system sqlite version needs at least to be at the same version that seamonkey ships. With this I mean that the patch has room for improvement, which should be taken if we want to keep system-sqlte available as an option.
Comment 3 Konstantin Münning 2022-11-03 12:59:32 UTC
(In reply to Myckel Habets from comment #2)
> Is there any real live data on this, that backs this claim that it is a real
> issue that people care about? Do people (gentoo seamonkey users?) use SQLite
> for large scale databases that do a lot of delete/update actions?

My real life experience on this was that enabling secure-detelte to use system-sqlite made everything else using sqlite *really* slow. There were no large scale databases involved, simple KDE organizer functions seemed to be demanding enough to see a painful significant difference. So I specifically disable system-sqlite for seamonkey since then to avoid this harm, having it generally disabled (or completely removed as it is now for firefox and thunderbird) would be OK as well.

> https://sqlite.org/pragma.html#pragma_secure_delete
> 
> Using the schema.secure_delete pragma would be an option for this. This
> would require patching the seamonkey source code, that this pragma is set to
> "on"  (alternatively "FAST"), where needed.

IMHO this would be the best solution when upstream incorporates it.