Merge remote-tracking branch 'origin/master' into testing

Conflicts:
	wiki/src/contribute/release_process/test.mdwn
	wiki/src/doc/about/openpgp_keys.fr.po

wiki/src/bugs/Failure_to_wipe_memory_when_RAM_disk_is_full.mdwn

@@ -42,6 +42,8 @@ memory.
 Probable solution: Force squashfs to keep certain files, especially
 the shutdown scripts and the files required for kexec, in memory.
 
+--JohnDoe
+
 > Already done using memlockd, see [[memory erasure implementation
 > notes|contribute/design/memory_erasure]] for details. Sounds like we
 > may have missed a few files, though: `/etc/init.d/gdm3 stop` is
@@ -51,4 +53,5 @@ the shutdown scripts and the files required for kexec, in memory.
 >> Do we need to stop gdm using the init-scripts instead of, let's say, kill -9
 >> when doing the *emergency* shutdown? --JohnDoe
 
---JohnDoe
+>>> Tails 0.9 uses pkill and fixes at least that probable cause.
+>>> Can anyone still reproduce the bug, or should we close it?

wiki/src/bugs/Forum_denial_of_service.mdwn

+1. Press *Remove comment*
+2. Click *Cancel*
+3. Enjoy the DOS of all but the simplest functionality (adding comments, etc.)
+
+> I just tried reproducing this; I did not find out what service was denied to me.
+
+>> Try adding a comment now.
+
+>>> The server admins workaround'ed this by disabling the *remove*
+>>> feature; seems like it works => [[done]].
+

wiki/src/bugs/Sound_not_disabled_by_default.mdwn

@@ -10,8 +10,36 @@ Maybe it's better to let the user do the 2 clicks to enable it, just to be on th
 
 > Why not, thanks for mentioning it. Care to bring us a patch? --intrigeri
 
-* see the "Small patch to mute sound on boot time" thread on
-  tails-dev; last patch [[attached here|Sound_not_disabled_by_default/0001-Small-patch-to-mute-the-sound-card-Master-channel-on.patch]]
-* see Liberte Linux' `liberte/src/usr/local/bin/reset-mixer` (which
+Inspiration sources
+===================
+
+* The "Small patch to mute sound on boot time" thread on
+  tails-dev; last patch [[attached
+  here|Sound_not_disabled_by_default/0001-Small-patch-to-mute-the-sound-card-Master-channel-on.patch]].
+* Debian's `alsa-utils` initscript and its `/usr/share/alsa/utils.sh`
+  library deals with channel levels in a way that supports many
+  specific tricks needed by various hardware.
+* Liberte Linux' `src/usr/local/bin/reset-mixer` (which
   seems to only mute the first sound-card, and supports a limited set
-  of controls)
+  of controls, and therefore a limited set of hardware).
+
+Implementation issues
+=====================
+
+What channel(s) shall be muted?
+-------------------------------
+
+According to the [archlinux
+documentation](https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Unmuting_the_channels),
+"ALSA installs with all channels muted by default"; indeed, most of
+the work done by the `alsa-utils` initscript in Debian is merely to
+unmute many channels and toggle many controls.
+
+If we mute all possible channels, most users won't know what
+hardware-dependent list of channels they must unmute and increase
+level in order to get sound output.
+
+So we may want to mute only the `Master` channel. However, this would
+only be a partial implementation of the stated goal: it seems there
+are ALSA drivers that don't expose a `Master` channel, e.g. see [this
+bug report](https://bugzilla.redhat.com/show_bug.cgi?id=594936).

wiki/src/bugs/Tails_0.9_doesn__39__t_open_.onion_sites_.mdwn

@@ -9,3 +9,22 @@ Dec 04 02:37:07.330 [Info] connection_ap_handshake_attach_circuit(): pending-joi
 
 Repeats then:
 SOCKS error: TTL expired
+
+> This has now been confirmed. When Tails sets the initial system time through
+> [tordate](todo/remove_the_htp_user_firewall_exception), the time can be
+> incorrect up to 1.5 hours, but hidden services require a time that is at most
+> 0.5 hour incorrect. This also explains the reported frequency of this issue
+> occuring.
+>
+> Tails will set the time much more accurately when htpdate finishes, and
+> connecting to hidden services should work just fine then. If the user tries
+> to access a hidden service before the time is set, Tor's inability to handle
+> clock jumps may render that hidden service inaccessible until Tor is
+> restarted. Hence it seems we have to ressurect the htpdate notification we
+> had earlier, although with a message urging users to not connecting to
+> hidden services just yet. At least as short term solution.
+>
+> It should also be noted that hidden services running a recent enough Tor
+> (>=0.2.3.7-alpha) will not produce this problem, see [[!tor_bug 3460]].
+> For instance, [[duskgytldkxiuqc6.onion]] is not affected and it's known to
+> run a sufficiently new Tor.

wiki/src/bugs/Tor_connection_error.mdwn

@@ -3,3 +3,8 @@ Booting into Tails 0.9 and connection to the Tor network never happens.  Vidalia
 > Does it happen consistently, or was it just once?
 
 I'm not the OP but it happens intermittently here too on two separate boxes. Manually opening Vidalia will sometimes show a single connection (like to Sickittotheman) but other times the network map is blank or says no relays available. Rebooting may or may not help.
+
+> With that little information, there's nothing we can do about it
+> => closing :/
+
+[[done]]

wiki/src/bugs/X_very_slow_in_0.8.mdwn

@@ -99,3 +99,11 @@ All other processes are 0% or near 0%. Here is some output from syslog:
 >> command-line, by pressing TAB in the initial language choosing
 >> menu. Does it solve the issue you're experiencing?
 >> `xorg-driver=vesa` is worth trying as well.
+
+>>> No reply since months, closing. Hopefully 0.10 (and its backported
+>>> X.Org stack) will help. In this area, there's not much *we* can do
+>>> about it, but include more recent drivers and forward bug reports
+>>> upstream... and the latter needs reactive bug reporters to be
+>>> worth it.
+
+[[done]]

wiki/src/bugs/impossible_to_download_files_bigger_than_64M_with_Iceweasel.mdwn

@@ -10,3 +10,5 @@ The really annoying thing about this bug is that it prevents
 downloading Tails images from Tails itself :/
 
 > Working to [[todo/stop_using_polipo_in_iceweasel]], which will fix this bug.
+
+>> [[!taglink pending]] for Tails 0.10

wiki/src/bugs/non-random_nick_in_Pidgin.mdwn

-In current (pre-0.10) `devel` branch Pidgin nicks are not randomized.
+In current (pre-0.10) `devel` branch Pidgin nicks are sometimes not randomized.

wiki/src/contribute/build.mdwn

@@ -30,8 +30,9 @@ Dependencies
   item](http://ikiwiki.info/todo/mirrorlist_with_per-mirror_usedirs_settings/)
   to get the custom ikiwiki branch. It is not critical to use it
   unless you prepare real releases.
-* `apt-get install libyaml-perl libyaml-libyaml-perl po4a perlmagick`
-  so that the wiki builds smoothly.
+* `apt-get install libyaml-perl libyaml-libyaml-perl po4a perlmagick
+  libyaml-syck-perl` so that the wiki builds smoothly.
+* `dpkg-dev`
 
 Build process
 =============

wiki/src/contribute/release_process.mdwn

@@ -10,23 +10,6 @@ See [[release_process/Debian_security_updates]].
 Update included files
 =====================
 
-Website
--------
-
-Merge the `master` branch into the one used to build the release.
-
-### version number
-
-In the branch used to build the release, update the `inc/*` files to
-match the *version number* and *date* of the new release. Don't update
-`/inc/stable_i386_hash.html` since the hash can't be computed yet.
-
-### design documentation
-
-	git grep PENDING wiki/src/contribute/design*
-
-... and remove the `PENDING-FOR-N.M` warnings.
-
 AdBlock patterns
 ----------------
 
@@ -38,8 +21,8 @@ upgrade i2p
 
 See [[todo/upgrade i2p]].
 
-Update Changelog
-================
+Changelog
+---------
 
 	./release NEW_VERSION PREVIOUS_RELEASED_TAG
 
@@ -67,6 +50,27 @@ Now cleanup some parts of it (semi-)automatically:
 
 ... then launch an editor for the needed cleanup of the result.
 
+included website
+----------------
+
+Merge the `master` branch into the one used to build the release.
+
+### version number
+
+In the branch used to build the release, update the `inc/*` files to
+match the *version number* and *date* of the new release. Don't update
+`/inc/stable_i386_hash.html` since the hash can't be computed yet.
+
+### features and design documentation
+
+Read the Changelog carefully, and update the [[contribute/design]] and
+[[doc/about/features]] pages accordingly.
+
+Also:
+
+	git grep PENDING wiki/src/contribute/design*
+
+... and remove the `PENDING-FOR-N.M` warnings.
 
 Build images
 ============
@@ -119,7 +123,7 @@ Third, generate detached GnuPG signatures for every published image,
 in the same directory as the image and with a `.pgp` extension; e.g.
 
 	gpg --armor --default-key BE2CD9C1 --detach-sign *.iso
-	ls --color=never -1 *.asc | while read asc ; do mv $asc ${asc%%.asc}.pgp ; done
+	rename 's,\.asc$,.pgp,' *.asc
 
 Fourth, create a `.torrent` file for every directory to be published:
 
@@ -136,7 +140,7 @@ Sixth, generate detached GnuPG signatures for every published
 
 	gpg --armor --default-key BE2CD9C1 --detach-sign \
 	  tails-i386-0.7.torrent
-	ls --color=never -1 *.asc | while read asc ; do mv $asc ${asc%%.asc}.pgp ; done
+	rename 's,\.asc$,.pgp,' *.asc
 
 Upload images
 =============

wiki/src/contribute/release_process/test.mdwn

@@ -37,9 +37,7 @@ Check the output for:
 * does the exposed User-Agent match the generic Torbutton's one?
   (connect to a website you can check the access logs for)
 * Entering `about:plugins` in the location bar should say no plugin is
-  installed in every one of the following cases:
- 1. Torbutton add-on enabled in *Tor enabled* status
- 2. Torbutton add-on disabled
+  installed.
 
 # Pidgin
 
@@ -63,13 +61,45 @@ Check the output for:
  - try connecting to the Internet after unsetting `$http_proxy` and
    `$HTTP_PROXY` using a piece of software that does not obey the
    GNOME proxy settings, *and* is not explicitely torified in Tails:
-   `unset http_proxy ; unset HTTP_PROXY ; wget http://monip.org`
+   `unset http_proxy ; unset HTTP_PROXY ; wget --no-proxy
+   http://monip.org` (should result in a "`Connection refused`".
 * firewall: is IPv6 traffic blocked?
  - check output of `ip6tables -L -n`
  - at a place with working IPv6: try connecting to a known-working
    IPv6-enabled server on its IPv6 address over TCP and icmp6.
 * is `/etc/resolv.conf` OK both before/after DHCP has been setup? it should
   *always* read `nameserver 127.0.0.1`
+* verify that all destinations reached from an intensive Tails session
+  are tor routers or authorities: Boot Tails without the network
+  in. Start dumping your whole session's network activity with `sudo
+  tcpdump -i any -w dump` (or better, do the dump on another machine,
+  or on the host OS if Tails is running in a VM). Next, plug the
+  network and do *a lot* of network stuff (why not run do this while
+  doing all the other tests?). Then check that all destinations,
+  e.g. by using tshark and the script below:
+
+(ignore this line, ikiwiki is buggy...)
+
+    DESCRIPTORS=/var/lib/tor/cached-descriptors
+    # Note that these default directory authorities may change! To be
+    # sure, check in Tor's source, src/or/config.c:~900
+    DIR_AUTHS="
+    128.31.0.39 86.59.21.38 194.109.206.212 82.94.251.203 216.224.124.114
+    212.112.245.170 193.23.244.244 208.83.223.34 213.115.239.118"
+    tshark -r dump -T fields -e ip.dst | sort | uniq | \
+    while read x; do
+        ip_expr=$(echo ${x} | sed -e "s@\.@\\\.@g")
+        if echo ${DIR_AUTHS} | grep -qe ${ip_expr}; then
+            continue
+        fi
+        if ! grep -qe "^router [^ ]\+ ${ip_expr}" ${DESCRIPTORS}; then
+            echo "${x} is bad"
+        fi
+    done
+
+  Note that this script will produce some false positives, like your
+  gateway, broadcasts, etc. Also note that running I2P during these
+  test will list every I2P peer as "bad", so that is not recommended.
 
 # Use of untrusted partitions
 
@@ -110,8 +140,8 @@ Check the output for:
 
 # GnuPG
 
-Those tests shall be run using GnuPG on the command-line and the
-Seahorse GUI:
+Those tests shall be run using GnuPG from the command-line and through
+the Seahorse GUI:
 
 * key search/receive: torified? going to the configured keyserver?
  - `gpg --search` tells what server it is connecting to

wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn

 **FIXME** this process is quite complicated and should be automated using VMs
 
-# 0. prepare the systems
+[[!toc levels=2]]
 
-## prepare a Tails USB stick
+# 0. Prepare the needed tools
 
-Install the Tails version to test on a 1st USB stick.
+Pick one of those:
 
-## prepare a minimal lenny live system 
+* [[erase_memory_on_shutdown/qemu_pmemsave]] (pros: no initial setup)
+* [[erase_memory_on_shutdown/pxedump]] (pros: works for bare metal,
+  possible to `|grep` and avoid writting the huge dump file to disk;
+  cons: initial setup)
+* [[erase_memory_on_shutdown/live_system]] (pros: works for bare metal;
+  cons: storage requirements, quite more complicated to get right than
+  the other methods)
 
-We will use this system to do a coldboot attack. It is useful that it is a
-minimal system so that it doesn't fill the RAM to boot.
+# 1. Fill the RAM with a known pattern
 
-To be able to grep /dev/mem, it must have a kernel with CONFIG_STRICT_DEVMEM
-disabled. It is enabled in debian since 2.6.28-1, so we use lenny:
-
-    lb config  --architecture i386 --linux-flavours 686 --apt-recommends false --distribution lenny --binary-images usb-hdd --binary-indices false  --memtest none --packages-lists="minimal" --syslinux-menu vesamenu --initramfs=live-initramfs --bootappend-live "init=/bin/bash"
-
-Then install this image on a 2nd USB stick
-
-# 1. fill the RAM with a known pattern
-
-* boot on Tails
-* launch fillram a few times in parallel (on a 32-bit architecture the
+* Boot Tails.
+* Run `fillram` a few times in parallel (on a 32-bit architecture the
   address space of a given process is usually limited at 3 GiB - or
-  less, depends on the kernel configuration)
-
-  	# for i in $(seq 0 31) ; do fillram & done ; watch free -m
+  less, depends on the kernel configuration); as root:
+  
+  	for i in $(seq 0 31) ; do fillram & done ; watch free -m
 
-# 2. test that you can get the pattern
+# 2. Test that you can get the pattern after rebooting, if no memory wiping takes place
 
-* plug the USB stick containing the minimal Lenny Live system
-* reboot from Tails using SysRq + B
-* boot on the minimal Lenny Live system
-* actually run the test:
+* Make sure your preferred memory scrapper toolkit is ready.
+* Reboot from Tails using `SysRq + b`; if testing in a VM, you'd
+  better be careful not rebooting your host system and proceed like
+  this:
+  
+  	echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger
+  
+* Dump memory and try to find the known pattern in it, e.g.:
 
-  	grep -c wipe_didnt_work /dev/mem
+  	grep -c wipe_didnt_work tails.dump
 
   - you should get some integer larger than zero if the pattern was found in
-    RAM, which is the expected result ;
+    RAM, which is the expected result;
   - you should get `grep: /dev/mem: Cannot allocate memory` otherwise. In that
     case, it is **not** useful to process to the next step, there is something
     wrong in the way you tested.
 
-# 3. test that sdmem really hides the pattern
+# 3. Test that you can*not* get the pattern after rebooting Tails normally
 
-* redo step 1
-* reboot from Tails the recommanded way : system > reboot
-* plug the USB stick containing the minimal Lenny Live system
-* when Tails displays that you can remove the USB stick, unplug the
-  Tails stick and plug the USB stick containing the minimal Lenny Live
-  system in
-* boot on the minimal Lenny Live system
-* actually run the test:
+* Redo step 1.
+* Reboot Tails by running `reboot` as root.
+* Make sure your preferred memory scrapper toolkit is ready (e.g.
+  plug your USB scrapper stick).
+* When Tails tells you you can unplug the USB stick, unplug the
+  Tails stick. 
+* Dump memory and try to find the known pattern in it, e.g.:
 
-  	grep -c wipe_didnt_work /dev/mem
+  	grep -c wipe_didnt_work tails.dump
 
   - you should get zero if the pattern was not found in RAM, which is the
     optimal (and expected) result;

wiki/src/contribute/release_process/test/erase_memory_on_shutdown/live_system.mdwn

+[[!toc levels=2]]
+
+# Prepare the needed tools
+
+We will use a minimal Debian Lenny Live system to setup a coldboot
+attack. 
+
+Why minimal? So that it doesn't overwrite too much of the RAM we want
+to analyze.
+
+Why Lenny? To be able to grep `/dev/mem`, one must run a kernel that
+has `CONFIG_STRICT_DEVMEM` disabled. This setting has been enabled in
+Debian kernels since 2.6.28-1, so we use lenny:
+
+	lb config  --architecture i386 --linux-flavours 686 --apt-recommends false --distribution lenny --binary-images usb-hdd --binary-indices false  --memtest none --packages-lists="minimal" --syslinux-menu vesamenu --initramfs=live-initramfs --bootappend-live "init=/bin/bash"
+
+*Nota bene*: if you have 64 bits hardware, better build an `amd64` image.
+
+Then install this image on a USB stick.
+
+# Dump the RAM
+
+Grep'ing `/dev/mem` does not work on systems with large amounts of
+memory, so let's use `dd`.
+
+	RAM_SIZE_IN_KB=$(free -k | awk '/Mem:/ { print $2 }')
+	dd if=/dev/mem of=$DUMP bs=1K count=$RAM_SIZE_IN_KB oflag=direct
+
+where `$DUMP` is some large enough storage for dumping your entire RAM
+into. It could be a USB drive, but I'd recommend a fast harddrive
+unless you want to wait for half an hour or more. The longer the dump
+takes, the more RAM may be overwritten, so speed is crucial, actually.
+One problem is that the live system built above doesn't include
+cryptsetup, lvm2 and friends, so you'll need an unencrypted partition.
+
+The point is to get `$RAM_SIZE_IN_KB` exactly right -- it should be in
+kilobytes of the 1024 bytes variant. The important thing is just to
+get bs and count in such a way that dd reads as much of your RAM as
+possible, but *NOT* more. Also, bs should be small since dd allocates
+that much memory for its own buffer, and that will overwrite RAM.
+oflag=direct will ensure that no cache is used, which otherwise would
+start to over-write RAM for buffers.

wiki/src/contribute/release_process/test/erase_memory_on_shutdown/pxedump.mdwn

+[[!toc levels=2]]
+
+# Prepare the needed tools
+
+## Memory scrapping software
+
+Sources are available there:
+
+* http://citp.princeton.edu/memory-content/src/bios_memimage-1.2.tar.gz
+* http://citp.princeton.edu/memory-content/src/bios_memimage-1.2.tar.gz.asc
+
+0. Check the tarball signature, unpack.
+0. On an amd64 system run:
+
+   	$ make -f Makefile.64
+
+## DHCP/TFTP server
+
+If you already have a DHCP/TFTP server ready (e.g. thanks to libvirt),
+all you need to do is to make your tftp root point to
+`bios_memimage/pxe`, and set `scraper.bin` in the place of the
+boot loader.
+
+Else, dnsmasq will happily provide both a DHCP and a TFTP server,
+using the following command line:
+
+	$ sudo dnsmasq --conf-file=/dev/null \
+		       --interface=tap0 \
+		       --dhcp-range=172.32.1.2,172.32.1.2,1h \
+		       --enable-tftp \
+		       --tftp-root=/tmp/bios_memimage/pxe \
+		       --dhcp-boot=scraper.bin \
+		       --no-daemon
+
+(Adjust `tftp-root` and `interface` according to your setup.)
+
+Don't forget to punch enough holes in your firewall so that DHCP, TFTP
+and port udp/31337 will go through.
+
+# Run Tails in qemu/kvm
+
+* Start kvm (using a tap interface, in order to 
+  be on layer 2 between host and VM, otherwise DHCP won't work.)
+  
+  	$ kvm -boot nd -net nic,macaddr=0:0:e8:1:2:3,model=rtl8139 -net tap -m 1024 -cdrom tails.iso
+  
+* Setup an IP address on your interface:
+  
+  	sudo ip addr add 172.32.1.1/24 dev tap0
+  	sudo ip link set tap0 up
+* Press 'Q' to disable PXE for the initial boot. Let the Tails CD boot.
+
+# Dump the RAM
+
+* At boot time, press 'N' to enable PXE boot. You should soon see
+  `Waiting for handshake...`
+* Start the dumping process:
+  
+  	pxedump 172.32.1.2 | pv > tails.dump
+
+# Final note
+
+By replacing `tap0` with `eth0` in the previous examples, it should be
+fairly easy to reproduce this for bare metal hardware, provided its
+network adapter and BIOS are PXE-ready.

wiki/src/contribute/release_process/test/erase_memory_on_shutdown/qemu_pmemsave.mdwn

+	qemu -enable-kvm -boot c -m 4096 -cdrom tails.iso
+
+* Open the qemu console (CTRL-ALT-2).
+* Save physical memory to the `tails.dump` file (replace `0xF0000000`
+  (= 4GiB) with the amount of memory bytes assigned to the VM):
+
+	pmemsave 0 0xF0000000 tails.dump

wiki/src/contribute/roadmap.mdwn

@@ -15,5 +15,4 @@
 9. Various other, unordered goals:
   * [[todo/monkeysphere]]
   * [[todo/add_support_for_free_wifi_hotspots]]
-  * [[todo/HTML5_ready_browser]] or [[todo/Flash support]]
   * [[Support running Tails in a VM inside Windows|todo/virtualization support]]

wiki/src/doc/about/features.es.po

@@ -19,7 +19,7 @@ msgstr ""
 #. type: Plain text
 #, no-wrap
 msgid "[[!meta title=\"Features\"]]\n"
-msgstr ""
+msgstr "[[!meta title=\"Características\"]]\n"
 
 #. type: Plain text
 #, no-wrap
@@ -29,13 +29,14 @@ msgstr ""
 #. type: Title =
 #, no-wrap
 msgid "Bundled software\n"
-msgstr ""
+msgstr "Software incluido\n"
 
 #. type: Bullet: '* '
 msgid ""
 "[GNOME](http://www.gnome.org), an intuitive and attractive desktop "
 "environment"