According to the documentation [1], there might be a risk when allowing untrusted components to access the SQLITE_DBPAGE table. I will try to investigate the options and potential issues, when this problem might occur.

[1] https://www.sqlite.org/dbpage.html

I'm ok with audacity moving to sqlite database files. But is this SQLITE_DBPAGE so important? Maybe Audacity could use sqlite without it? Is just a matter of speed when reading and writing audacity project files?

I am not sure why they have decided to use the dbpage feature, but the only mention of it I can find in the code is here: https://github.com/audacity/audacity/blob/77dab158c37fcb7e448a103400810ac16eda4686/src/ProjectFileIO.cpp#L2430.

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

I have opened an upstream discussion about why this flag is needed here https://github.com/audacity/audacity/discussions/1457. Hopefully they will respond and I can report back.

Upstream Audacity has responded with what they use it for (https://github.com/audacity/audacity/discussions/1457#discussioncomment-1162659):

This extension is used to quickly evaluate the size required by used blocks vs total blocks. Based on that information Audacity decides if there is a need to compact the database on exit. Compacting is not the fastest process, but it is really important due to the way Undo/Redo works. Without it can easily end up with: reddit.com/r/audacity/comments/p18i1o/86gb_project_file_for_a_12hr_audiobook_recording

We will be working on database compaction and probably the code will be more agnostic of the presence of sqlite_dbpage. I'm not sure how quickly we will get there though.

Also, we will need this extension so we can implement project recovery, similar to sqlite3 .recover mode. We will make the code aware of sqlite_dbpage, but in the end, it will mean that recovery won't be available for Fedora users (not that it matters that much, it is an extremely rare case)


@odubaj have you had a chance to investigate this option more? It looks like there is one remaining issue in Audacity upstream that needs to be solved (dynamic page size setting), but once that is, I would like to unbundle sqlite if possible.

From my perspective only wrong usage of sqlite with SQLITE_DBPAGE virtual table can cause problems and it is up to the user to make sure any untrusted components are not using the SQLITE_DBPAGE virtual table in a wrong manner. Enabling this extension should not affect the "normal" usage of sqlite, so we can enable this option in fedora-rawhide.

Fixed in sqlite-3.36.0-4.fc36

Thanks!