Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-25 Thread anonym
24/02/14 16:54, Kathleen Brade wrote:
 On 2/20/14, 4:15 PM, anonym wrote:
 Any ETA on when my patches can be reviewed? ...
 
 Feedback from Mark and myself for: [...]

Thanks for the review!

Before actually fixing any of your concerns I'd to know how you'd like
me to prepare these additional changes. Do you want them in new commits
(easier to review), or do you want me to rewrite the history by fixing
the old commits (nicer VCS history)?

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-25 Thread Kathleen Brade

On 2/25/14, 1:24 PM, anonym wrote:

... Do you want them in new commits
(easier to review), or do you want me to rewrite the history by fixing
the old commits (nicer VCS history)?


We prefer nicer/shorter revision history.
Thanks!
-- Kathy


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-25 Thread Mike Perry
Mark Smith:
 Another small consideration is that we (TBB developers) will probably
 not test Tor Launcher as a standalone XUL application because we will
 not be using it that way... so it is possible we will accidentally break
 something that is needed in that mode.  Of course we will try not to do so.
 
 As long as Tor Launcher more or less sticks with its current design, and
 continues to keep away from stuff directly affecting Firefox (leaving
 that to Tor Button) and only do stuff related to
 starting/configuring/monitoring Tor processes, I expect very little
 problems due to your upstream changes.
 
 Does this look like your plan for the foreseeable future?
 
 Yes, although I leave it to Mike (in his role as TBB chief
 architect) to comment as well.  Requirements may dictate a future
 change in direction, but for now the plan is for Torbutton and Tor
 Launcher to work together but maintain their distinct roles.

Yes, I think it is reasonable to assume that Tor Launcher should behave
independently of Firefox (modulo minor oversights). In addition to
XULRunner/Tails, we want it to continue to work with Thunderbird, and be
easy to port to Instantbird, as well.

To what degree does Tails have automated testing? Will you be able to
keep an eye on 'master' and tell us if you run into problems?

As far as the patches, they should have a Tor Launcher ticket to
correspond to them. Perhaps attach them there?


-- 
Mike Perry


signature.asc
Description: Digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-25 Thread anonym
25/02/14 23:46, Mike Perry wrote:
 Mark Smith:
 Another small consideration is that we (TBB developers) will probably
 not test Tor Launcher as a standalone XUL application because we will
 not be using it that way... so it is possible we will accidentally break
 something that is needed in that mode.  Of course we will try not to do so.

 As long as Tor Launcher more or less sticks with its current design, and
 continues to keep away from stuff directly affecting Firefox (leaving
 that to Tor Button) and only do stuff related to
 starting/configuring/monitoring Tor processes, I expect very little
 problems due to your upstream changes.

 Does this look like your plan for the foreseeable future?

 Yes, although I leave it to Mike (in his role as TBB chief
 architect) to comment as well.  Requirements may dictate a future
 change in direction, but for now the plan is for Torbutton and Tor
 Launcher to work together but maintain their distinct roles.
 
 Yes, I think it is reasonable to assume that Tor Launcher should behave
 independently of Firefox (modulo minor oversights). In addition to
 XULRunner/Tails, we want it to continue to work with Thunderbird, and be
 easy to port to Instantbird, as well.

Excellent!

 To what degree does Tails have automated testing?

While we have an automated test suite that we run on release time, we're
not quite there yet to have it run on nightly basis. To automatically
package and test the development branches of various applications (our
own, Tor Launcher, etc.) is yet another step but we do have plans in
that direction.

 Will you be able to keep an eye on 'master' and tell us if you run into 
 problems?

I suppose that for now this will become a manual step for the Tails
Release Manager, similar to how we try to keep in sync with your TBB work.

 As far as the patches, they should have a Tor Launcher ticket to
 correspond to them. Perhaps attach them there?

Done in ticket #11074 (and children).

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-24 Thread Kathleen Brade

On 2/20/14, 4:15 PM, anonym wrote:

Any ETA on when my patches can be reviewed? ...


Feedback from Mark and myself for:
   0001-Support-packaging-as-a-standalone-XUL-application.patch
--
For the Makefile:
A small issue:  Mark and I would prefer that files not be copied into 
the src tree during packaging.  An alternative would be to stage the 
files under pkg (I realize that will be more work).


For application.ini.in:
Why do you have MinVersion set to 17.0.0?
Unless for some reason you need MinVersion set to 17, you should make it 
24.0.0.  At this point, we really don't want anyone running with Gecko 
older than 24.  We are going to change the minVersion in Tor Launcher's 
install.rdf file to 24.0.0 as well.



Feedback for:
   0002-Split-Tor-process-starting-code-from-control-code.patch
--
For tl-process.js:
Mark and I prefer that the line setting mTorProcessStatus to unknown be 
left in _startTor().  Some day we may call that multiple times and we'll 
want it initialized correctly in there.  The status is initialized to 
unknown (0) upon creation so you do not need to set it in _controlTor().



Feedback for:
   0003-If-TOR_CONFIGURE_ONLY-1-only-configure-Tor.patch
--
For tl-process.js:
Please fix the else to be on its own line (to match the rest of the file).

