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

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.