>SQLite has secure delete too, which does not take much extra time: https://www.sqlite.org/pragma.html#pragma_secure_deleteThe fast variant doesn't guarantee cleanup. The slow one results in additional I/O = SSD wear. And you position your archiver as a faster alternative to zip, and additional cleanup will make it less fast.
>If anyone attempts to rewrite, they need to take security seriously too
Let's say it clear — IRL security of software is not a problem of software author, it is a problem of software user. Most of software have licenses, and every sane license disclaim any liabilty. For software not having licences you get no warranty either. Software is distributed AS IS and its users are liable themselves that they have to use software written by assholes. Ones who is not OK with that have to create an own "Juche"-software, in the extreme case of total so-called "supply-chain security" - the whole stack: own research facilities, own foundries, own hardware, own microcode, own firmware, own OS, own libraries, own applications, own Internet to use their Juche-stack with (because Juche-stack will never pass Web Environment Integrity check), own everything :), and hold liability themselves and blame themselves solely. This will never happen in real world. You know it (don't pretend you don't!), because everyone, including you, uses insecure (and often - intentionally backdoored) software and hardware created by assholes.
In real worlde cannot expect that all the implementers will implement software "securely" when implementing it "securely" faces serious challenges. In this case it is very tempting to just use an SQLite lib from the distro/programming language and add a few code above it. Using another SQLite lib is not easy ... for example in the case of Python
a) one needs a dependency, `apws` package
b) since it is implemented in C, it has to be built, which is a big issue in Windows hosts
c) one needs a hardened SQLite lib
d) it also has to be built
e) one needs a way to plug that hardened SQLite lib into the programming language lib ... surprise, there is no such a feature in `apws`, its author's build scripts link it to hardcoded source-level included SQLite. There are ways to link it to external `libsqlite3.so`, but it seems they are jntentionally made pain in the ass. So one has to implement the feature in `apws` to load a certain shared SQLite lib per connection, persuade the maintainer of `apws` it is needed, upstream it to `apws`, backport that version of `apws` to all legacy versions of Python needed (and some of them are needed because assholes in PSF have decuded to drop certain versions of OSes, so to have a new version of Python one has either to maintain an own fork of it or buy a new PC with a license to a new version of the OS, and given that that OS was created by assholes, that version of the OS should never be used at all, so one has to use a hacky workaround to install a new version of Python onto a dropped version of OS that can break any time), persuade a user that he needs a tool with a dependency...
So in real world the only viable tradeoff a dev has to make is just to use `sqlite3`. And the only viable tradeoff users (including the dev himself) have to make is just use insecure shitware written by assholes in order to just not to create own software and not to withstand the pressures to create a yet another piece of shit, and pray that the files they have to open are not exploits, instead of trying to live without those files. So people will just have to use insecure impls made by assholes. Real world issues caused by the format proposed by you strongly outweight all the benefits your format claims to provide.
>One good point about Pack is that if they use SQLite, almost all will be secure from bad memory access problems, as SQLite is much more tested and reliable.
Just use Kaitai (optionally with Rust/Python/Java/C# target) for parsing of properly designed binary formats and you should be pretty safe from insecure memory access.
>Your point about updating, and while doing that, those files are locked by OS. No one can delete them unless they force it.
Mandatory locks have to be explicitly be enabled in kernel during compilation. Kernels in distros are compiled without mandatory locks. Also, I have seen a lot of times additional files being kept after normal process termination. I have to open bases with `sqlite3` CLI tool to get rid of the unneeded files in those cases (usually backup). And if a process crashes mid-operation, they are always present.
>Just as different implementations of JPEG have different security flaws that need to be taken care of,. And a big reason most will use the official.
JPEG is not based on misusing preexisting widely-available lib that is insecure for that use case. JPEG doesn't create such drastic incentives to create ihsecure shit.
If you want to create a new archive format, just leave SQLite alone and design an own format and own lib, not based on SQLite, not using its source code, but written from scratch, using memory-safe subset of languages, with security-first design, using some ideas from fast databases.