For tl-util.jsm:
It would be nice if shouldOnlyConfigureTor() had a corresponding pref 
like shouldStartAndOwnTor() does (other people may find the concept 
useful).  Perhaps extensions.torlauncher.only_configure_tor?



Feedback for:
  0004-If-FORCE_NET_CONFIG-is-set-show-network-settings-iff.patch
--
Please change FORCE_NET_CONFIG to TOR_FORCE_NET_CONFIG.

Thanks!

-- Kathy

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-20 Thread intrigeri
anonym wrote (19 Feb 2014 19:14:40 GMT) :
 The primary profile can be used offline too. For instance, if a link in
 some GNOME notification is clicked, Iceweasel using the primary profile
 will be opened. We'd some how need to make Tor Launcher *not* run when
 the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But
 then, if the browser was opened while offline and we then connect to a
 network (and we are in bridge mode), then the NM hook will want to start
 the already running browser with the envvar that will show Tor
 Launcher's network settings and then exit the browser. How can all this
 be achieved without creating a complete mess?

OK. From the top of my head, two vaguely related notes:

* We'll want to run Tor Launcher *only* when the user has ticked
  a checkbox in the Greeter, right? Or do we run it in all cases?

* Note that we don't run the browser by default on network connection.
  See the wrapper in /usr/local/bin/iceweasel.

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
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-20 Thread Mark Smith

On 2/19/14, 2:14 PM, anonym wrote:

It sounds to me like the setting you are talking about does *not* have
any direct effect on Firefox, only on Tor Launcher. To clarify, you are
*not* setting e.g. `network.proxy.socks` (which Firefox itself uses),
instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox
itself doesn't use).

Is this correct? (If so, we're happy -- see the end of this email.)


Yes, I think that is correct.  It is a little difficult for Kathy and me 
to separate the two things because until now we have never thought about 
Tor Launcher running in a profile separate from the one where browsing 
will be done.



This is also why we need to start tor
with DisableNetwork=1 when the use default bridges option is enabled:
  so we can update the bridge configuration before tor starts its
bootstrap process.  See:
   https://trac.torproject.org/projects/tor/ticket/10418


[Note: The reason I'm continuing this part of the discussion is not
because I think it will be especially relevant for Tails directly but it
does help me to better understand where Tor Launcher is going in the
future so I can assess if Tor Launcher in Tails is a long-term
solution or not. It may be that I'm just wasting everyone's time here
being confused and speculating about a future change that I don't know
the exact details of, so we may want to just drop it. :)]

Will anything change with Tor Launcher's current design of immediately
starting Tor and configure it to use the previous settings on all runs
after the very first? Otherwise I don't see the relevance of setting
`DisableNetwork=1` beyond the first run; if the use default bridges
option was chosen on first run, bridges will be written into torrc,
which makes `DisableNetwork=1` redundant.

However, if the design does change, e.g. that you show the network
settings on *each* run, with `DisableNetwork=1` set (highly relevant now
since the user may have chosen connect in the clear in the previous
run), then I don't see why you thought this new behaviour would be
incompatible earlier patch
(0002-Always-open-network-settings-if-DisableNetwork-is-se.patch).


I tried to explain this in my last message but possibly I wasn't clear. 
 We do not plan to show the network configuration wizard each time. 
The issue is that Tor Launcher needs to reconfigure the default bridges 
each time tor starts up.  This is necessary because the default bridge 
addresses may change when TBB is upgraded (the addresses are stored as a 
series of hidden Tor Launcher preferences).



I am not sure if the concept of default bridges is something you will
want for Tails in the future or not.


It doubt it. In Tails we care about the bridges being non-public to
support the hide that you are using Tor use case as best we can. If we
expose our users to a convenient option to use a public list of default
bridges, then we put the users of that use case at risk. Therefore it'd
be great if whatever GUI control you'll use for this option will be
hidden (or at least disabled/greyed out) if the pre-supplied list of
default bridges is empty/non-existent.


That is already how things work.  The option to use default bridges is 
only displayed if the necessary preferences are present.



Another small consideration is that we (TBB developers) will probably
not test Tor Launcher as a standalone XUL application because we will
not be using it that way... so it is possible we will accidentally break
something that is needed in that mode.  Of course we will try not to do so.


As long as Tor Launcher more or less sticks with its current design, and
continues to keep away from stuff directly affecting Firefox (leaving
that to Tor Button) and only do stuff related to
starting/configuring/monitoring Tor processes, I expect very little
problems due to your upstream changes.

Does this look like your plan for the foreseeable future?


Yes, although I leave it to Mike (in his role as TBB chief architect) to 
comment as well.  Requirements may dictate a future change in direction, 
but for now the plan is for Torbutton and Tor Launcher to work together 
but maintain their distinct roles.


-Mark
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-20 Thread anonym
20/02/14 10:57, intrigeri wrote:
 anonym wrote (19 Feb 2014 19:14:40 GMT) :
 The primary profile can be used offline too. For instance, if a link in
 some GNOME notification is clicked, Iceweasel using the primary profile
 will be opened. We'd some how need to make Tor Launcher *not* run when
 the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But
 then, if the browser was opened while offline and we then connect to a
 network (and we are in bridge mode), then the NM hook will want to start
 the already running browser with the envvar that will show Tor
 Launcher's network settings and then exit the browser. How can all this
 be achieved without creating a complete mess?
 
 OK. From the top of my head, two vaguely related notes:
 
 * We'll want to run Tor Launcher *only* when the user has ticked
   a checkbox in the Greeter, right? Or do we run it in all cases?

