Re: [Tails-dev] Please review and test feature/tordate

2012-01-27 Thread intrigeri
 I have reviewed and tested them with positive results, so they are now
 merged too.

:)

 Just to make this tordate story a bit more never-ending I came up
 with a one-liner improvement (wrap-warning!):
[...]
 According to dir-spec.txt all directory authorities generates a new
 consensus every hour (see: fresh-until). Since we fetch a new consensus
 at every boot we can narrow the time points we set the time to to the
 middle of [valid-after, fresh-until], and since fresh until is always
 valid-after + 1 hour... yeah you get the picture. The benefit of this is
 that *if* htpdate fails (which should be much less likely these days)
 then the user still gets a time that is at most 30 minutes incorrect.
 This, incidentally, will prevent the known problem with hidden services
 refusing connections.

Agreed. Please push to feature/tordate, I'll review and merge into
stable and devel.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
  | Who wants a world in which the guarantee that we shall not
  | die of starvation would entail the risk of dying of boredom ?
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] Please review and test feature/tordate

2012-01-27 Thread anonym
01/27/2012 09:36 AM, intrigeri:
 Just to make this tordate story a bit more never-ending I came up
 with a one-liner improvement (wrap-warning!):
 [...]
 According to dir-spec.txt all directory authorities generates a new
 consensus every hour (see: fresh-until). Since we fetch a new consensus
 at every boot we can narrow the time points we set the time to to the
 middle of [valid-after, fresh-until], and since fresh until is always
 valid-after + 1 hour... yeah you get the picture. The benefit of this is
 that *if* htpdate fails (which should be much less likely these days)
 then the user still gets a time that is at most 30 minutes incorrect.
 This, incidentally, will prevent the known problem with hidden services
 refusing connections.
 
 Agreed. Please push to feature/tordate, I'll review and merge into
 stable and devel.

Done (commit 18d23a5).



signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] Please review and test feature/tordate

2012-01-27 Thread Maxim Kammerer
On Fri, Jan 27, 2012 at 17:39, Maxim Kammerer m...@dee.su wrote:
 When writing and testing that script, I noticed that the incoming
 valid-after is never more than an hour earlier from the current
 (correct) time, but at that point it was all kind of black magic, and
 I didn't know that (as you say) the reason is that the directory
 authorities agree on a new consensus each hour.

I think I now recalled the actual reason that stopped me from doing
more research on whether it is possible to rely on hourly new
consensus: fringe conditions. Say at 13:59 (correct time), Tor gets a
13:00-14:00-16:00 (valid-after, fresh-until, valid-until) consensus,
the computer's time is off, and tordate sets the time to 13:30. But
shortly after (maybe even before Tor has established a circuit — not
sure whether that matters), the directory authorities agree on a new
14:00-15:00-17:00 consensus, and 13:30 is now out of that window, so
Tor won't work (will it? The consensus is not yet valid — i.e.,
unverified), and htpdate will fail. With 14:30 estimate that problem
wouldn't have happened.

-- 
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


[Tails-dev] Testing Tails 0.10.1-rc1

2012-01-27 Thread anonym
Hi,

Here's my progress of testing the next point release. I did all the
actual in-session tests, but didn't have time for verifying that the
wipe worked :/.

Also, please look at my weird result in the Tor encforcement section.

DONE:
=

# Iceweasel

All is good.

# Pidgin

All is good, but:

* Check if pidgin doesn't leak to many informations on replying to different
  CTCP requests:

Responds to commands: ping version

# Tor enforcement

Here we're some issues:

* 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 test thanks to my ISP.

* verify that all destinations reached from an intensive Tails session
  are tor routers or authorities:

I did this and got a spook: 217.70.182.162 was a destination! Reverse
DNS yields: cpc-prod2.canardpc.com which I never tried to
contact. Visiting http://canardpc.comif results in a french computer
related website. Err...

When I actually looked at the dump and filtered for that IP address
the only thing I found was two ICMP destination unreachable packets,
so our firewall blocked it, which is good. But I wonder what generated
this non-torified request, as that application obviously leaks. I did
practically the whole test during the session the dump covers so it's
hard for me to tell. The only application that seems reasonable is
iceweasel, which is a bit discomforting.

I'm not sure how to proceed on this one.

# Use of untrusted partitions

All is good.

# Claws

All is good.

# Whisperback

All is good.

# GnuPG

All is good.

# Monkeysphere

All good.

# Time

All is good.

# erase memory on shutdown

- remove Tails' media (USB and cdrom) and check that the memory
  erasure process is started (`Loading new kernel`, at least).

Both ejecting CD and pulling USB triggered shutdown + wipe, so this is good.

Didn't have time for the verification, though.

# Virtualization support

All is good.

# 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.

I2P 0.8.12 was released on Jan 6th 2012 but we're still on 0.8.11. The
announcement says nothing about security fixes, so we're good.

Rest is good.

# Git

All is good.

# Misc

All is good.


NOT DONE


# 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?)

# 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]].



signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev