Does Whonix build script use specific fixed package versions?

Development
1

I’m working on Qubes + Whonix source builds and need to figure this out. Couldn’t efficiently find this in the code, so asking here.

Does Whonix build script use specific fixed package versions?

The “packages” directory seems to come with empty subdirectories with the same Whonix packages hosted on the Whonix Github account that are needed for building Whonix.

ls ./packages

anon-apt-sources-list
anon-base-files
anon-gpg-tweaks
anon-gw-anonymizer-config
anon-gw-base-files
anon-gw-build-upgrade-tor
anon-gw-dhcp-conf
anon-gw-dns-conf
anon-gw-first-run-notice
anon-gw-kde-startmenu
anon-gw-leaktest
anon-iceweasel-warning
anon-icon-pack
anon-kde-streamiso
anon-meta-packages
anon-mixmaster
anon-shared-build-apt-sources-tpo
anon-shared-build-ban-nonfree
anon-shared-build-fix-grub
anon-shared-build-inst-tb
anon-shared-build-log-build-version
anon-shared-build-remember-sources
anon-shared-build-sanity-checks
anon-shared-build-upgrade-torsocks
anon-shared-helper-scripts
anon-torchat
anon-ws-base-files
anon-ws-disable-stacked-tor
anon-ws-dns-conf
anon-ws-kde-startmenu
anon-ws-leaktest
apparmor-profile-anondist
apparmor-profile-gwenview
apparmor-profile-icedove
apparmor-profile-okular
apparmor-profile-pidgin
apparmor-profile-sdwdate
apparmor-profile-timesync
apparmor-profile-torbrowser
apparmor-profile-virtualbox
apparmor-profile-whonixcheck
apparmor-profile-xchat
bootclockrandomization
control-port-filter-python
curl-scripts
damngpl
genmkfile
gpg-bash-lib
gpl-sources-download
grub-enable-apparmor
grub-output-verbose
grub-screen-resolution
ipv4-forward-disable
ipv6-disable
kde-apper-no-autoupdate
kde-common-resolution
kde-dolphin-menubar-enable
kde-kdm-autologin
kde-kgpg-tweaks
kde-konsole-unlim-scrollback
kde-lowfat
kde-mouse-doubleclick
kde-no-move-max-win
kde-privacy
kde-sounds-off
kmix-disable-autostart
knetattach-hide
ksm
msgcollector
open-link-confirmation
pidgin-improved-privacy
pkg-manager-longer-timeouts
pkg-manager-no-autoupdate
poweroff-passwordless
power-savings-disable-in-vms
python-guimessages
qubes-whonix
rads
scurl
sdwdate
sdwdate-plugin-anon-shared-con-check
sdwdate-plugin-anon-shared-streamiso
shared-folder-help
swap-file-creator
swappiness-lowest
tb-default-browser
tb-starter
tb-updater
tcp-timestamps-disable
timesanitycheck
timesync
timezone-utc
tor-ctrl
usability-misc
uwt
vbox-disable-timesync
whonix-base-files
whonixcheck
whonix-developer-meta-files
whonix-gw-desktop-shortcuts
whonix-gw-firewall
whonix-gw-kde-desktop-conf
whonix-gw-network-conf
whonix-host-firewall
whonix-initializer
whonix-legacy
whonix-libvirt
whonix-repository
whonixsetup
whonix-setup-wizard
whonix-welcome-page
whonix-ws-desktop-shortcuts
whonix-ws-firewall
whonix-ws-irc-chat-support
whonix-ws-kde-desktop-conf
whonix-ws-network-conf
whonix-ws-start-menu-additions
xchat-improved-privacy

For each main Whonix tag version, 8, 8.2, 9, 9.4, 9.6, etc does the Whonix build script use specific fixed versions of each of these packages?

