[Tails-dev] Testing Tails 0.10.2-rc1

このメッセージを削除

このメッセージに返信
著者: anonym
日付:  
To: The T(A)ILS public development discussion list
題目: [Tails-dev] Testing Tails 0.10.2-rc1
Below is what I either haven't tested yet or stuff I have tested but
have comments about. I.e. stuff not listed here are already tested with
positive results.

> # Iceweasel
>
> * Browsing (by IP) a FTP server on the LAN should be possible.
>
> # Pidgin
>
> * Check if pidgin doesn't leak to many informations on replying to different
> CTCP requests:


Same as before (only PING and VERSION responds, and does so truthfully.)

> # Tor enforcement
>
> * firewall: is IPv6 traffic blocked?
>  - at a place with working IPv6: try connecting to a known-working
>    IPv6-enabled server on its IPv6 address over TCP and icmp6.


Can't check since my ISP doesn't support IPv6.

> * is `/etc/resolv.conf` OK both before/after DHCP has been setup? it should
> *always* read `nameserver 127.0.0.1`
>
> # 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.)
>
> # 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.


Neither `gpg --search` not seahorse's key search works. WTF? Is the
hidden service down per chance?

> # 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]].
>
> # Git
>
> * clone a repository over dumb transport (`git://`)
> * clone a repository over SSH
>
> # Misc
>
> * 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.


They work, but Torbutton seems to block opening it (file:// vs.
http(s):// I suppose).
>
> * 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.
> * 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.