It's been my assumption that we'll stick with the original checkbox in
the Greeter plan.

Of course, we could instead run it for each new connection (and always
make sure `DisableNetwork` is set in torrc before we start Tor in the NM
hook). It would actually make it harder for users that need bridge mode
to make a mistake by accidentally logging in without checking the box
(if there's a wired connection they're screwed by NM automatically
connecting). When it comes to user experience, though, I'm not sure
non-bridge users will be happy with this new, frequent pop-up that they
have to deal with. In fact, it will train them to always click Connect
so that they will screw themselves the time they actually need to add
bridges. I think I prefer our original plan. Other opinions?

 * Note that we don't run the browser by default on network connection.
   See the wrapper in /usr/local/bin/iceweasel.

Yes, I'm aware of this change. I suppose this also would have
complicated things if we'd gone with the exit the browser approach.
Was there anything else you had in mind by pointing this out, in case it
got lost on me?

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-20 Thread anonym
20/02/14 16:35, Mark Smith wrote:
 On 2/19/14, 2:14 PM, anonym wrote:
 It sounds to me like the setting you are talking about does *not* have
 any direct effect on Firefox, only on Tor Launcher. To clarify, you are
 *not* setting e.g. `network.proxy.socks` (which Firefox itself uses),
 instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox
 itself doesn't use).

 Is this correct? (If so, we're happy -- see the end of this email.)
 
 Yes, I think that is correct.

Excellent!

 It is a little difficult for Kathy and me
 to separate the two things because until now we have never thought about
 Tor Launcher running in a profile separate from the one where browsing
 will be done.

Right but given the answer you gave me in the end of your email it
should be pretty straight-forward. The standalone profile will only
include whatever default settings are present in the Tor Launcher
package itself, and the ones Tor Launcher sets during its operation
(i.e. it will *not* include the TBB's settings *nor* stuff Firefox sets
during its operation). However, since those are the settings you care
about (currently, at least) you can reason about the standalone version
in exactly the same way as when it's run as a Firefox extension. It's
only when you use settings that are not exclusive to Tor Launcher that
things may get problematic.

 This is also why we need to start tor
 with DisableNetwork=1 when the use default bridges option is enabled:
   so we can update the bridge configuration before tor starts its
 bootstrap process.  See:
https://trac.torproject.org/projects/tor/ticket/10418
[...]
 Will anything change with Tor Launcher's current design of immediately
 starting Tor and configure it to use the previous settings on all runs
 after the very first?
[...]
 I tried to explain this in my last message but possibly I wasn't clear.
  We do not plan to show the network configuration wizard each time. The
 issue is that Tor Launcher needs to reconfigure the default bridges each
 time tor starts up.  This is necessary because the default bridge
 addresses may change when TBB is upgraded (the addresses are stored as a
 series of hidden Tor Launcher preferences).

Ah, now I get it. Thanks for you patience! :)

 I am not sure if the concept of default bridges is something you will
 want for Tails in the future or not.

 It doubt it. In Tails we care about the bridges being non-public to
 support the hide that you are using Tor use case as best we can. If we
 expose our users to a convenient option to use a public list of default
 bridges, then we put the users of that use case at risk. Therefore it'd
 be great if whatever GUI control you'll use for this option will be
 hidden (or at least disabled/greyed out) if the pre-supplied list of
 default bridges is empty/non-existent.
 
 That is already how things work.  The option to use default bridges is
 only displayed if the necessary preferences are present.

Great!

 Another small consideration is that we (TBB developers) will probably
 not test Tor Launcher as a standalone XUL application because we will
 not be using it that way... so it is possible we will accidentally break
 something that is needed in that mode.  Of course we will try not to
 do so.

 As long as Tor Launcher more or less sticks with its current design, and
 continues to keep away from stuff directly affecting Firefox (leaving
 that to Tor Button) and only do stuff related to
 starting/configuring/monitoring Tor processes, I expect very little
 problems due to your upstream changes.

 Does this look like your plan for the foreseeable future?
 
 Yes, although I leave it to Mike (in his role as TBB chief architect) to
 comment as well.  Requirements may dictate a future change in direction,
 but for now the plan is for Torbutton and Tor Launcher to work together
 but maintain their distinct roles.

This is reassuring enough and welcome news! Now I truly feel confident
that the standalone XUL approach is a perfect fit for Tails for now.

Any ETA on when my patches can be reviewed? We plan to incorporate Tor
Launcher in the next Tails release (0.23) which has its feature freeze
on the 5th of March. If this could be upstreamed at the very latest the
day before that (so there's time for us to package and test it), we'd be
very happy. Of course, for that to happen the review would probably have
to happen quite soon as I'm sure there'll be some back-and-forth with me
revising the patches.

In the worst case, if it's not upstreamed in time for our freeze, we can
of course ship a patched Tor Launcher for this release and have them
upstreamed for the next release or so, so it's not an imminent, hard
requirement.

Also, see attached files for a new patch set. From now on I won't rebase
the patches any more in order to ease your review process. For the
record, I've tested the patched Tor Launcher successfully both as a
Firefox extension, and a standalone XUL application.

Cheers!

From 

Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-19 Thread Mark Smith

On 2/18/14, 1:08 PM, anonym wrote:

Ah, now I get it, thanks! I must admit that even though I read this I
completely missed the actual point. I still thought we were going to try
the standalone XUL approach, and that's what I did (as indicated by the
new subject line in this thread). Sorry for the confusion.

