Re: [Tails-dev] Please review and merge feature/obfsproxy

[anonym]

12/11/12 15:11, anonym wrote:
> 03/11/12 09:08, intrigeri wrote:
>> Hi,
>>
>> anonym wrote (02 Nov 2012 20:26:34 GMT) :
>>> Basic (perhaps even experimental as it currently lacks documentation)
>>> support for obfsproxy has been added in the branch feature/obfsproxy.
>>> Please review and merge it into devel.
>>
>> We agreed at the Tails summit to not merge new features before their
>> documentation is ready. For the record, this is what allows us to
>> squeeze the delay before feature freeze + RC1 and RC2, because it's
>> now dedicated to translation work, rather than (like we used to do) to
>> doc writing + translations.
> 
> Now done:

I should perhaps have pointed out that I'd really to see this branch
merged for Tails 0.15.

Cheers!


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Fonts, Wheezy and Tails

[anonym]

12/11/12 17:54, intrigeri wrote:
> Hi,
> 
> intrigeri wrote (07 Nov 2012 07:56:48 GMT) :
>> (Testing on Squeeze might be useful too, by the way, in case we want
>> to ship these config files on current Tails. But it seems more
>> important to me to get that fixed upstream, that is in Debian Wheezy.)
> 
> I've tested the suggested configuration both on Tails 0.14 and on
> Wheezy, both on LCD and CRT. The result is:
> 
>   * much better on LCD than without this configuration

Tested, but I couldn't see any difference. OTOH, I'm no font snob. :)

>   * good enough on CRT

Not tested.

> => please review and merge feature/nicer-fonts for 0.15.

Done.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Progress report on the automated test suite

[anonym]

03/11/12 09:55, intrigeri wrote:
>> Next I'd like to announce that the automated test suite, in its
>> current unfinished state, actually has found its very first Tails
>> bug. [...] In other words, our firewall leaks link-local IPv6
>> broadcasts even though it should block everything IPv6 (right?).
> 
> Ouch.
> 
> WAN hat on: please report it (ticket + email) separately so that it
> does not get lost in the middle of this "report on the automated test
> suite" thread.

For the ticket, see todo/really_block_ipv6.

