[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Policy for Inclusion of Compiled Software


#1

@Patrick What is the policy for including non-packaged programs by default, that are distributed as Appimages or Jar files? Can you please document your policy on this on the wiki? Is Tor Browser the only exception?

Interesting software we might want to consider in this form is:

Freenet
Cryptocat


#2

Updated wiki page to answer a part of this:

Added a bit here https://www.whonix.org/wiki/Dev/Default_Application_Policy#Others

Installing software other then Tor Browser (as documented above) from non-APT package sources by installed one by default would be nightmare, because:

  • Users wouldn’t know how it was installed and not update it.
  • Updating would be left to the user.
  • It is better if the whole process of download, verification, install, upgrade notification and upgrade is up to the user.

Experiences made with tb-updater and Tor Browser (see above chapter) further discourage this.

Wouldn’t call that a policy though. Rather for reasons of practicality / lowering maintenance effort / lack of developer manpower.

That doesn’t mean development help including Freenet / Cryptocat. That could in long run rather increase maintenance effort. Development help with something that would lower development in long run such as more whonixcheck tests or [looking for contributor] automated test suite.


#3

But these two programs are designed with secure auto-update in mind.

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.

Implementation:

Making them a part of an independent package that drops the binary at some location in the home folder. In Freenet’s case, all deps are self-contained except openjdk which we can include the small headless version of in the base packages. I can check/download/verify new releases and update the jar in the Whonix package. That shouldn’t be too much overhead since the releases are infrequent.

As for cryptocat, my main goal was to provide something with offline messaging for now until Gajim or CoyIM are ready, but it may be unnecessary.


#4

Tor Browser i think we gonna have it from Debian as well through TBB-Downloader from debian repo. So i dont think its an exception anymore no?

although i like to have more support to other secure net philosophy support BUT if their developers doesnt help themselves to support and upload their stuff to debian then its better to avoid them until then. (we cant help lazy , or very low power community which cant upload stuff to debian repos)


#5

TNT BOM BOM:

Tor Browser i think we gonna have it from Debian as well through TBB-Downloader from debian repo.

There’s no Tor Browser in packages.debian.org.


#6

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 https://www.whonix.org/wiki/Dev/About_Debian_Packaging#Files_in_Home_Folder

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”.


Hyper-V and Whonix?
#7

Excellent reasons I hadn’t considered. Bending the rules leads to dev hell. Please add these examples to https://www.whonix.org/wiki/Dev/Default_Application_Policy#Others