|author||Tails developers <email@example.com>||2012-10-29 21:21:07 +0100|
|committer||Tails developers <firstname.lastname@example.org>||2012-10-29 21:21:07 +0100|
Merge branch 'master' into testing0.14-rc2
Conflicts: wiki/src/support/known_issues.de.po wiki/src/support/known_issues.es.po wiki/src/support/known_issues.fr.po wiki/src/support/known_issues.pt.po
Diffstat (limited to 'wiki/src/todo')
17 files changed, 169 insertions, 68 deletions
diff --git a/wiki/src/todo/APT_repository.mdwn b/wiki/src/todo/APT_repository.mdwn
index 8932b93..f1d8d28 100644
@@ -40,35 +40,31 @@ creating new suites, merging, freezing, etc.
Left to do
-[[!tag todo/code todo/sysadmin]]
-* Allow importing packages, creating new suites, merging, freezing,
- etc.; see the *Documentation* section bellow.
- - reprepro's incoming directory: whatever ACL and umask I set,
- dupload with scp backend, connecting to a non-reprepro user on the
- APT repo box, puts files in there that are not writable by the
- reprepro user, so `reprepro processincoming` fails. In the
- meantime, we upload to `email@example.com`, but it would
- be a bit nicer to deal with that in a better way, some day.
-* test basic operations to check that suite are in the supported set:
- - tails-merge-suite sid -> 0.11 -- **??** (`tails-merge-suite`
- should maybe prevent us from doing that, as 0.11 was released
- already; however, we do need to do this copy to build the 0.11
- ISO, so a --force switch would have to be provided)
- - tails-merge-suite branch with long/complicated name -> devel **OK**
- - tails-merge-suite sid -> devel -- **OK**
- - tails-merge-suite sid -> doc-donate -- **OK**
- - tails-merge-suite sid -> bugfix-boot-profile-vs-live-rofs -- **OK**
- - list suite with long/complicated name **OK**
- - manually import a package into branch with long/complicated name **OK**
- - let inotincoming import a package into branch with long/complicated name **OK**
+* Document the workflow, writing scripts as needed; see the current
+ draft in the *Documentation* section bellow. Then move the
+ documentation to a nice place in [[contribute]]
+ [[!tag todo/documentation]]
+* Tell reprepro to email what `processincoming` does:
+ [[!tag todo/code]]
+* Host our `tails_secrets_apt` Puppet module's Git repository on
+ lizard [[!tag todo/sysadmin]]
* import binary and source packages from our Git repository:
- currently used branches
- past releases... at least the most recent ones, depending on how
much pain it takes to do it.
-* tell reprepro to email what `processincoming` does: <file:///usr/share/doc/reprepro/manual.html#hooks>
-* host our `tails_secrets_apt` Puppet module's Git repository on
+* Allow uploading packages using scp to one's own user at
+ incoming.d.t.b.o, instead of as reprepro@. It was tried, but
+ whatever ACL and umask I set, dupload with scp backend, connecting
+ to a non-reprepro user on the APT repo box, puts files in there that
+ are not writable by the reprepro user, so `reprepro
+ processincoming` fails.
@@ -80,19 +76,15 @@ Done
- generate `conf/incoming`
- generate `conf/pulls`
- create new suites in the APT repository
+* basic operations tested, including importing a big source package
+ (iceweasel) in there, merged into another branch
This is the http:// public APT repository that will be used at Tails
-Left to do
-* setup HTTP access to this APT repository
+build time. The `tails::reprepro` Puppet class sets nginx up to
@@ -181,8 +173,8 @@ Example:
$ git checkout devel
$ git merge feature/icedove
- $ ssh incoming.deb.tails.boum.org \
- sudo -u reprepro reprepro tails-merge-suite feature/icedove devel
+ $ ssh firstname.lastname@example.org \
+ tails-merge-suite feature/icedove devel
$ git push
**FIXME**: I think I had to `retrack` after importing a package, who
diff --git a/wiki/src/todo/Two-layered_virtualized_system.mdwn b/wiki/src/todo/Two-layered_virtualized_system.mdwn
index 7e29ff2..a4f918e 100644
@@ -112,7 +112,7 @@ degraded security.
aka TorVM design document
-#A promising, alternative solution: Qubes
+# A promising, alternative solution: Qubes
Qubes is Fedora spin off which takes [security by isolation to the extreme](http://qubes-os.org/Architecture.html): a Xen hypervizor manages user defined "lightweight virtual machines" or "AppVMs" that isolate user processes, and even certain system-components like the network stack, from each other. Appropriate IPC, file and clip-board sharing supposedly works between programs in different AppVMs.
@@ -269,6 +269,52 @@ New developments in other projects:
> There are many users who would be able to set this up themselves, see [[todo/amd64_kernel]], the virtualisation software can be stored in the persistent storage and installed after booting a tails livecd. As long as the tails kernel supports running virtualisation software, the features in this document can be used today by a great many users
+# Semi-simple solution
+Let's say we [[todo/add_virtualbox_host_software]] to Tails and note
+that a host can start several guests using the same boot media. Hence
+we could add some kind of hook during Tails' boot process that,
+depending on some "magic" parameter set by the host (if any), makes
+Tails boot into specialized profiles (e.g. one that only runs Tor and
+one that runs the GUI stuff). For instance:
+* tor-guest: Boot Tails into a minimal mode (no Xorg etc.) that just:
+ - starts Tor with all its ports listening on the network.
+ - sets an appropriate firewall (only allow inbound traffic from the
+ 'app-guest' vm (see below) to Tor's ports, and only the outbound
+ traffic made by Tor).
+* i2p-guest: Same as 'tor-guest' but adapted for i2p.
+* app-guest: Boot Tails exactly like it's done now except:
+ - it uses the Tor instance running on 'tor-guest' vm.
+ - sets an appropriate firewall (only allow connections to the
+ 'tor-guest' and 'i2p-guest' vms)
+If no such profile is set Tails boots normally. In Tails Greeter we add
+an option called "Use isolation through virtualization" (or similar)
+that when set:
+1. Continues from Tails Greeter to a simple X screen (no GNOME etc.
+ running; only vms are supposed to be run from the host from now on).
+2. Starts a Tails guest with the 'tor-guest' parameter in headless
+ mode. (not sure about the 'i2p-guest' yet since it should start
+3. Starts a Tails guest with the 'app-guest' parameter in fullscreen
+ mode. This is where the user should interact with Tails from now on.
+Relevant settings from Tails Greeter on the host must be forwarded to
+these guests appropriately, e.g. persistent Tor data dir to
+'tor-guest' and all other persistent directories to 'app-guest' (using
+VirtualBox' shared directories, I guess), and the language settings
+should be set in 'app-guest' etc.
+A fine question, though, is whether there exist something like this
+"magical" parameter I talk about above in VirtualBox. The simplest
+would be if Virtualbox could add stuff to the kernel commandline,
+but I doubt that is possible in any sane way. More likely something
+can be achieved through the guest additions. It seems like the host
+can execute arbitrary commands on guests using `vboxmanage
+guestcontrol execute`, which could be used to alter how Tails boots
+from then on.
diff --git a/wiki/src/todo/add_virtualbox_host_software.mdwn b/wiki/src/todo/add_virtualbox_host_software.mdwn
index 29535f0..89eab22 100644
@@ -7,13 +7,18 @@ The compressed .deb files (4.0.x) take 20MB.
We'll soon get a [[todo/boot_menu]], support many languages and go
beyond the 700MB limit, so it may be time to implement this. (Beware:
-in case it matters, we're shipping quite special guest packages that
-I'm going to refresh soon to 4.1.8 --intrigeri)
+in case it matters, we're shipping quite special guest packages --
+custom backport of the guest tools and drivers, built against the xorg
IIRC, VirtualBox host software sets iptables/netfilter up in a way
that makes the guest system bypass the existing firewall / or be
blocked by it, so some care should be taken on this side.
+> I haven't seen any indication of this after years using VirtualBox.
+> I don't even think port-forwarding for the NAT virtual adapter uses
# Previous Work #
Whonix (back in times where it still was called TorBOX) implemented something very similar.
@@ -24,4 +29,13 @@ https://sourceforge.net/p/whonix/wiki/OneVM/
* iptables / bridging was used to route all VM traffic through Tor.
* It was probable affected by identity correlation through circuit sharing.
+# Other resources
+* [How To Set Up A TOR Middlebox Routing All VirtualBox Virtual Machine Traffic Over The TOR Network](http://www.howtoforge.com/how-to-set-up-a-tor-middlebox-routing-all-virtualbox-virtual-machine-traffic-over-the-tor-network)
+ (Using an adaptation of this we could instruct users to set up each
+ guest with Bridged Adapter on `vnet0` and then it should magically
+ rout all traffic from the VM through Tor. Identity correlation
+ could be dealt with by using a dedicated TransPort with the
+ IsolateDestAddr option set.)
diff --git a/wiki/src/todo/custom_dpkg_origin.mdwn b/wiki/src/todo/custom_dpkg_origin.mdwn
new file mode 100644
@@ -0,0 +1,10 @@
+We should add vendor-specific dpkg origin information.
+This would make dpkg-vendor return correct information. See deb-origin(5) and dpkg-vendor(1) for details.
+This was suggested by Paul Wise <email@example.com> on the
+Implemented in `feature/dpkg-origin`, candidate for post-0.14.
diff --git a/wiki/src/todo/disable_pcmcia__63__.mdwn b/wiki/src/todo/disable_pcmcia__63__.mdwn
index 40b95cd..41f9d5d 100644
@@ -12,3 +12,7 @@ See also [[todo/disable expresscard?]]
See implementation ideas on
+> There was a demonstration where a pcmcia firewire card was inserted into a live running system, the host OS auto-installed it, and then the firewire-exploit was used on its firewire ports
+> pcmcia already gets dma, and could be used in other unforeseen ways
+> the 5 minute window looks like the best compromise
diff --git a/wiki/src/todo/fix_gpgApplet_with_Windows_camouflage.mdwn b/wiki/src/todo/fix_gpgApplet_with_Windows_camouflage.mdwn
new file mode 100644
@@ -0,0 +1,3 @@
+gpgApplet is unusable in Windows camouflage mode.
diff --git a/wiki/src/todo/handheld_Tails.mdwn b/wiki/src/todo/handheld_Tails.mdwn
index 8e02861..8802225 100644
@@ -3,6 +3,8 @@ and more "handheld" (tablets, smartphones ...) we need to start
working on better support for such platforms in order to stay relevant
and not fade into oblivion.
This is more of a meta-task listing tasks (some which eventually
should have their own todo pages) necessary for this to become true:
@@ -34,7 +36,11 @@ should have their own todo pages) necessary for this to become true:
>> Agreed. Should be easier on miniaturized PC x86 devices like the [OQO](https://en.wikipedia.org/wiki/OQO#Linux-on-OQO) and [Sony UX Series ](https://en.wikipedia.org/wiki/Sony_Vaio_UX_Micro_PC) and any future x86 device(s).
>> Many Linux distributions already run unmodified on the OQO and Sony UX as these are just standard x86 computers in pocket-sized form factor. [OQO Model 01+ & Debian Linux](http://jamie.lentin.co.uk/computers/oqo-01plus/) [Ubuntu, Debian, Suse, Fedora, etc](https://en.wikipedia.org/wiki/OQO#Linux-on-OQO)
-* Handheld Tails lends itself to being a handheld Tails VoIP device. See [[VoIP_support]]. Could be used today (manually) with OQO and Sony UX Series
+* Handheld Tails lends itself to being a handheld Tails VoIP device.
+ See [[VoIP_support]]. Tails may already work fine on the standard x86 pocket-sized OQO and Sony UX computers (testing needed, everything is likely to work fine except we don't know if there is a driver for the inbuilt 3G modem). One could then also install mumble+onioncat and setup their own pocket-sized Tails VoIP device with some manual effort
diff --git a/wiki/src/todo/i2p_hidden_mode.mdwn b/wiki/src/todo/i2p_hidden_mode.mdwn
new file mode 100644
@@ -0,0 +1,12 @@
+Killing I2P ungracefully is bad for the I2P network, and this is most
+likely a prevalent behaviour among Tails users. For I2P to shutdown
+gracefully, it needs up to 11 minutes to let all its current
+participatory tunnels to expire. Killing I2P before that makes peers
+using these participatory tunnels experience timeouts and disconnects,
+which most definitely is bad for the network. Since Tails users are
+likely to shutdown Tails quickly without waiting these 11 minutes,
+this is a good reason to enable hidden mode = disable participating
diff --git a/wiki/src/todo/improve_Windows_Camouflage.mdwn b/wiki/src/todo/improve_Windows_Camouflage.mdwn
index 09a63fe..eb00664 100644
@@ -5,6 +5,10 @@ Some improvements for [[Windows Camouflage|doc/first_steps/startup_options/windo
- add *--no-splash* startup setting to those applications: scribus, inkscape
>Instead of doing the XP theme, why not do the Windows Classic theme? It's much more square and could avoid people asking why you're using XP over Windows 7.
->>Would they then ask why are you using an even older Windows than Windows XP or Windows 7?
+>>Would they then ask why are you using an even older Windows than
+>>Windows XP or Windows 7?
+>>> Please take discussions where we'll read it, and participate in
+>>> it: the firstname.lastname@example.org (public) mailing list.
diff --git a/wiki/src/todo/improve_the_forum.mdwn b/wiki/src/todo/improve_the_forum.mdwn
index 7e7fdf0..a358105 100644
@@ -83,8 +83,7 @@ Askbot
- *Individually selected*
- *Entire forum (tag filtered)*
- *Comments and posts mentioning me*
- - Shows the ‘Search’ button first by default and the ‘Ask your
- question’ button on the side.
+ - List matching questions on the fly when typing a new question.
- The software is
[translated](https://www.transifex.com/projects/p/askbot/) but there
is no multilingual support from the web interface.
@@ -129,8 +128,7 @@ Shapado
earned badges, new followers, etc*
- *Receive a report with latest group activity (only for group
- - Shows the ‘Ask a question’ first and the ‘Search’ form in the top
- bar. When something is typed in the 'Ask a question' form,
+ - When something is typed in the 'Ask a question' form,
the current set of matching questions are displayed on the fly.
Maybe an intermediate screen will be better if anything is found.
- Group feature:
diff --git a/wiki/src/todo/korean_input_system.mdwn b/wiki/src/todo/korean_input_system.mdwn
index db0c47e..d4b6463 100644
@@ -1,7 +1,5 @@
We're asked to add a Korean input system, and suggested `scim-hangul`.
-Implemented in feature/korean_input.
+Implemented in `feature/korean_input`.
diff --git a/wiki/src/todo/obfsproxy.mdwn b/wiki/src/todo/obfsproxy.mdwn
index 05d908e..8dcc4a4 100644
@@ -1,5 +1,4 @@
The [Obfsproxy](https://tails.boum.org/todo/obfsproxy/) project exists
to achieve the benefits of Tor's bridges together with traffic
@@ -28,6 +27,9 @@ obfsproxy. It's possible to just add a bridge like `obfs2 $IP:$PORT`
through Vidalia's settings and it works (also works with
+> Does this mean a user has to boot Tails, let Tor start (and then
+> start talking on the network), and then switch to "stealth" mode?
A complete TBB+Obfsproxy bundle is available from the project's
@@ -39,4 +41,8 @@ requirement, but such users could opt-out of using the static list and
instead have to input bridges manually, as is currently the case when
+>Would supplying the Obfsproxy project's default obfs2 bridge list in our torrc but with <span class="command">UseBridges 0</span> offer the best solution in all cases?
diff --git a/wiki/src/todo/persistence_preset_-_i2p.mdwn b/wiki/src/todo/persistence_preset_-_i2p.mdwn
index 14e41df..159a2e0 100644
@@ -4,3 +4,6 @@ There's an expensive (in time and bandwidth) bootstrap process
necessary for getting I2P going (generate keys, fetch network database
and hosts file, etc.). This can easily be avoided by making
`/var/lib/i2p` persistent, so a preset should be added.
+When we implement this we should enable I2P's "Laptop mode" (Change
+router identity and UDP port when IP changes for enhanced anonymity).
diff --git a/wiki/src/todo/protect_against_external_bus_memory_forensics.mdwn b/wiki/src/todo/protect_against_external_bus_memory_forensics.mdwn
index 6210ac8..ad9ff4d 100644
@@ -1,3 +1,10 @@
+It should not be that easy, for an attacker with physical access, to
+retrieve Tails memory. (Note that this will especially be the case for
+a [[Tails server|todo/server_edition]] instance left unattended.
@@ -27,10 +34,4 @@ Test for vulnerability
FireWire physical memory manipulation and hacking tool". It
supposedly supports "FireWire/Thunderbolt/ExpressCard/PCMCIA".
-* If/when Tails [[Server_Edition]] is implemented this would be a useful part of the package. A Tails server left running would benefit highly from being protected against external bus memory attacks. A [[screen_locker]] plus the external bus protection would be important features for Tails server.
diff --git a/wiki/src/todo/replace_iceweasel_with_Torbrowser.mdwn b/wiki/src/todo/replace_iceweasel_with_Torbrowser.mdwn
index 114451f..18de8db 100644
@@ -15,8 +15,8 @@ First thing to do is to update this page to reflect our current
position and reasons thereof on this page:
-Then, we have to decide upon the preferred implementation path.
+Then, we have to test prototypes before deciding upon the preferred implementation path.
@@ -48,11 +48,7 @@ Being worked on in `feature/torbrowser`. Our iceweasel Git repo is
documented on [[contribute/git]].
* more tests [[!tag todo/test]]
- [torbutton vs.
- a bit more [[!tag todo/research]]
-* What about the unsafe browser?
+* What about the unsafe browser? [[!tag todo/research]]
- Ship Epiphany?
- Don't care about it? (That is, let is use TorBrowser and have
a uncommon fingerprint.)
diff --git a/wiki/src/todo/replace_or_drop_pdnsd__63__.mdwn b/wiki/src/todo/replace_or_drop_pdnsd__63__.mdwn
index 35fe89e..fef7396 100644
@@ -7,11 +7,9 @@ caching feature.
So perhaps we could simply *remove* pdnsd from the loop.
-Here's a plan:
+This was implemented in `feature/remove-pdnsd`, merged in
+experimental. Let's give it some maturation time in there.
+Later (0.15, likely), if happy, go with this; else, try alternatives
+to pdnsd, such as [[!debpts unbound]].
-1. prepare a branch that implements "remove pdnsd from the loop"
- [[!tag todo/code]]
-1. merge it into `experimental`
-1. let it mature a bit / get exposed to flames there
-1. if happy, go with this; else, try alternatives to pdnsd,
- such as [[!debpts unbound]]
diff --git a/wiki/src/todo/upstream_use_of_relative_path_in_syslinux_config.mdwn b/wiki/src/todo/upstream_use_of_relative_path_in_syslinux_config.mdwn
new file mode 100644
@@ -0,0 +1,10 @@
+Removing all absolute paths in our SYSLINUX config has the advantage
+that to convert the configuration from ISOLINUX to SYSLINUX, the
+directory name is the only thing that actually needs to be changed.
+Implemented in Tails in
+Should be done upstream.
+[[!tag todo/code todo/easy]]