Re: [Tails-dev] Please review and test feature/tordate
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
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
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
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