Luckily I think this misunderstanding may be good in the end as it made
me investigate the standalone approach:


TL;DR: the standalone XUL application idea (whose difficulty has not
been asserted) was superseded by the exit the browser right after the
Tor Lancher config screens, if a given envvar is set one, since it
seemed way easier, and good enough for us.


TL;DR: I think the standalone approach is better, and like to switch it.


The main reason we proposed the exit browser after configuration 
solution was because we were not sure how much work it would be to 
create a standalone XUL app.  But you have already done the work.  The 
downside I see is that you will need to ship (and maintain) XULRunner. 
But maybe you already need to do that for other reasons.




Some notes on exit the browser vs standalone XUL approaches:
...

* When it comes to upstream maintenance, the exit the browser and
   standalone XUL approaches are pretty similar, at least as long as
   Tor Launcher only deals with starting/configuring Tor, and do not
   interact with Firefox (e.g. add something to `prefs.js` that's
   relevant for Firefox, or whatever). Tor Launcher maintainers, is
   this the plan for the foreseeable future?


To support a pluggable transports (PT) Tor Browser bundle, we have added 
an option to configure a default set of bridges.  That option requires 
setting preferences inside the browser so that Tor Launcher knows to 
reconfigure the default bridges each time the browser is started (we 
need to set the bridge configuration each time because they originate 
from hidden Tor Launcher preferences which may be updated when a new 
version of TBB is installed).  This is also why we need to start tor 
with DisableNetwork=1 when the use default bridges option is enabled: 
 so we can update the bridge configuration before tor starts its 
bootstrap process.  See:

  https://trac.torproject.org/projects/tor/ticket/10418
I am not sure if the concept of default bridges is something you will 
want for Tails in the future or not.


Another small consideration is that we (TBB developers) will probably 
not test Tor Launcher as a standalone XUL application because we will 
not be using it that way... so it is possible we will accidentally break 
something that is needed in that mode.  Of course we will try not to do so.


--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-19 Thread intrigeri
Hi,

anonym wrote (18 Feb 2014 18:08:01 GMT) :
 TL;DR: I think the standalone approach is better, and like to switch it.

After reading the following (but not the last email from Mark yet),
I now concur.

 Some notes on exit the browser vs standalone XUL approaches:
[...]
 * The way I understand the exit the browser approach is that we'd
   have Tor Launcher installed as an Iceweasel extension. However,
   having it intalled in our default Iceweasel profile will not be
   pretty so we'll have to generate yet another profile, with the added
   complexity and maintaince burden of that.

I don't see the downsides of having Tor Launcher installed as an
extension in our primary browsing profiles. I guess that's not
a decisive point anyway.

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
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-19 Thread anonym
19/02/14 15:14, Mark Smith wrote:
 On 2/18/14, 1:08 PM, anonym wrote:
 TL;DR: I think the standalone approach is better, and like to switch it.
 
 The main reason we proposed the exit browser after configuration
 solution was because we were not sure how much work it would be to
 create a standalone XUL app.

Completely understandable. I certainly thought the standalone approach
would be much more problematic than it turned out to be. :)

[...]
 Some notes on exit the browser vs standalone XUL approaches:
 ...

 * When it comes to upstream maintenance, the exit the browser and
standalone XUL approaches are pretty similar, at least as long as
Tor Launcher only deals with starting/configuring Tor, and do not
interact with Firefox (e.g. add something to `prefs.js` that's
relevant for Firefox, or whatever). Tor Launcher maintainers, is
this the plan for the foreseeable future?
 
 To support a pluggable transports (PT) Tor Browser bundle, we have added
 an option to configure a default set of bridges.  That option requires
 setting preferences inside the browser so that Tor Launcher knows to
 reconfigure the default bridges each time the browser is started (we
 need to set the bridge configuration each time because they originate
 from hidden Tor Launcher preferences which may be updated when a new
 version of TBB is installed).

It sounds to me like the setting you are talking about does *not* have
any direct effect on Firefox, only on Tor Launcher. To clarify, you are
*not* setting e.g. `network.proxy.socks` (which Firefox itself uses),
instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox
itself doesn't use).

Is this correct? (If so, we're happy -- see the end of this email.)

 This is also why we need to start tor
 with DisableNetwork=1 when the use default bridges option is enabled:
  so we can update the bridge configuration before tor starts its
 bootstrap process.  See:
   https://trac.torproject.org/projects/tor/ticket/10418

[Note: The reason I'm continuing this part of the discussion is not
because I think it will be especially relevant for Tails directly but it
does help me to better understand where Tor Launcher is going in the
future so I can assess if Tor Launcher in Tails is a long-term
solution or not. It may be that I'm just wasting everyone's time here
being confused and speculating about a future change that I don't know
the exact details of, so we may want to just drop it. :)]