For example:

  • Version 8 will always build with the same unique historical Whonix package versions.
  • Version 8.2 will always build with the same unique historical Whonix package versions.
  • Version 9 will always build with the same unique historical Whonix package versions.
  • Version 9.4 will always build with the same unique historical Whonix package versions.
  • Version 9.6 will always build with the same unique historical Whonix package versions.
    …and so on.

Or would each historical version of the build script use whatever happens to be the latest current version of these packages?

Where do I find this in the code?

Thank you!

2

Saw this…

https://phabricator.whonix.org/T157

- The Whonix main repository / build script references packages as git sub modules. I.e. The main repository points to the exact git commit hash of every package.

  • This has the advantage, when git taging a release (such as Whonix 9.6) it points to the exact commit hashes that have been used to create that release (such as 9.6).

  • There is no need to manually maintain a list such as “of package X, version Y” should go into Whonix 10.

And the git sub modules list seems to be here:

https://github.com/Whonix/Whonix/blob/master/.gitmodules

And called from here:

https://github.com/Whonix/Whonix/blob/master/build-steps.d/1100_prepare-build-machine

true "INFO: Updating git sub modules..."
sudo -u "$user_name" git submodule sync
sudo -u "$user_name" git submodule update --init --recursive
true "INFO: Updated git sub modules."

So it seems that each primary Whonix version tag does use specific fixed historical package versions, by way of git submodules?

If correct so far…

Where are these specific commit versions of each package listed in the code?

3

Yes, it’s git submodules. Specific git commits reflect a fixed state, a link to a git commit of a submodule. So they’re tied to specific sub modules, not package versions. By convention, stable and testers-only tags do point to packages that are “finalized”, i.e. that are at the “bumped changelog version” commit, i.e. a finalized version. Not version + x.

The only exception is the whonix-developer-meta-files packages, it doesn’t have meaningful version numbers, but it’s also not used by users. No version numbers needed there, since you need to understand what you’re doing there.

Tying to package versions, well, that would be good to have it enforced on a technical level, but that’s not how git works. Any great new plan, well, that’s https://phabricator.whonix.org/T157.

- Version 8 will always build with the same unique historical Whonix package versions. - Version 8.2 will always build with the same unique historical Whonix package versions. - Version 9 will always build with the same unique historical Whonix package versions. - Version 9.4 will always build with the same unique historical Whonix package versions. - Version 9.6 will always build with the same unique historical Whonix package versions. ...and so on.
Yes, but it's only by convention. However, 8.2 etc. will never point to a different version. Once you got that tag on your hdd, it will never change [unless you delete it and retag yourself or get a new tag from someone else with that name, but retagging is a bad, confusing practice in git].

It’s stored in git. What shows this quite well is this…

git submodule status

Examples…

Good…
973cca3ff49f49195340d88caa21fac87cc4670a packages/genmkfile (1.7-1)

Like all others, except two exception.

Unimportant exception:
packages/whonix-developer-meta-files (2.2-1-22-g851c3d1)

So as of 10.0.0.5.5 the qubes-whonix package also in the repository is in a weird state:
packages/qubes-whonix (9.6.2-4-g17f0775)

Yet have to work that out.

I didn’t mass quote since you figured out half of it and didn’t pluck all into pieces. Perhaps I have forgotten something. Should any questions be still open, please just re-state them, most likely I can answer those.

4

Perfect. Thank you, Patrick. :smiley:

This is to accomplish user builds of Qubes + Whonix that ensure the user gets essentially the same stable package versions as the current ITL binary release.

So trying to sync versions between Binary Install Guide and Source Install Guide.

With checking out different versions of the Whonix repo and running:

git submodule status

I can see the unique historical commits of the various Whonix packages.

So indeed, it does seem that each major Whonix version includes a fixed historical state of the Whonix packages and we should be able to closely sync up the binary releases and user source builds.

Thanks!

5

Yes. They are fixed in that sense. We could also say “frozen”? Not sure. Having this feature is something I find important.

As a related discussion… It can also be “frozen some more”. Using fixed (“frozen”) Debian package versions. See the ‘Current Sources vs Frozen Sources’ thread: