path: root/wiki/src/todo
diff options
authorTails developers <>2012-10-29 21:21:07 +0100
committerTails developers <>2012-10-29 21:21:07 +0100
commitafdb04423fe0c37f92822c76433f07e8b93276dc (patch)
tree4cead9ef6ffb431cf1c2bbc4a826f15d655af64c /wiki/src/todo
parent50709c1e03bc5eefea0c56bb7b626d386d3842a5 (diff)
parent9b21482eea03d81066bc604cdb032e7606c4536f (diff)
Merge branch 'master' into testing0.14-rc2
Conflicts: wiki/src/support/ wiki/src/support/ wiki/src/support/ wiki/src/support/
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
--- a/wiki/src/todo/APT_repository.mdwn
+++ b/wiki/src/todo/APT_repository.mdwn
@@ -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 `reprepro@incoming.t.b.o`, 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**
+### Now
+* 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:
+ <file:///usr/share/doc/reprepro/manual.html#hooks>
+ [[!tag todo/code]]
+### Later
+* 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
- lizard
+* 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
HTTP access
This is the http:// public APT repository that will be used at Tails
-build time.
-Left to do
-[[!tag todo/sysadmin]]
-* setup HTTP access to this APT repository
+build time. The `tails::reprepro` Puppet class sets nginx up to
+serve that.
Build system
@@ -181,8 +173,8 @@ Example:
$ git checkout devel
$ git merge feature/icedove
- $ ssh \
- sudo -u reprepro reprepro tails-merge-suite feature/icedove devel
+ $ ssh \
+ 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
--- a/wiki/src/todo/Two-layered_virtualized_system.mdwn
+++ b/wiki/src/todo/Two-layered_virtualized_system.mdwn
@@ -112,7 +112,7 @@ degraded security.
aka TorVM design document
* JanusVM
-#A promising, alternative solution: Qubes
+# A promising, alternative solution: Qubes
Qubes is Fedora spin off which takes [security by isolation to the extreme]( 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
+ automatically)
+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
--- a/wiki/src/todo/add_virtualbox_host_software.mdwn
+++ b/wiki/src/todo/add_virtualbox_host_software.mdwn
@@ -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
+from squeeze-backports).
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
+> it.
# Previous Work #
Whonix (back in times where it still was called TorBOX) implemented something very similar.
@@ -24,4 +29,13 @@
* 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](
+ (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.)
[[!tag todo/code]]
diff --git a/wiki/src/todo/custom_dpkg_origin.mdwn b/wiki/src/todo/custom_dpkg_origin.mdwn
new file mode 100644
index 0000000..4260e04
--- /dev/null
+++ b/wiki/src/todo/custom_dpkg_origin.mdwn
@@ -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 <> on the
+debian-derivatives mailing-list.
+Implemented in `feature/dpkg-origin`, candidate for post-0.14.
+[[!tag todo/qa]]
diff --git a/wiki/src/todo/disable_pcmcia__63__.mdwn b/wiki/src/todo/disable_pcmcia__63__.mdwn
index 40b95cd..41f9d5d 100644
--- a/wiki/src/todo/disable_pcmcia__63__.mdwn
+++ b/wiki/src/todo/disable_pcmcia__63__.mdwn
@@ -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
index 0000000..601b432
--- /dev/null
+++ b/wiki/src/todo/fix_gpgApplet_with_Windows_camouflage.mdwn
@@ -0,0 +1,3 @@
+gpgApplet is unusable in Windows camouflage mode.
+[[!tag todo/code]]
diff --git a/wiki/src/todo/handheld_Tails.mdwn b/wiki/src/todo/handheld_Tails.mdwn
index 8e02861..8802225 100644
--- a/wiki/src/todo/handheld_Tails.mdwn
+++ b/wiki/src/todo/handheld_Tails.mdwn
@@ -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.
+# Tasks
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]( and [Sony UX Series ]( 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]( [Ubuntu, Debian, Suse, Fedora, etc](
-* 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
+Random ideas
+* 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
index 0000000..a648ce2
--- /dev/null
+++ b/wiki/src/todo/i2p_hidden_mode.mdwn
@@ -0,0 +1,12 @@
+[[!tag todo/code]]
+[[!tag todo/easy]]
+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
--- a/wiki/src/todo/improve_Windows_Camouflage.mdwn
+++ b/wiki/src/todo/improve_Windows_Camouflage.mdwn
@@ -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 (public) mailing list.
[[!tag todo/research]]
diff --git a/wiki/src/todo/improve_the_forum.mdwn b/wiki/src/todo/improve_the_forum.mdwn
index 7e7fdf0..a358105 100644
--- a/wiki/src/todo/improve_the_forum.mdwn
+++ b/wiki/src/todo/improve_the_forum.mdwn
@@ -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]( 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
--- a/wiki/src/todo/korean_input_system.mdwn
+++ b/wiki/src/todo/korean_input_system.mdwn
@@ -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`.
[[!tag todo/qa]]
diff --git a/wiki/src/todo/obfsproxy.mdwn b/wiki/src/todo/obfsproxy.mdwn
index 05d908e..8dcc4a4 100644
--- a/wiki/src/todo/obfsproxy.mdwn
+++ b/wiki/src/todo/obfsproxy.mdwn
@@ -1,5 +1,4 @@
[[!tag todo/research]]
-[[!tag todo/discuss]]
The [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?
# Future
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
using [[bridge-mode|todo/bridge_support]].
+>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?
+[[!tag todo/discuss]]
[[!tag release/2.0]]
diff --git a/wiki/src/todo/persistence_preset_-_i2p.mdwn b/wiki/src/todo/persistence_preset_-_i2p.mdwn
index 14e41df..159a2e0 100644
--- a/wiki/src/todo/persistence_preset_-_i2p.mdwn
+++ b/wiki/src/todo/persistence_preset_-_i2p.mdwn
@@ -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
--- a/wiki/src/todo/protect_against_external_bus_memory_forensics.mdwn
+++ b/wiki/src/todo/protect_against_external_bus_memory_forensics.mdwn
@@ -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.
[[!tag todo/research]]
diff --git a/wiki/src/todo/replace_iceweasel_with_Torbrowser.mdwn b/wiki/src/todo/replace_iceweasel_with_Torbrowser.mdwn
index 114451f..18de8db 100644
--- a/wiki/src/todo/replace_iceweasel_with_Torbrowser.mdwn
+++ b/wiki/src/todo/replace_iceweasel_with_Torbrowser.mdwn
@@ -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.
-[[!tag todo/discuss]]
+Then, we have to test prototypes before deciding upon the preferred implementation path.
+[[!tag todo/test]]
@@ -48,11 +48,7 @@ Being worked on in `feature/torbrowser`. Our iceweasel Git repo is
documented on [[contribute/git]].
* more tests [[!tag todo/test]]
-* investigate
- [torbutton vs.
- torbrowser.version](
- 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
--- a/wiki/src/todo/replace_or_drop_pdnsd__63__.mdwn
+++ b/wiki/src/todo/replace_or_drop_pdnsd__63__.mdwn
@@ -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]]
+[[!tag todo/qa]]
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
index 0000000..82ae502
--- /dev/null
+++ b/wiki/src/todo/upstream_use_of_relative_path_in_syslinux_config.mdwn
@@ -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]]