Will anything change with Tor Launcher's current design of immediately
starting Tor and configure it to use the previous settings on all runs
after the very first? Otherwise I don't see the relevance of setting
`DisableNetwork=1` beyond the first run; if the use default bridges
option was chosen on first run, bridges will be written into torrc,
which makes `DisableNetwork=1` redundant.

However, if the design does change, e.g. that you show the network
settings on *each* run, with `DisableNetwork=1` set (highly relevant now
since the user may have chosen connect in the clear in the previous
run), then I don't see why you thought this new behaviour would be
incompatible earlier patch
(0002-Always-open-network-settings-if-DisableNetwork-is-se.patch).

 I am not sure if the concept of default bridges is something you will
 want for Tails in the future or not.

It doubt it. In Tails we care about the bridges being non-public to
support the hide that you are using Tor use case as best we can. If we
expose our users to a convenient option to use a public list of default
bridges, then we put the users of that use case at risk. Therefore it'd
be great if whatever GUI control you'll use for this option will be
hidden (or at least disabled/greyed out) if the pre-supplied list of
default bridges is empty/non-existent.

 Another small consideration is that we (TBB developers) will probably
 not test Tor Launcher as a standalone XUL application because we will
 not be using it that way... so it is possible we will accidentally break
 something that is needed in that mode.  Of course we will try not to do so.

As long as Tor Launcher more or less sticks with its current design, and
continues to keep away from stuff directly affecting Firefox (leaving
that to Tor Button) and only do stuff related to
starting/configuring/monitoring Tor processes, I expect very little
problems due to your upstream changes.

Does this look like your plan for the foreseeable future?

[Sorry for essentially repeating my question from earlier, but a
straight answer to this question would help immensely for assessing the
viability of Tails' new plan w.r.t. Tor Launcher.]

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-19 Thread anonym
19/02/14 15:40, intrigeri wrote:
 Hi,
 
 anonym wrote (18 Feb 2014 18:08:01 GMT) :
 TL;DR: I think the standalone approach is better, and like to switch it.
 
 After reading the following (but not the last email from Mark yet),
 I now concur.

Excellent! Then I'll proceed on this path.

To be able to work on this more efficiently (well, faster feedback you
all) I think I'll start with a quick-and-dirty POC branch in Tails where
I'll just include Tor Launcher via config/chroot_local-includes to avoid
the packaging (that part will be nuked from the history before merging).
This way I can work on the Tails integration and Debian packaging of Tor
Launcher (which I may ask you about some best practices) in parallel.

 Some notes on exit the browser vs standalone XUL approaches:
 [...]
 * The way I understand the exit the browser approach is that we'd
   have Tor Launcher installed as an Iceweasel extension. However,
   having it intalled in our default Iceweasel profile will not be
   pretty so we'll have to generate yet another profile, with the added
   complexity and maintaince burden of that.
 
 I don't see the downsides of having Tor Launcher installed as an
 extension in our primary browsing profiles. I guess that's not
 a decisive point anyway.

For whatever it's worth (since you already seem to be convinced for
other reasons) here's one example on why I think it's messy, and I think
it suggests that there are deeper reasons why the browser and Tor
controller should be separate among our assumptions, and in Tails' design:

The primary profile can be used offline too. For instance, if a link in
some GNOME notification is clicked, Iceweasel using the primary profile
will be opened. We'd some how need to make Tor Launcher *not* run when
the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But
then, if the browser was opened while offline and we then connect to a
network (and we are in bridge mode), then the NM hook will want to start
the already running browser with the envvar that will show Tor
Launcher's network settings and then exit the browser. How can all this
be achieved without creating a complete mess?

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]

2014-02-18 Thread intrigeri
Hi,

anonym wrote (18 Feb 2014 01:07:07 GMT) :
 Sorry, but I don't understand the exit the browser [...] part. In the
 way we intend to use the Tor Launcher in Tails there will be no browser
 as it will run as a standalone XUL application.

There seems to be some amount of misunderstanding here. As suggested
earlier privately, you really want to read the beginning of this
thread.

TL;DR: the standalone XUL application idea (whose difficulty has not
been asserted) was superseded by the exit the browser right after the
Tor Lancher config screens, if a given envvar is set one, since it
seemed way easier, and good enough for us.

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
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails

2014-02-18 Thread anonym
18/02/14 10:56, intrigeri wrote:
 Hi,
 
 anonym wrote (18 Feb 2014 01:07:07 GMT) :
 Sorry, but I don't understand the exit the browser [...] part. In the
 way we intend to use the Tor Launcher in Tails there will be no browser
 as it will run as a standalone XUL application.
 
 There seems to be some amount of misunderstanding here. As suggested
 earlier privately, you really want to read the beginning of this
 thread.

I assume the following quote is what you are talking about:

14/01/14 17:09, Kathleen Brade wrote (in email with Message-ID
52d5614d.3090...@pearlcrescent.com):
 Here is another idea: What if Tor Launcher presented its initial
 configuration dialogs and then exited after the user clicked
 Connect?

Ah, now I get it, thanks! I must admit that even though I read this I
completely missed the actual point. I still thought we were going to try
the standalone XUL approach, and that's what I did (as indicated by the
new subject line in this thread). Sorry for the confusion.

