summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/release_process/test.mdwn
blob: 37182359505188e9794d916b6782cfd68cd48c4f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
[[!toc levels=1]]

# Changes

Keeping an eye on the changes between released versions is one of the
many safeguards against releasing crap.

## Source

Thanks to Git tags one can easily compare the to-be-released source
code with previous version's one e.g.:

	git diff 0.6.1..stable

## Result

`wdiff -l` makes it easy to compare the list of bundled packages and
versions with the one shipped last time e.g.:

	wdiff -l wiki/src/torrents/files/tails-i386-lenny-0.6.1.packages \
	  tails-i386-lenny-0.7.packages | less

Check the output for:

- new packages that may cause harm or make the images unnecessarily
  big
- packages that could be erroneously removed
- new versions of software we might not have audited yet (including:
  does the combination of our configuration with software X version
  Y+1 achieve the same wished results as with software X version Y?)

## Image size

Check the image size has not changed much since the last release.

# Iceweasel

* is web browsing really torified?
 - <https://check.torproject.org/>
 - <http://monip.org/>
* does the exposed User-Agent match the generic Torbutton's one?
  (connect to a website you can check the access logs for)
* Browsing (by IP) a HTTP/HTTPS server on the LAN should be possible.
* Browsing (by IP) a FTP server on the LAN should be possible.
* Entering `about:plugins` in the location bar should say no plugin is
  installed.
* Does playing HTML5 videos work? In particular, (due to its popularity)
  do [youtube](http://www.youtube.com) videos work?

# Pidgin

* pidgin: is an IRC session really torified?
 - if you are running an IRC server: check there
 - else: see if the connection to the IRC server appears in Vidalia
   connections list
* Check OTR is working.
* Check at least IRC and XMPP are working.
* Check if pidgin doesn't leak to many informations on replying to different
  CTCP requests:
  * Start Tails and launch pidgin once done. Connect to an IRC server where you're already on
  * try to /ctcp <T(A)ILS_account_nick> COMMAND
  (for a list of commands, see [this page](http://www.wikkedwire.com/irccommands)).

# Tor enforcement

* firewall: is the Tor-enforcement effective?
 - check output of `iptables -L -n -v`
 - check output of `iptables -t nat -L -n -v`
 - 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 --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

* are any local hard-disk partitions mounted or used as swap?
  boot on a (possibly virtual) machine that has a cleartext swap
  partition not managed by LVM. This swap partition must not be used
  by Tails.
* is a Live system found on a local hard-disk partition used? boot the
  CD/USB stick you are testing on a (possibly virtual) machine that
  has a Tails system copied on a cleartext partition not managed by
  LVM. The CD/USB ramdisk must use the Tails system found on the
  CD/USB, and not the one found on the hard disk. (Also check that
  without Tails, that other Live system boots.)

# Claws

* Check mail over IMAP.
* Send an email.
* Check that the profile works and is torified (specifically the
  EHLO/HELO SMTP messages it sends). Send an email using Claws and a
  non-anonymizing SMTP relay. Then check that email's headers once
  received, especially the `Received:` and `Message-ID:` ones.
* Also check that the EHLO/HELO SMTP message is not leaking anything
  with a packet sniffer: start Claws using the panel icon (which runs
  `torify claws-mail`) to
  avoid using the transparent proxy (which will confuse tcpdump).
  Disable SSL/TLS for SMTP in Claws (so take precautions for not
  leaking your password in plaintext by either changing it temporarily
  or using a disposable account). Then run `sudo tcpdump -i lo -w
  dump` to capture the packets before Tor encrypts it, and check the
  dump for the HELO/EHLO message and verify that it only contains
  `localhost`.

# Whisperback

* can a bug report e-mail be sent?
* is it correctly encrypted?

# GnuPG

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
 - the connection to the configured keyserver must appear in Vidalia's
   list of connections
 - if you run a keyserver, have a look there.

# Monkeysphere

* Monkeysphere validation agent key search/receive: torified? uses
  configured keyserver?

# Time



1. `sudo rm /var/run/htpdate/success /var/run/tordate/done /var/lib/tor/cached-descriptors`
2. disconnect the network cable
3. set the time to an obviously wrong one :

           date --set="Mon, 01 Mar 2000 15:45:34 - 0800"

4. connect the network cable

=> the date should be corrected and Tor/Vidalia should start
correctly.

# erase memory on shutdown

- check that `memlockd` and `udev-watchdog` are running, and that the right
  device is being watched by the later.
- remove Tails' media (USB and cdrom) and check that the memory
  erasure process is started (`Loading new kernel`, at least).

Testing that the needed files are really mapped in memory, and the
erasing process actually works, involves slightly more complicated
steps that are worth [[a dedicated page|test/erase_memory_on_shutdown]].

# Virtualization support

* `modinfo vboxguest` should work
* test in VirtualBox

# I2P

* Make sure that I2P is up-to-date, at least if the
  [changelogs](http://www.i2p2.de/announcements.html) mention that
  security critical bugs were fixed.
* Check that "Applications -> Internet -> I2P" works:
  - You get the "Starting I2P..." pop-up.
  - The router console opens in Iceweasel upon success.
  - You get the "I2P failed to start" pop-up on failure (e.g. no
    network so tordate failed).
* Check that I2P connects to the network:
  - The numbers in the "Peers" section of the router console should be
    non-zero.
  - You should get "Network: Firewalled" in the "General" section
    (implying that the I2P network is reachable but UDP is blocked).
* Check that you can reach some eepsites within Iceweasel, like
  <http://www.i2p2.i2p> and <http://forum.i2p>.
* Check that you can connect to the I2P IRC server through Pidgin.

# Git

* clone a repository over dumb transport (`git://`)
* clone a repository over SSH

# Misc

* Check that there are no weird applications listening to external
  connections with `sudo netstat -ltupn` (everything should be
  `127.0.0.1` (IPv4) or `::1` (IPv6)).
* Check that links to the online website (`Mirror:`) at the bottom of
  bundled static web pages are working. Else, it probably means the
  wiki was not built with the needed patched ikiwiki version.
* Check that all seems well during init (mostly that all services
  start without errors), and that dmesg seems ok.
* Boot without network connection, and then plug it in after
  some arbitrary time; Tor and Vidalia must be autostarted and end up
  in working state.
* Doing an apt-get update and installing random packages.
* Boot on bare-metal on USB and CD.
* Boot and check basic functionality is working for every supported
  language. The virtual keyboard must work and be auto-configured to
  use the same keyboard layout as the X session.
* Try to start with the `truecrypt` option on boot, see if it can be found in
  the *Applications* → *Accessories* menu and that it runs correctly.
* Connecting over SSH to a server on the Internet should work (and
  appear in Vidalia's connections list).
* Connecting (by IP) over SSH to a server on the LAN should work.