Assuming secure auto-update by these applications for the sake of discussion for now without having that checked yet.
HulaHoop:
Verification is a hurdle for many beginners who would then risk running the binaries without checking at all. Including them in Whonix while updating in sync with newer releases upstream, is a better solution.
Good point.
Implementation:
Making them a part of an independent package that drops the binary at some location in the home folder.
ought to avoid writing into linux user /home folder as per Dev/About Debian Packaging - Kicksecure
But this would be a detail that can probably be sorted somehow.
openjdk which we can include the small headless version of in the base packages.
Ok.
I can check/download/verify new releases and update the jar in the Whonix package.
Undecided. Various disadvantages come to my mind. Not sure if any or the totality of these are bad enough to avoid this?
I’d still have to recheck, otherwise we’d implement the first package which doesn’t get scrutinized before I merge or I just trust you’ll do it?
It’s not only me who should be easily and quickly capable of verifying the backdoor-freeness of the package. Also independent auditors should be capable to do so. At minimum securely check the gpg signature matches the binary. Doing so by script?
Is this contrary to verifiable builds / deterministic builds? I mean, by using this style, do we have to undo such a package containing binaries if one day verifiable builds / deterministic builds are in reach?
Freenet is ~ 18 MB. The way git handles binary files, with each release the repository would get bigger since git keeps old files. With each release that git repository would get bigger and bigger, therefore slower to fetch over Tor. If we delete old binary files (reset git / start fresh / git push force), we’d open new issues. https://github.com/Whonix/Whonix couldn’t be updated anymore by standard git commands. It would complain and abort due the force pushed versions. If git repository size alone isn’t a problem enough, would we get more and more contributions/pull requests for addition of more programs in binary form?
Unclean. We’d produce a “source package” that in fact contains binaries.
Needless to say that such a package is unfit for inclusion into Debian.
Why tb-updater then? Could a simplified a lot without download by using a package containing the binaries? (I actually worked on that implementation once but then threw it away due to the big size of the git repository.)
Why didn’t I develop “Whonix freeware” style? What I mean by “freeware” style: Not a “proper” Open Source project with instructions on how to build it from source code. Why bother spending hours and hours with the development of a build script if I could just install Debian inside VirtualBox, manually make all changes by keyboard and mice, run a cleanup script, export ova, upload? Could even post instructions how I did it so anyone can manually replicate. With “freeware style” development would be actually a lot easier, faster. What’s the difference between “freeware style” development and a package that contains binaries? I am trying to demonstrate the slippery line between a clean Open Source project and “freeware style”.