[Whonix-devel] revisiting decision of using stable as a Whonix base

bancfc at openmailbox.org bancfc at openmailbox.org
Sun May 15 02:09:16 CEST 2016

On 2016-05-15 00:58, Patrick Schleizer wrote:
> bancfc at openmailbox.org:
>> On 2016-05-13 22:41, Patrick Schleizer wrote:
>>> I don't think this is possible with the resources we have.
>> The lack of maintenance power is decisive but lets look away from it 
>> for
>> a minute to continue the thought exercise.
> Ok.
>>> We cannot manage /etc/apt/sources.list.d/debian.list though a Debian
>>> package / apt-get.
>>> Let's say we had a a snapshot.debian.org in
>>> /etc/apt/sources.list.d/debian.list as anon-apt-sources-list.
>>> At first run of apt-get would install a newer package of
>>> anon-apt-sources-list would ship a newer
>>> /etc/apt/sources.list.d/debian.list with a fresher snapshot and new
>>> Whonix debian packages. Only then, on next run of apt-get update and
>>> apt-get dist-upgrade, newer Debian packages would be installed. So 
>>> the
>>> Whonix packages would have to be tested and compatible with the older
>>> and newer Debian packages.
>> Couldn't apt-during-apt help with this?
> Not that I know.
> apt-during-apt is a hack. Does not have a great way to install packages
> that it just downloaded besides doing that at next boot. It can have 
> one
> package postinst have install another one or two packages or so. Such 
> as
> an ip2box package could download the i2p key and router packages. Not
> suited for something as big as a suite upgrade or so.
>> Postpone any new Whonix package
>> install until next time when anon-apt-sources package and the the new
>> snapshot packages have had a chance to upgrade?
> Somehow the Debian repository could be disabled using apt-pinning
> mechanism. But then users could also not install any new packages on
> their own. Unless there are more hacks around apt-get.
>>> Or use some other mechanism to guide upgrades, something outside of
>>> apt-get which is not great, reinventing such a system.
>>> What would work in theory would be not using the official Debian
>>> repository, but a mirror of all Debian packages under Whonix control. 
>>> So
>>> packages are only made available to everyone once they have been 
>>> tested
>>> for Whonix compatibility. Ubuntu does something similar. They freeze
>>> Debian testing, stabilize and support.
>>> I don't think we have enough reliable working hours per week or even 
>>> per
>>> month to get this done. And I can't do it alone, because then this 
>>> would
>>> be kinda my only task.
>> From what I understand Debian snapshots include packages in the whole
>> archive - its essentially a wayback machine for the official repos.
> Somewhat like that. A snapshot of the state of the repository at that
> date/time, which will never change. No upgrades ever. Unless upgrading
> to a newer snapshot.
>> Every two years you usually have to go thru the dependency testing
>> process with every major stable upgrade.
> Yes.
>> With snapshots you have more control of when the system packages get 
>> to
>> transition.
> Also at the moment there won't uncontrolled suite (ex: wheezy -> 
> jessie)
> upgrades, because we are using specific codenames (ex: jessie) in apt
> sources lists and not generic codenames such as stable. The specific
> codenames will on purpose never be automagically upgraded by Debian
> maintainers. (Generic ones would, that is what they are for.)
> This was done since Whonix 9 and discussed here:
> https://forums.whonix.org/t/done-use-wheezy-or-stable-in-etc-apt-sources-list-d-debian-list
>> Lets say you update the snapshot every year or even 6 months
>> or whenever it suits you. This is still a win from a security point
>> because exposure time is less than waiting for a new stable snapshot.
> Security fixes are uploaded more often than on a 6 month cycle. There
> are so many new security fixes alone in stable, it's impossible to keep
> track of them. If I had to test each of them in advance, I don't think
> that would work. But on testing it's not just security fixes, these can
> be mixed up with package upgrades.
> Let's say hypothetically we used
> http://snapshot.debian.org/archive/debian/20160101T111320Z/ (2016 01 01
> T111320Z). Two months later, a there is a remotely exploitable
> vulnerability when using ssh as a client. Then users would not get any
> upgrades. Unless we transition to a newer snapshot. But this newer
> snapshot comes with all the required testing work and dependency stuff.
> In meanwhile they could have even made changes as big as changing from
> sysvinit to systemd. Unless we had someone to keep track of these
> security fixes, to backport them to our snapshot and upload that.
>> Also if something turns out to be badly broken in the future stable
>> release you can wait it out
> As explained above, future stable releases that would not work for
> Whonix and would require more upgrading work would not be an issue at 
> all.
> Debian Testing: is like me "against" the whole crew of Debian
> maintainers being super active with new releases.
> Debian Stable: No changes besides minor security changes. Can even add
> specific codenames and directly use Debian repository without need to
> monitor too closely what the bleeding edge in Debian is up to.

Then its probably better to trust that Debian maintainers get it right 
(even if its just some of the time) then having to make these decisions 
on an individual basis.

More information about the Whonix-devel mailing list