[Tails-dev] apt security updates, wear and tear,

Borrar esta mensaxe

Responder a esta mensaxe
Autor: Chris
Data:  
Para: tails-dev
Asunto: [Tails-dev] apt security updates, wear and tear,
>
> Also, please be kind enough to quickly sum-up what is the exact
> problem you are suggesting us to solve, so that other Tails developers
> don't need to read the whole thread to (try to) understand what the
> problem could be, among discussions about implementation details.


The problem as I see it: The amount of work and technical skill required
to use Tails safely greatly exceeds the ability of 99.9% of technical
users. Trying to support non-technical users with it isn't feasible at
this time.

The solution I am proposing would eliminate the need to regularly
authenticate (via a terminal) updates (manually), eliminate the need to
frequently download large files (ISO, time consuming), not require
significant disk space (something that is a premium), and reduce the
amount of wear on flash media (over time).

1. The tails system should be installed to a flash drive or other
writeable media

2. It should boot in a read-only operations mode by default where log
files and other desktop changes are written to memory only. This is what
AUFS is for.

3. Upon booting the system should allow the user to connect to the
Internet, and then prior to getting a desktop check for updates via apt.
If updates are found the system should re-mount the root partition in
read/write mode prior to updating. This reduces the amount of data users
need to download/use. After an update the system should be shut down. When
the user turns it back on the system would have all the updates.


Additional notes:

I'm not a fan of stacking squashfs for updates as this will increase the
disk space used over time and increase the time between security updates
for underlying packages (kernels, GNOME, etc). squashfs has a 3:1
compression ratio. While this seems like a good idea at first it only
takes three updates before you lose any benefit as older versions of the
file are not removed. No free space becomes available compared to if you
use a non-squashfs filesystem like ext2/ext3/ext4 in a read-only mode.
Tails would still be write-friendly in an update-only mode so there is no
risk to leaking data.

The right away to do it I feel is setting up a Tails repository and
releasing updates on top of Debian/Ubuntu/Trisquel or possibly using rsync
(or similar). As long as this is limited to LTS or stable releases where
the only changes are security patches there should not be a need to
maintain a large cloned separate repository from the main distribution.


I'll add one more thing that is of least concern and unrelated to the above:

I also would like to point out that because Tails is based on Debian it
may work with fewer systems than if it were based on Ubuntu. I also wanted
to mention that the Tails project is concerned about non-free software
(removed/moving away from Truecrypt) and yet ships with non-free drivers
and firmware (I might be wrong... Debian is moving away (again) from
non-free software and have been working hard to separate free and non-free
components). While I think users should be encouraged to use only free
software I don't think it wise to move to a free Linux kernel or remove
non-free drivers/firmware completely. I think it would be smarter to
advise users on hardware purchasing decisions- don't buy HP, Lenovo,
Toshibia for instance (you can't change the Mini PCIe cards for instance
which may not work with GNU/Linux or free software). Other examples: There
are almost no USB wifi cards on the market today which are free software
compatible. There are many other components people use that have similar
dependencies. Basing the distribution off Trisquel at some future point (a
free distribution based on Ubuntu) may be a better way to go. Tails could
then release a free and non-free version easily given the minimal of
differences between the two distributions (the main difference is Trisquel
removes drivers/firmware/kernel/flash/and non-free repositories/and has a
slightly different GUI- still GNOME based with the LTS version with a
minor configuration change to where the 'start menu' is).