Luckily I think this misunderstanding may be good in the end as it made
me investigate the standalone approach:

 TL;DR: the standalone XUL application idea (whose difficulty has not
 been asserted) was superseded by the exit the browser right after the
 Tor Lancher config screens, if a given envvar is set one, since it
 seemed way easier, and good enough for us.

TL;DR: I think the standalone approach is better, and like to switch it.

Some notes on exit the browser vs standalone XUL approaches:

* Just to be clear: the code needed for the don't start, only
  configure Tor use case is completely independent either approach.

* The *only* thing required to run Tor Launcher as a standalone XUL
  application is an application.ini and the correct invocation of
  xulrunner. In particular, no code changes are required inside Tor
  Launcher's logic.

* At least the previous point is true for the Tails use case. To make
  standalone Tor Launcher support *starting* *and* *owning* the Tor
  process as well (i.e. without `TOR_CONFIGURE_ONLY=1`), I think some
  more work is needed, since owning the Tor process means that it'll
  terminate when Tor Launcher closes (i.e. immediately after it has
  configured Tor in the standalone case). Since we don't need it, I
  guess we wouldn't care, but fixing it should be pretty simple for
  those that do.

* Actually the exit the browser approach will require one piece of
  extra code, namely to exit the browser at the appropriate time if
  `TOR_CONFIGURE_ONLY=1`. Actually, overloading that option with this
  additional behaviour is pretty ugly and highly Tails-specific
  (non-Tails users may want to set that option to configure their
  system-wide Tor *and* have a browser afterwards). It'd make more
  sense with yet another option, like `NO_BROWSER=1` or something
  similarly weird. Otherwise we might just as well bake all
  Tails-specific stuff into a `RUNNING_IN_TAILS=1`.

* When it comes to upstream maintenance, the exit the browser and
  standalone XUL approaches are pretty similar, at least as long as
  Tor Launcher only deals with starting/configuring Tor, and do not
  interact with Firefox (e.g. add something to `prefs.js` that's
  relevant for Firefox, or whatever). Tor Launcher maintainers, is
  this the plan for the foreseeable future?

* When it comes to Debian packaging, both are trivial to package. I
  suppose that, if anything, Debian is more likely to ever package the
  Firefox extension, but even that seems unlikely to me at this
  point. Hence I guess we (Tails) will be effectively responsible for
  it, so there's nothing in favour of either approach here then.

* The way I understand the exit the browser approach is that we'd
  have Tor Launcher installed as an Iceweasel extension. However,
  having it intalled in our default Iceweasel profile will not be
  pretty so we'll have to generate yet another profile, with the added
  complexity and maintaince burden of that.

* Relating to the previous point, nothing extra is required for the
  standalone Tor Launcher to run it as a separate profile (starting it
  will automatically create a profile in `.torproject/tor-launcher`).

Conclusion: if my analysis above is correct, and my assertions/questions
are the way I expect, then the standalone XUL approach is in fact
cleaner, simpler, more flexible, more portable (outside the Tails
context) and more maintainable than the exit the browser one. I can
see no disadvantage with it, now that the research has been done.
Therefore I think we should change the old plan and go with the
standalone XUL application approach instead.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]

2014-02-17 Thread anonym
11/02/14 20:17, Mark Smith wrote:
 On 2/11/14, 11:23 AM, anonym wrote:
 11/02/14 02:37, anonym wrote:
 # Tor Launcher in Tails

 All in all, not much is necessary to make Tor Launcher able to *only*
 control (as opposed to own, i.e. control + Tor is started by the
 controller, and Tor exits with the controller) a system-wide Tor
 instance:

  src/application.ini |   13 +
  src/chrome/locale/en/torlauncher.properties |1 +
  src/components/tl-process.js|   32
 ++--
  3 files changed, 40 insertions(+), 6 deletions(-)
 
 Thanks for working on this.

Thank you for providing an alternative to the now-abandoned Vidalia! And
sorry for thinking that Mark was a mistaken Mike in my first post in
this thread -- I just didn't see any mention of Mark in the Git history. :S

 See attached files for a POC.

 Essentially what my changes do is to separate the starting Tor and
 control Tor code, and skip the former if
 `extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH`
 is `1`. The old behaviour of those options is to do absolutely nothing
 w.r.t. starting/communicating with Tor, so I suppose they were only
 used for debugging. IMHO this new behaviour is better than introducing
 `TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still
 needed we can instead introduce a new option, like `IGNORE_TOR` or
 whatever.
 
 I think we need to preserve the existing behavior.  There are people who
 are using TOR_SKIP_LAUNCH and the extensions.torlauncher.start_tor
 preference, and I don't think we should break things for them.

What use cases are they trying to achieve by using Tor Launcher like
that? Is it for just starting the browser in the TBB by making Tor
Launcher do (more or less) nothing?

 We picked the name TOR_CONFIGURE_ONLY for the new behavior because we
 thought Tor Launcher would need to exit the browser after the settings
 wizard finished.  If that is not the case, a name like TOR_CONTROL_ONLY
 would be better.

Sorry, but I don't understand the exit the browser [...] part. In the
way we intend to use the Tor Launcher in Tails there will be no browser
as it will run as a standalone XUL application.

 ...
 We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment
 variables by instead using the corresponding settings in `prefs.js`,
 but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE`
 although a `extensions.torlauncher.control_cookie_path` should be easy
 to add. This is only relevant if we prefer to use proper settings
 instead of environment variables.
 
 Is there an advantage to avoiding environment variables?  They are
 already implemented and they work ;)

Not really. In fact it may just increase our maintenance burden since
keeping our own `prefs.js` will also require us to keep it in-sync with
your upstream changes.

 # Problem: settings persistence with a system-wide Tor setup

 In Vidalia, settings configured by the user (like `bridge ...`,
 `HTTPProxy ...`, etc) persist by being saved in Vidalia's config
 (well, I think Vidalia first tries to write the settings to torrc via
 `SAVECONF` and falls back to this if it fails, which it does in
 Tails), and they are restored as soon as Vidalia establishes control
 of Tor. In Tails' current, experimental bridge mode, the obvious race
 condition is dealt with by adding an invalid bridge, which effectively
 emulated the `DisableNetwork` option (in combination with our custom
 Vidalia patches).

 In Tor Launcher, settings configured by the user are saved directly in
 torrc (via `SAVECONF`), which doesn't fit very well in the Tails
 context. With my changes applied, the changes are simply lost whenever
 Tor restarts, which will happened for a number of reasons, e.g. for
 each new network connection.

 This is a fundamental issue that my changes doesn't currently deal
 with, and I'm unsure how to proceed. Below are some thoughts on our
 options:
 ...
 
 I admit that I do not understand everything about the Tails
 architecture.  It sounds like users can write to the browser's (or
 XULRunner's) prefs.js but not to torrc?  Is this restriction present to
 improve security or for a different reason?

In order to lessen the damage possible by compromising certain users we
do (at least) the following:

* The system-wide Tor process runs under the `debian-tor` user.

* The torrc used by Tor is only writeable by `root`.

* Tor controllers are run under yet another user (currently called
  `vidalia` since that's our current controller).

 When we designed Tor Launcher, we tried hard to only have Tor settings
 stored in one place (torrc).  I don't like the idea of caching all of
 the Tor settings as Tor Launcher preferences, but maybe that is the only
 viable solution given your architecture.

I understand this, and I think the Vidalia developers suffered a bit
from supporting that.

Something we Tails developers may want 

[Tails-dev] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]

2014-02-11 Thread anonym
11/02/14 02:37, anonym wrote:
 10/02/14 23:01, intrigeri wrote:
 Hi,

 Kathleen Brade wrote (10 Feb 2014 15:17:23 GMT) :
 On 2/9/14, 10:21 AM, intrigeri wrote:
 So, now that we agree on something that would satisfy our needs,
 what's the plan? Has anyone allocated time to implement this?
 If someone is planning to do it, is there any ETA?

 I think this is easy to add to Tor Launcher; Mark and I can probably
 do it in the next couple of days.

 Awesome!

 anonym, given you'll be working on bridges support soon, may you
 please have a look at this idea ASAP, and evaluate how well it could
 replace our initial plan? From my PoV it looks just great, compared to
 the initial setup being done in Vidalia, but I might have
 missed something.
 
 I did some research into this earlier today and have a working,
 standalone POC that can deal with system-wide Tor instances (but it is
 incomplete in some ways that require further discussion). I'm way too
 tired at the moment to do the write up, but I will do it after I've got
 some sleep. In other words, Mark (Mike?), Kathleen and others: please
 don't duplicate work by looking into this until I've posted my results.

Here's my results:

# Tor Launcher in Tails

All in all, not much is necessary to make Tor Launcher able to *only*
control (as opposed to own, i.e. control + Tor is started by the
controller, and Tor exits with the controller) a system-wide Tor
instance:

src/application.ini |   13 +
src/chrome/locale/en/torlauncher.properties |1 +
src/components/tl-process.js|   32
++--
3 files changed, 40 insertions(+), 6 deletions(-)

See attached files for a POC.

Essentially what my changes do is to separate the starting Tor and
control Tor code, and skip the former if
`extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH`
is `1`. The old behaviour of those options is to do absolutely nothing
w.r.t. starting/communicating with Tor, so I suppose they were only
used for debugging. IMHO this new behaviour is better than introducing
`TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still
needed we can instead introduce a new option, like `IGNORE_TOR` or
whatever.

# How to start as a stand-alone application in Tails

To test it, add a firewall exception for port 9051 to the `vidalia`
user in `/etc/ferm/ferm.conf`, and run:

git clone https://git.torproject.org/tor-launcher.git
cd tor-launcher
# apply attached patches
sudo -u vidalia TOR_SKIP_LAUNCH=1 TOR_CONTROL_PORT=9051
TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control.authcookie
xulrunner-17.0 src/application.ini -purgecaches

For the bridge mode behaviour, set `DisableNetwork 1` in torrc first.

(The `-purgecaches` is useful for clearing the XUL runner cache;
otherwise ignore changes made to the source files (at least the `.js`
files) are ignored after the first run. In other words, this is only
relevant for development and can otherwise be skipped.)

We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment
variables by instead using the corresponding settings in `prefs.js`,
but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE`
although a `extensions.torlauncher.control_cookie_path` should be easy
to add. This is only relevant if we prefer to use proper settings
instead of environment variables.

