Commit c7703e80 authored by Tails developers's avatar Tails developers
Browse files

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

Conflicts:
	wiki/src/contribute/release_process/test.mdwn
	wiki/src/doc/about/openpgp_keys.fr.po
parents b6c8b7a9 08b5eaf3
......@@ -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?
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]].
......@@ -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).
......@@ -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.
......@@ -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]]
......@@ -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]]
......@@ -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
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.
......@@ -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
=============
......
......@@ -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
=============
......
......@@ -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
......
**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;
......
[[!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.
[[!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.
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
......@@ -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]]
......@@ -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"
msgstr ""
"[GNOME](http://www.gnome.org), un intuitivo y atractivo entorno de escritorio. "
#. type: Title -
#, no-wrap
......@@ -70,80 +71,115 @@ msgid ""
"* [Aircrack-ng](http://aircrack-ng.org/) for wireless networks auditing\n"
"* [I2P](http://www.i2p2.de/) an anonymizing network\n"
msgstr ""
"* [Tor](https://www.torproject.org) y\n"
" [Vidalia](https://www.torproject.org/projects/vidalia) entorno gráfico.\n"
"* [NetworkManager](http://projects.gnome.org/NetworkManager/) para una fácil\n"
" configuración de la red.\n"
"* [Firefox](http://getfirefox.com) configurado con:\n"
" - [Torbutton](https://www.torproject.org/torbutton) pera el anonimato\n"
" y protección contra JavaScript malignos.\n"
" - [FireGPG](http://getfiregpg.org) para la codificación de mails\n"
" - todas las cookies son tratadas como cookies de sesión por defecto;\n"
" La extensión [CS Lite](https://addons.mozilla.org/fr/firefox/addon/5207/)\n"
" que permite un control más avanzado de las cookies para el que lo necesita.\n"
" - [HTTPS Everywhere](https://www.eff.org/https-everywhere)\n"
" encripta mediante SSL las conexiones a una\n"
" gran cantidad de páginas web\n"
"* [Pidgin](http://www.pidgin.im/) configurado con\n"
" [OTR](http://www.cypherpunks.ca/otr/index.php) para información Off-the-Record\n"
" Messaging\n"
"* [Claws Mail](http://www.claws-mail.org/) cliente de correo con\n"
" soporte GnuPG\n"
"* [Liferea](http://liferea.sourceforge.net/) lector de canales de sindicación.\n"
"* [Gobby](http://gobby.0x539.de/trac/) para redacción conjunta.\n"
"* [Aircrack-ng](http://aircrack-ng.org/) para escuchas de redes inalámbricas.\n"
"* [I2P](http://www.i2p2.de/) una red anónima.\n"
#. type: Title -
#, no-wrap
msgid "Desktop Edition\n"
msgstr ""
msgstr "Ofimática\n"
#. type: Bullet: '* '
msgid "[OpenOffice.org](http://www.openoffice.org/)"
msgstr ""
msgstr "[OpenOffice.org](http://www.openoffice.org/)"
#. type: Bullet: '* '
msgid ""
"[Gimp](http://www.gimp.org/) and [Inkscape](http://www.inkscape.org/) to "
"edit images"
msgstr ""
"[Gimp](http://www.gimp.org/) y [Inkscape](http://www.inkscape.org/) para "
"la edición de imágenes"
#. type: Bullet: '* '
msgid "[Scribus](http://www.scribus.net) for page layout"
msgstr ""
msgstr "[Scribus](http://www.scribus.net) para el diseño de página"
#. type: Bullet: '* '
msgid ""
"[Audacity](http://audacity.sourceforge.net/) for recording and editing sounds"
msgstr ""
"[Audacity](http://audacity.sourceforge.net/) para grabar y editar sonidos"
#. type: Bullet: '* '
msgid "[PiTIVi](http://www.pitivi.org/) for non-linear audio/video editing"
msgstr ""
"[PiTIVi](http://www.pitivi.org/) para edición de video"
#. type: Bullet: '* '
msgid "[Poedit](http://poedit.sourceforge.net/) to edit .po files"
msgstr ""
msgstr "[Poedit](http://poedit.sourceforge.net/) para editar archivos .po"
#. type: Bullet: '* '
msgid ""
"[Simple Scan](https://launchpad.net/simple-scan) and [SANE](http://www.sane-"
"project.org/) for scanner support"
msgstr ""
"[Simple Scan](https://launchpad.net/simple-scan) y [SANE](http://www.sane-"
"project.org/) para soporte de escáners"
#. type: Bullet: '* '
msgid "[Brasero](http://projects.gnome.org/brasero/) to burn CD/DVD"
msgstr ""
msgstr "[Brasero](http://projects.gnome.org/brasero/) para grabar CD/DVD"
#. type: Bullet: '* '
msgid ""
"[Sound Juicer](http://burtonini.com/blog/computers/sound-juicer) to rip "
"audio CDs"
msgstr ""
"[Sound Juicer](http://burtonini.com/blog/computers/sound-juicer) para rippear "
"CDs de audio"
#. type: Title -
#, no-wra