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

Sun May 15 00:58:26 CEST 2016

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.

> and skip to a newer snapshot where its
> fixed. Essentially instead of syncing Whonix development around Debian's
> release schedule you instead work around your own - which hopefully
> means more frequent package upgrades. If its still too much then its a
> non-starter but at least its been explored.
> 
>>
>> As a half baked solution there could be a maintainer who provides a
>> Whonix version based on Debian testing who provides patches to make
>> Whonix compatible with both stable and testing.
>>
>> Cheers,
>> Patrick
> 
> 