# Problem: settings persistence with a system-wide Tor setup

In Vidalia, settings configured by the user (like `bridge ...`,
`HTTPProxy ...`, etc) persist by being saved in Vidalia's config
(well, I think Vidalia first tries to write the settings to torrc via
`SAVECONF` and falls back to this if it fails, which it does in
Tails), and they are restored as soon as Vidalia establishes control
of Tor. In Tails' current, experimental bridge mode, the obvious race
condition is dealt with by adding an invalid bridge, which effectively
emulated the `DisableNetwork` option (in combination with our custom
Vidalia patches).

In Tor Launcher, settings configured by the user are saved directly in
torrc (via `SAVECONF`), which doesn't fit very well in the Tails
context. With my changes applied, the changes are simply lost whenever
Tor restarts, which will happened for a number of reasons, e.g. for
each new network connection.

This is a fundamental issue that my changes doesn't currently deal
with, and I'm unsure how to proceed. Below are some thoughts on our
options:

* No settings persistence for system-wide Tor instances: While simple
  to implement, it's inconsistent with how it works compared to when
  Tor Launcher starts Tor, which may confuse users familiar with
  TBB. And it's annoying; all bridges have to be re-entered each time
  the wireless dies, etc. Also it's inconsistent with how it works in
  Vidalia, for whatever that's worth.

* Vidalia-like settings persistence: I suppose we could save the
  settings as `extensions.torlauncher.torconf_httpproxy = 

Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]

2014-02-11 Thread Mark Smith

On 2/11/14, 11:23 AM, anonym wrote:

11/02/14 02:37, anonym wrote:
# Tor Launcher in Tails

All in all, not much is necessary to make Tor Launcher able to *only*
control (as opposed to own, i.e. control + Tor is started by the
controller, and Tor exits with the controller) a system-wide Tor
instance:

 src/application.ini |   13 +
 src/chrome/locale/en/torlauncher.properties |1 +
 src/components/tl-process.js|   32
++--
 3 files changed, 40 insertions(+), 6 deletions(-)


Thanks for working on this.



See attached files for a POC.

Essentially what my changes do is to separate the starting Tor and
control Tor code, and skip the former if
`extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH`
is `1`. The old behaviour of those options is to do absolutely nothing
w.r.t. starting/communicating with Tor, so I suppose they were only
used for debugging. IMHO this new behaviour is better than introducing
`TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still
needed we can instead introduce a new option, like `IGNORE_TOR` or
whatever.


I think we need to preserve the existing behavior.  There are people who 
are using TOR_SKIP_LAUNCH and the extensions.torlauncher.start_tor 
preference, and I don't think we should break things for them.


We picked the name TOR_CONFIGURE_ONLY for the new behavior because we 
thought Tor Launcher would need to exit the browser after the settings 
wizard finished.  If that is not the case, a name like TOR_CONTROL_ONLY 
would be better.




...
We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment
variables by instead using the corresponding settings in `prefs.js`,
but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE`
although a `extensions.torlauncher.control_cookie_path` should be easy
to add. This is only relevant if we prefer to use proper settings
instead of environment variables.


Is there an advantage to avoiding environment variables?  They are 
already implemented and they work ;)




# Problem: settings persistence with a system-wide Tor setup

In Vidalia, settings configured by the user (like `bridge ...`,
`HTTPProxy ...`, etc) persist by being saved in Vidalia's config
(well, I think Vidalia first tries to write the settings to torrc via
`SAVECONF` and falls back to this if it fails, which it does in
Tails), and they are restored as soon as Vidalia establishes control
of Tor. In Tails' current, experimental bridge mode, the obvious race
condition is dealt with by adding an invalid bridge, which effectively
emulated the `DisableNetwork` option (in combination with our custom
Vidalia patches).

In Tor Launcher, settings configured by the user are saved directly in
torrc (via `SAVECONF`), which doesn't fit very well in the Tails
context. With my changes applied, the changes are simply lost whenever
Tor restarts, which will happened for a number of reasons, e.g. for
each new network connection.

This is a fundamental issue that my changes doesn't currently deal
with, and I'm unsure how to proceed. Below are some thoughts on our
options:
...


I admit that I do not understand everything about the Tails 
architecture.  It sounds like users can write to the browser's (or 
XULRunner's) prefs.js but not to torrc?  Is this restriction present to 
improve security or for a different reason?


When we designed Tor Launcher, we tried hard to only have Tor settings 
stored in one place (torrc).  I don't like the idea of caching all of 
the Tor settings as Tor Launcher preferences, but maybe that is the only 
viable solution given your architecture.



...
If we can agree on what the right thing to do with all this is, and I
haven't missed anything big, I feel confident that we can drop Vidalia
and have bridge mode implemented using Tor Launcher in Tails 0.23.


Kathy and I will need to review your patches in more detail, but one 
comment is that I don't think Tor Launcher should open the network 
settings wizard whenever DisableNetwork=1.  In fact, to support PTs we 
are adding a Use Default Bridges option which will require that Tor 
Launcher always start Tor with DisableNetwork=1 (so that the correct 
bridge configuration can be set before Tor touches the network).  Can 
you instead ensure that the extensions.torlauncher.prompt_at_startup 
pref is set to 'true' before starting Tor Launcher?


--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev