Re: [Tails-dev] Please test Tails 0.12-rc1
06/12/2012 12:34 AM, a...@boum.org: Hi, For anyone interested, a release candidate of Tails 0.12 has been made available for your testing pleasure from the following address: Quickly tested, upgrade seems working fine. Only issue I found : I can't find how to shutdown tails in Windows camouflage mode. Start - System - Administration - Power Off. So while it is there, it is a problem that you were unable to find it. 0.12 blocker? I'd be delighted to learn how to put it directly into the start-menu, as the last entry (which I believe is what Windows people would expect). Anyone know how? Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails's plans for Tor's stream isolation in Tor 0.2.3?
intrig...@boum.org wrote: pro...@secure-mail.biz wrote (11 Jun 2012 22:48:48 GMT) : The open question, which remains... If a user types 'gpg ...', 'wget ...' or apt-get ...' in console, how to reinterpret it as ip=127.0.0.1 port=9053 uwt gpg ... so it's gets it's own SocksPort? just drop wrappers listed in the $PATH before the normal application (e.g. /usr/local/bin/gpg), that does that, or did I miss something obvious that would make the trivial solution not work? That sounds like a fine solution. The following test script /usr/local/bin/gpg works. #!/bin/bash ip=127.0.0.1 port=9053 uwt /usr/bin/gpg $* Thanks! (OTOH, even with Tor separate streams, I'm not sure Tails will ever pretend being able to seriously separate multiple identities used at the same time in a given running Tails system.) You must not support multiple identities. Separating web, irc, IM, ssh, git, apt-get, etc. is still desirable and the implementation effort manageable. __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] Tails server
I strongly suggest asking on the Debian Live mailing-list how others are doing. For now, there are no automatic tests : everything is done by hand. I also strongly suggest looking at grml's setup (that uses kantan). Pointers and resources there: https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 This is why I am currently playing around with lettuce[2], a nice Python-powered BDD tool. Great. Please: * share your scenarios early (allows better communication, forces you to start small and to stay practical :) You can find the scenario for my first iteration here : http://git.immerda.ch/?p=jvoisin/tails.git;a=summary (more to follow) * file a RFP bug as soon as you're sure you want to use it -- I want your test suite to integrate nicely with our infrastructure, and that means using software that is in Debian as much as possible. For now, I'm being stuck : I have scenarios, but I have no clear ideas about how they can be run, because most of them are boot-related. I was planing to use qemu, but it doesn't seems to be able to boot from an usb stick. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev -- -- Julien Voisin | pgp key : C48815F2 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9768FD3CC48815F2 | dustri.org ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] Tails server
Hi, jvoisin wrote (12 Jun 2012 11:29:42 GMT) : I strongly suggest asking on the Debian Live mailing-list how others are doing. For now, there are no automatic tests : everything is done by hand. Well, it's sad there was no positive answer, but FWIW, this does not really indicate that all Debian Live downstreams do things by hand: e.g. grml folks did not answer, while they do run automated tests. I also strongly suggest looking at grml's setup (that uses kantan). Pointers and resources there: https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 Did you do so, and if you did, what was the outcome? For now, I'm being stuck : I have scenarios, but I have no clear ideas about how they can be run, because most of them are boot-related. I have a hard time believing neither the grml tools, nor any of the ones listed on our automated build and test resources [0], can be at least used as a basis. Perhaps they are too complex and/or lacking needed functionality, but please beware of the NIH syndrome :) [0] https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 And perhaps, eventually, the autotest framework won't look that overkill. Who knows. I was planing to use qemu, but it doesn't seems to be able to boot from an usb stick. KVM (qemu-kvm package) from testing/sid boots pretty well from a USB 2.0 device passed through the host to the guest. I'm unsure about regular qemu. I'm using this in libvirt/virt-manager. I hope this un-stucks you a bit :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
Hi,
Today I've been testing (what I thought was) the final 0.12 build, but
beyond the usual minor annoyances that I've been reporting for a few
releases now there's a regression with Claws Mail (see below). I suppose
this could be called a blocker, but I'd like input on it. No matter what
this will probably delay the 0.12 release until tomorrow. Ah well...
# Iceweasel
* Does playing HTML5 videos work? In particular, (due to its
popularity) do [youtube](http://www.youtube.com) videos work?
Like in 0.11, I cannot click the element placeholder to enable HTML5
youtube videos. I have to click the noscript toolbar button - blocked
objects - temporarily allow object, to make it work. Which object
is the correct one is non-obvious.
# 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.
Couldn't test.
# Claws
* 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`.
We have a regression here. EHLO/HELO messages leaks the hostname
('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
the last Received field. I managed to track down the culprit: torsocks.
We start claws-mail with torify, which uses torsocks over tsocks.
Switching back to tsocks, like in 0.11 and previous releases, fixes the
leak.
Once an account has been created, the problem can be fixed by setting:
set_domain=1
domain=localhost
in accountrc. Unfortunately we get:
set_domain=0
domain=
no matter what's put in accountrc.tmpl ('set_domain' isn't supported in
templates, and 'domain' is only used in the wizard for guessing the
email address, the servers' hostnames etc.).
Should we call this a blocker? If so, since torsocks apparently behaves
worse than tsocks in this respect I believe the right course of action
is to revert 7f7cd4e (Merge branch 'feature/torsocks' into devel).
Otherwise, I'm unsure of how to make torsocks play nicely with Claws
Mail, but perhaps some one else has a better solution?
[1] todo/applications_audit/claws_mail/
# Whisperback
* can a bug report e-mail be sent?
Eventually, yes. I got this error quite a few times:
Unable to create or to send the mail. [...] peer certificate is
invalid
Hm? Also it seems that some of them were sent any way, despite the error.
# erase memory on shutdown
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]].
Bad results as expected.
The following tests has not been done yet:
# USB Installer/Upgrader
The installed or upgraded Tails medium shall be successfully booted
after each of the following tests.
* Test Clone Install:
- onto a USB stick that has a MBR partition table, and no
partition at all (regression test)
- onto a USB stick that already has an old-fashioned hybrid cat'd
Tails on it
* Test Clone Upgrade (onto a USB install containing an older
Tails):
- onto a USB stick that already has a old-fashioned cat'd hybrid
Tails on it: should warn this action is not supported, and direct
the user to the Clone Install operation mode.
* Test Upgrade from ISO.
- make sure to test that TailsData partitions survive upgrades.
* Test emergency shutdown on boot medium removal feature, on Tails
system installed by this installer.
# Persistence
* Turn off some persistence presets, reboot, and make sure they are
not activated.
Cheers!
signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
On Tue, Jun 12, 2012 at 07:21:36PM +0200, anonym wrote:
# Claws
* 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`.
We have a regression here. EHLO/HELO messages leaks the hostname
('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
the last Received field. I managed to track down the culprit: torsocks.
We start claws-mail with torify, which uses torsocks over tsocks.
Switching back to tsocks, like in 0.11 and previous releases, fixes the
leak.
If tsocks really is good enough, here is a quick and dirty hack, hastly
tested in the wild, no time for a proper patch:
1. Create `/usr/bin/torified-claws-mail` (perm 755) with:
#!/bin/sh
TSOCKS_CONF_FILE=/etc/tor/tor-tsocks.conf tsocks.distrib claws-mail
2. Update .desktop (applications and shortcut icon) to use
`torified-claws-mail`.
I have only gone so far to look upon /proc/$PID/maps to see that
libtsocks was indeed loaded. I don't know if that fixes the regression
or introduce others.
This is not the nicest, but we have in mind to ditch Claws soon enough.
--
Ague
pgpyYoxynyjiI.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