>> I'd like to present the last two with a bit more depth and hear your
>> opinions, especially w.r.t. the fact that they alter Tails or "cheat" in
>> the testing process, so I wonder how "ethical" they are in the context
>> of test-driven development.
> 
>> Running arbitrary commands inside the guest VM
>> ==
> 
>> This is very valuable as it makes many tests that would be truly
>> awkward to do with sikuli into something trivial. libvirt doesn't
>> seem to have something like VirtualBox' `vboxmanage guestcontrol
>> execute` (provided by the VirtualBox guest additions), so
>> I implemented a simple remote shell (read: a backdoor (listening on
>> port 1337 + firewall exception) so expect havoc on the Tails forum!)
>> that starts on the guest when the boot parameter
>> "autotest_never_use_me" is present on the kernel cmdline.
> 
> "autotest_never_use_me" looks to me like "(speaking to) autotest:
> never use me". What about "backdoor_for_autotest"?

I'm not sure I want to mention the word "backdoor". Sure, I do it in the
remote shell server script, but then it's mentioned in a context where
sane people should have no reason to be worried. Makes sense? Other
naming suggestions?

>> Saving/restoring VM snapshots
>> =
>> [...]
> 
> For both features, to reply on the 'how "ethical" they are in the
> context of test-driven development' topic, I'd need a concrete example
> of how this would be used in practice.

I'm sure there are specific/concrete situations where this is not a good
idea. I was more interested  if you saw any fundamental flaws with this
approach since it's a step away from black box testing (same applies to
the remote shell).

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Progress report on the automated test suite

[anonym]

03/11/12 17:18, Ague Mill wrote:
> anonym:
>> Next I'd like to announce that the automated test suite, in its current
>> unfinished state, actually has found its very first Tails bug. Here's
>> the cucumber output of when it was found:
>>
>> [...]
>> And all Internet traffic has only flowed through Tor
>>   # cucumber/iceweasel/step_definitions/torified_browsing.rb:66
>>
>>   The following IPv6 hosts were contacted:
>>   ff02::1
>>   Full network capture available at: [...censored...]
>> There were network leaks! (RuntimeError) [...]
>>
>> In other words, our firewall leaks link-local IPv6 broadcasts even
>> though it should block everything IPv6 (right?). This is promising (not
>> that Tails has this particular bug, but that the test suite found it)!
> 
> I did not run the code itself, but are you sure that these packets came
> from Tails and not from the host system?

Unless there's a bug in tcpdump, yes, I'm sure. tcpdump is configured
with the filter "src host ${IP} or src host ${IP6}", where IP* = the
guest running Tails.

>> Saving/restoring VM snapshots
>> =
>>
>> This is how I intend to use it for a given feature:
>>
>>   Background:
>> Given I restore the background snapshot if it exists
>> [ ... "real" background steps ... ]
>> And I save the background snapshot if it does not exist
>>
>>   [ ... Scenarios ... ]
> 
> Those lines feel like noise: they are an implementation detail and
> should not appear in the scenarios.
> 
> Cucumber offer tags and hooks that should be usable to achieve something
> similar while keeping the scenarios as lean as possible. See:
>  and
> 

I looked at them but couldn't find anything that I thought suited. I
need one hook that runs exactly before the background, and one that runs
exactly after.

>> An issue with restoring past state like this is that our Tor's circuit
>> state may get out-of-sync with the circuit state of the relays they use.
>> For instance, I ran 10 tests that restored to the same post-background
>> state and all but the first two failed to fetch a web page. Then I ran
>> 10 tests where I do the following after each snapshot restore:
>>
>>   1. Stop Tor.
>>   2. Sync time from host to guest.
>>   3. Start Tor.
>>
>> And then all 10 tests succeeded, so it seems resetting Tor like this is
>> highly necessary.
> 
> Indeed, as restoring from a snapshot is likely to break all existing TCP
> connections. Have you tried to see if a SIGHUP sent to Tor is sufficient?

>From previous experiences (e.g. "tordate") Tor doesn't behave well if it
experience a time jump, even if given a HUP, so in order to avoid future
mysterious failed tests due to Tor being confused, I thought restarting
it was for the best.

> Side note: your `try_for` function is very unidiomatic Ruby.
> I suggest you have a look at the part about blocks on
> ,
> and the `yield` and `block_given?` methods.

Thanks, I'll look into it (again)! I actually used `yield` at first, but
didn't get it to work, whereas anonymous functions worked fine. I
suspect those issues might have been due to an unrelated problem (the
stock 'timeout' module in Ruby, which I used at first, can lockup if
syscall get involved, apparently).

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review and merge bugfix/no-console-setup-on-X

[intrigeri]

intrigeri wrote (12 Nov 2012 16:35:20 GMT) :
> I'll be back if I see it again.

I can reproduce it by issueing "sudo su -" in a non-root terminal.
So, I'm bringing my merge request back.

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

Re: [Tails-dev] Please review and merge bugfix/no-console-setup-on-X

[Ague Mill]

intrigeri:
> intrigeri wrote (12 Nov 2012 16:35:20 GMT) :
> > I'll be back if I see it again.
> 
> I can reproduce it by issueing "sudo su -" in a non-root terminal.
> So, I'm bringing my merge request back.

I don't this how this could break anything and it solved your problem in
my tests. Merged.

-- 
Ague


pgpW1iBDBZy4c.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review and merge feature/korean_input

[Ague Mill]

intrigeri:
> please review and merge (into devel):
> 
> branch: feature/korean_input
> ticket: todo/korean_input_system
> 
> "Tested", as in if I choose Korean language in Tails greeter,
> then I get a SCIM applet in the panel, in which I can choose the
> Hangul input method. We've got someone willing to test early ISO
> images once they're out (I guess that would be 0.15~rc1 or something).

Looked fine to my untrained eyes. Merged.

-- 
Ague


pgpyvHJopS1HM.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review and merge feature/hpijs

[Ague Mill]

intrigeri:
> branch: feature/hpijs
> ticket: https://tails.boum.org/todo/install_hpijs/
> 
> Candidate for 0.15. Short log:
> 
>   05b1b35 Install HPIJS PPD files.

Merged.

-- 
Ague


pgptFgc9tkh1H.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.15 release schedule

[Ague Mill]

intrigeri:
> Ague Mill wrote (02 Nov 2012 10:29:43 GMT) :
> > I'd like to propose the following:
> 
> >  * November 13th: freeze and RC1
> >  * November 20th: Firefox ESR is out
> >  * November 22th: RC2
> >  * November 27th: Tails release

The freeze should happen tomorrow (14th) evening. Hopefully
the release candidate will be out the next day.
 
-- 
Ague


pgpdLHc0Y9dYa.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review and merge feature/obfsproxy

[Ague Mill]

anonym:
> 12/11/12 15:11, anonym wrote:
> > 03/11/12 09:08, intrigeri wrote:
> >> Hi,
> >>
> >> anonym wrote (02 Nov 2012 20:26:34 GMT) :
> >>> Basic (perhaps even experimental as it currently lacks documentation)
> >>> support for obfsproxy has been added in the branch feature/obfsproxy.
> >>> Please review and merge it into devel.
> >>
> >> We agreed at the Tails summit to not merge new features before their
> >> documentation is ready. For the record, this is what allows us to
> >> squeeze the delay before feature freeze + RC1 and RC2, because it's
> >> now dedicated to translation work, rather than (like we used to do) to
> >> doc writing + translations.
> > 
> > Now done:
> 
> I should perhaps have pointed out that I'd really to see this branch
> merged for Tails 0.15.

Confirmed working. Merged.

sajolida: I suggest you have a look at the changes in user
documentation, but they are good in my eyes.

-- 
Ague


pgpDmsYHLXfF8.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Progress report on the automated test suite

[intrigeri]

hi,

anonym wrote (13 Nov 2012 13:01:41 GMT) :
> 03/11/12 09:55, intrigeri wrote:
>>> that starts on the guest when the boot parameter
>>> "autotest_never_use_me" is present on the kernel cmdline.
>> 
>> "autotest_never_use_me" looks to me like "(speaking to) autotest:
>> never use me". What about "backdoor_for_autotest"?

> I'm not sure I want to mention the word "backdoor". Sure, I do it in the
> remote shell server script, but then it's mentioned in a context where
> sane people should have no reason to be worried.

Why should the boot parameter name be mentioned in contexts where this
does not apply? (Not a rhetorical question.)

>>> Saving/restoring VM snapshots
>>> =
>>> [...]
>> 
>> For both features, to reply on the 'how "ethical" they are in the
>> context of test-driven development' topic, I'd need a concrete example
>> of how this would be used in practice.

> I'm sure there are specific/concrete situations where this is not a good
> idea. I was more interested  if you saw any fundamental flaws with this
> approach since it's a step away from black box testing (same applies to
> the remote shell).

Sorry, I'm not in a mood to think about fundamental flaws without
examples. Anyhow, I'll try to contribute a bit, hoping that helps.

So, I think that:

1. There are serious shortcomings that come with these features.
   Every time one cheats and uses them, one should know what they are
   actually *not* testing, and think if/how that could be tested.
2. Trying at all costs to totally avoid to use these features is
   probably not a good use of our time.
3. Generally, I like to exercise systems under test at different
   levels, and the remote shell feature is probably the most efficient
   way to zoom-in and run something like "unit tests". This may not
   totally replace more zoomed-out, behavioral testing, though.

That's all I feel I can answer, on a general level.

I'd rather be pointed to cases when it looks much easier or even
needed to resort to such hacks, and then, discuss whether that is
acceptable on a case by case basis. But that may happen later, once
actual reasons to use these features arise.

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

Re: [Tails-dev] Bookmarks persistence - help needed

[Ague Mill]

Ague Mill:
> On Thu, Oct 11, 2012 at 11:11:14PM +0200, Alessandro Grassi wrote:
> > > Yes, it is too late. But don't worry, 0.15 should be out early
> > > December. :)  That gives us a little more room to have the
> > > documentation well polished and delivered with more translations.
> > 
> > Fine. I made a new patch for documentation, and symlink patch is fixed
> > to create the bookmarks folder. All the needed patches are attached.
> 
> Wonderful!
> 
> Everything works fine according to my tests, so  I have pushed your work
> in the `feature/persistent_bookmarks` branch and merged it in
> experimental.
> 
> Please note that I did not upload a customized tails-persistent-setup
> and relied on a patch instead, as I wanted to leave
> tails-persistent-setup alone until 0.14 is out.

New package built and uploaded. `feature/persistent_bookmarks` confirmed
working and merged in `devel`.

-- 
Ague


pgp7YMF2fwsXG.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] forking Tails documentation pages credit

[adrelanos]

Hi!

I've read "How to use GNU licenses for your own software" again. GPLv3
doesn't make much sense for documentation anyway, since it says
"program" and "For interactive programs". Well, I don't have to luxury
of having a more suitable license.

I'll interpret the my wiki page as "interactive program" and the source
of the website as source code.

Having the complete GPLv3 at the top of a website, just because it's a
fork, looks like problematic and overkill to me.

New proposal:






[[include ref=WikiHeader]]

[TOC]

# License #
Whonix Trust wiki page Copyright (C) Amnesia 
Whonix Trust wiki page Portions Copyright (C) 2012 adrelanos


This program comes with ABSOLUTELY NO WARRANTY; for details see the
wiki source code.
This is free software, and you are welcome to redistribute it
under certain conditions; see the wiki source code for details.

# Next header... #

[...]



Attribution and minimal information is directly visible on the website,
a more comprehensive description in the wiki page source () and the full blown GPLv3 is linked and distributed
everywhere. (dedicated Whonix wiki page, with Whonix source code, with
Whonix images, link to gnu.org)

Is this solution satisfying? Open for suggestions. I just want to get
this done.

intrigeri:
> hi,
> 
> adrelanos wrote (10 Nov 2012 13:52:26 GMT) :
>> which is copyrighted by [Tails](https://tails.boum.org/)
> 
> I think this is wrong. If we've written this somewhere, please point
> me to it.
> 
>> The derived work is copyrighted by
>> [adrelanos](https://github.com/adrelanos/Whonix)
> 
> One generally puts email contact information here.

That page contains contact information. Anyway, I removed the whole
sentence.

>> and licensed under
>> the same license GPLv3 or later. (see license below)
> 
> Make sure GPL-3 is included bellow, then.

Answered above.

>> 
>> Copyright:
> 
>>Copyright (C) Amnesia 
> 
> Makes me realize this lacks copyright years on our side. Sorry.
> 
>>Portions Copyright (C) adrelanos 
> 
> I suggest making copyright years explicit.

Done.

>> On Debian GNU/Linux systems, the complete text of the GNU General Public
>> License can be found in the /usr/share/common-licenses' directory.
> 
> I'm not sure how useful this sentence is in the context at hand.

Doesn't hurt either and no one can accuse me of removing anything.

>> The complete text of the GNU General Public License can also be
>> found online on .
> 
> ... and should be included with your stuff.

Yes, I remember to read somewhere "source code has to be distributed
over the same mechanism as the binary". (Download binary, download
source code or binary on cd, source code on cd. Not like download
binary, source code only by snail mail after payment.) To fulfill all
cases I am using this sentence now:

"The complete text of the GNU General Public License can also be found
online on gnu.org , in Whonix
virtual machine images in /usr/share/common-licenses/GPL-3 file or in
Whonix wiki on ."

Cheers,
adrelanos
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] config/chroot_local-packages is now deprecated

[Ague Mill]

Hi!

The current `devel` branch now fetches all binary packages from our APT
repository. From now on, `config/chroot_local-packages` should only be
used for internal tests and external branch reviews. A `README` file is
there to remind you that.

See the following page on how to upload packages and general repository
usage:


This is a very welcome step toward splitting the main Git repository,
and proper source distribution. Hurray!

Please note that `experimental` has not been touched yet. It should
probably be reset and rebased from that point.  I'll take care of it in
the next days if no one beats me to it.

-- 
Ague


pgppTK5Iri7fr.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev