[tor-dev] Default parsing order of config files in Debain tor package

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello, Tor developers!

With the implementation of torrc.d, there will be at least two Tor
config files and one Tor config directory by default in Debian tor
package. However, I am not able to find the documents on what the
parsing order Tor follows.

My guess is that:
1. /usr/share/tor/tor-service-defaults-torrc is parsed first
2. /etc/torrc.d is parsed next (in lexical order)
3. /etc/torrc is parsed at last
4. and the lines in config files parsed later will overwrite similar
lines in config files that are parsed earlier

Could anyone familiar with the problem help me please? This will be
really helpful to my future work and I really appreciate your help!

Thank you very much!

Best,
iry
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZWPgFAAoJEKFLTbxtzdU8HpoP/3dz869rQmlAMC4v/2UAO0F+
hPtC/L27ILeICraQRc2sJOsf7FTueKD/a6GadUbCbWBwWyyzdBXotqADnmJdvNnm
hSgkE1mYz27+eI2NUd7UpHs+NrP7FXdjufGkHxZfJPrhTbGKPCC66HouT+T1vdh5
PTRBjc6M/+C2yRuteGRcAW6Be3NJ+3HRuFC5THJd6b+p0WmP+OYXdVlq7cXuY3zj
ffaXvX7WGOH2J+ALIaspc0wjLiieUCq5wrO7REkeUM0TuqjhWWGBhANqVM1Qrfs+
0jWPRklFq/7BkfySUZA88H6D5pkpBX3eVDsUlduxvoSS/F8ksWzAIdMMFaz9a7tR
GpCEBBmbJIN3d4ApF78h//Y9XkaBsAotf40YEC4uZ4h3iW4rlyojWuU7N78A36PL
MJ0IdUm52hWy7ySRDFi9lr7y1xtGQ9qO1gAYCq7D+qeKte+E7UO/QKZjOkAMBBir
hxLimroNtL708rcDzLegstWt5Rpf2iJOYP1wOYnAeYfkSeXXW5KQBDJEd1botJg6
YRa69iICoLBNY+4z6i3t5lVlMolqPyAAwEfA1j4yXBrtBed8ISKx4V44y5JeGnZ2
SjMfHM6XJB95Bu8sWVQc1dQ+eBBiFYHbP4s4n1+jsTbmImg2bc+LauxChwRmAHek
o9KiSasLITPC7zIv1m2o
=KrAy
-END PGP SIGNATURE-


0x6DCDD53C.asc
Description: application/pgp-keys


0x6DCDD53C.asc.sig
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Default parsing order of config files in Debain tor package

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Daniel!

Thank you so much for your immediate, detailed and informative answer.
I really like the example you offered as it clearly illustrates the
parsing order.

Your answer is very helpful for me to decide where I should place the
%include line and Tor config files. I really appreciate your help.

Best,
iry

Daniel:
> The precedence for tor options is the following (1 overrides 2,
> etc...):
> 
> 1. Command line options. 2. Configuration file options (your
> /etc/torrc). 3. Defaults file options (your
> /usr/share/tor/tor-service-defaults-torrc).
> 
> In the same file, options that appear later override earlier
> options.
> 
> Currently, there is no torrc.d directory created when you install
> the tor package. However, you can use a %include in the
> configuration file or in the defaults file. When you insert a
> %include in a file, it works as if all the options for the included
> file or folder were written on the line of the %include. If you're
> including a folder, the files will be processed in lexicographic
> order and files starting with a dot will be ignored.
> 
> Here is an example:
> 
> tor-service-defaults-torrc: SomeOption 0 %include /etc/tor/torrc.d/
> # SomeOption is now 2 SomeOption 3 # SomeOption is now 3
> 
> /etc/tor/torrc.d/01_one: SomeOption 1
> 
> /etc/tor/torrc.d/02_two: SomeOption 2
> 
> 
> With this configuration, the value for some option is 3. But we can
> have a torrc with %include too:
> 
> /etc/torrc: SomeOption 4 # SomeOption is now 4 %include
> /etc/tor/foo.torrc # SomeOption is now 5 SomeOption 6 # SomeOption
> is now 6
> 
> /etc/tor/foo.torrc: SomeOption 5
> 
> With both these files, the value for SomeOption is 6.
> 
> There are also different types of options and some can take
> multiple values. For more information see the section "Mid-level
> semantics" on this file:
> https://gitweb.torproject.org/tor.git/tree/doc/torrc_format.txt
> 
> Best regards, Daniel
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZWZ1gAAoJEKFLTbxtzdU84gAQAKVu8UcbYHXIaZ+sUkiENUeW
lSBnvOHeRcIBAOe1LfClgkAFiVWhHwfG2ll7cGDTiMxn7IuDlv+sUFtwpqRVFgYH
kOxJiVS1kORQJ8t8DuXh3rQZTUTKOkhCCepb8maHeCSED0yUGSXs+wzpFMAyKJk+
2B73YR/hQd2XgpZx9LcpfkdznTXF/jpOPZthZWFAkwm1yNAlvwAmfXgADV4lQy5K
RRCwYmAgdSS9OLrDMj0G1lVnvsr7qUgfePzLpp1FBkMf/E8nhL6NBCK+jJc+BA+R
3YKn5pKtJ5/KaAwutQ5nlI3+mdVoDnJI0wWGHxL6ZJPwfCMANqkrbRa8/Wq0i7ZB
u1sG9aWJzTXPaI/OZQ8VE5bvh9mLSfwo0RpzYv8CVsFgu2VnMPk5EW13d33+Dzjz
5GVcA0s0V1AA7uZ/NGUrcUZ/jO+z5Argre7RxkCnAgjItKb2vJK5hGnj7gVQO0il
bcx+e47MyLVNoi7tOaoJmOusEEMQB1wMG6S1Pc+o/apqW6p2VEUKrTh+DSp72+LX
zDPOxAleJjbntXZkGrDO0nay21y1LWYL2bOHpWomjd03f9v6br/n9oofNX6pN7Xn
B9FIOa0PxzCT2BwcROnEDEB9mCHDbIRSEvuwpbbdz3StRW3pLzU1Q2e6WO+eF7dH
OpDeWlO5/Z6IJKV4eesz
=9riT
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Feature Request: please consider ship default, Tor bridges

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Roger:
> On Thu, Aug 17, 2017 at 07:57:53PM +0000, iry wrote:
>> Btw, Collateral Freedom seems to be one of the most effective 
>> ways to circumvent Internet censorship in China. Circumvention 
>> tools that depend on Collateral Freedom usually works fine, 
>> including meek, lantern, psiphon3 etc. Therefore, I see a lot of
>>  potential work which may benefit the Internet freedom in China.
>>  For example: 1. package meek into Debian 2. host (part of the) 
>> BridgeDB mirror on Github or AWS 3. #22402: 
>> https://trac.torproject.org/projects/tor/ticket/22402
> Some hopefully useful thoughts along these lines:
> 

Hi Roger! Thank you for sharing your insights!

> A) Most places around the world that need bridges these days need 
> pluggable transport bridges, not just vanilla bridges. So if we 
> want to bundle bridge addresses, we should bundle PT bridge 
> addresses.
> 

I agree! This also makes me think about a small potential improvement
on the design of BridgeDB web. When users click the big "Just give me
some bridge" on https://bridges.torproject.org/options , they will be
provided with vanilla bridges instead of obfs4 bridges.

However, those users who choose not to use "Advanced Options" are most
likely to be inexperienced and have no idea on what obfd4, PT etc are.
Therefore, is it a good idea to provide obfs4 bridges, rather than
vanilla ones, in "Just give me some bridge" for better usability and
higher success rate?

> B) ...and that means we need to make sure that those PTs are well 
> packaged in Debian too, since the Tor deb by itself would not be 
> able to use them.
> 

Agreed. I can help to report a bug against obfs4proxy on Debian BTS
when the idea is mature.

> C) I wonder if we could use the new %include torrc directive in 
> this situation: https://bugs.torproject.org/1922


I don't have a say on the final decision, but this is also what I am
thinking about:> 3. "Bridge" + plain text which is ready to be
appended to a torrc file
> or to be one of the torrc files in /etc/torrc.d/ (or whatever 
> torrc.d path Debain decides to use)

> That is, when you apt-get install obfs4proxy, is that the right 
> time to populate /etc/torrc.d/obfs4-bridges with some (probably 
> commented out to start) lines that let you use those bridges if
> you want?

How about not commenting out the bridge info as the switch? Instead,
user who would like to use bridge can comment out or add the following
two lines in /etc/tor/torrc:
#UseBridges 1
#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy

I have being considering /etc/torrc.d/ as a place to store all the
available settings and considering /etc/tor/torrc as a panel that let
user decide what they would like to enable and disable. But I am not
sure if this is a good way to think about the relationship between
/etc/tor/torrc and /etc/torrc.d/

One thing I am concerned about is, when applying the method above, how
can user choose different PTs in the future? For example, when meek in
packaged into Debian, the meek package will probably also have a
/etc/torrc.d/meek-bridges file. Can we just choose to use obfs4 or
meek in /etc/tor/torrc by switching between the following two lines?

#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
#ClientTransportPlugin meek exec  /usr/bin/meek-client

(I can test with that, but people who is familiar with the mechanism
behind it can probably answer that.)


Best,
iry
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZmHZUAAoJEKFLTbxtzdU8Y2gP+wfDoSOTprVqe4rByzHVhUup
LXvy4WnfHeUq03t+H8W5QwJCPdsFssFZae/EsfUU5Q490GqhAFryi8rHmOHluSGl
FmX9SIxQXT3RV7iEFN7w4qKqYHLEKrRTklWOLrDauHZe3eJEUyn49VCROtBat88Y
bdnrav4D443fFD/ugk8C3K5u4oNEWgtaq9natsLkPFbXpNcB06gd/S23Vj4VsOP0
+FUmIHmtzzMk0iTAVjGrW8X/z6/lyqk6Nj/lvwfNhdIJ5gbk5F848sl71VBeK3of
Q7rdCjglZ3/tPRfrE+d40cfQWmOpw7doozC7LKdDbxCtx/LJ0WFq2PvwmO+uUFOG
3QMAV0w58JWsUsLW80ifcx7T+0O7QeAMASqWqKva7d1Y2PgqNCJfDJDHOX/KuEy3
TUi8o5WkIUUtyPaMwnYXW9VkaEKIHBXxfjYBwg0llfGU9HKJmTj+yCrMMHB2t0m0
OlZUFx9E7U11mhWzGM64sICHuob8VjwsLgLPMJc1+ocDobo0HrJr1ZtWmMZScp60
SpK35EwU8jKZJTSXtI/SKtDdHGhGmxm4NvLy26TWSqHbEzlcelK+yqkifnLHr3tb
we61NdV2ZA7XCrp+o3Q7NprMjRGtaP1aze2bQTjJfkLDdrShkZFw3/hYk75cRpvk
tkf7Tl4oLtoa5lnNhB/S
=sP5G
-END PGP SIGNATURE-


0x6DCDD53C.asc
Description: application/pgp-keys


0x6DCDD53C.asc.sig
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Problems on torrc.d-style configuration directories

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi teor and Daniel!

Thank you so much for your reply! Your instructions are really helpful
to me.

teor:
> You probably need a %include directive in /etc/tor/torrc.

I tried to add %include directive in /etc/tor/torrc and
/usr/share/tor/tor-service-defaults-torrc separately. And both of them
worked well :)

teor:
> If you get this working, please submit a patch to the Debian bug
> tracker.

No problem! But please forgive my ignorance, could you please explain
a little bit more to me that why I should report it to Debian BTS,
instead of tpo? In other words, what is the relationship between
packages.debian.org and deb.torproject.org?

According to cypherpunks[0]:
> The first released tor version with this feature is 0.3.1.1-alpha. 
> As usual there will be alpha packages on deb.torproject.org
> 
> If you want this feature _now_ you can use the nightly builds: ​
> https://deb.torproject.org/torproject.org/dists/tor-nightly-master-str
etch

However,
> 
the highest tor version in Debian BTS right now is
3.0.8-1.[1], which means the feature has not been included into Debian?

My current thought is deb.torproject.org is the upstream of
packages.debian.org in terms of tor package. So a change made in
deb.torproject.org will be adopted by packages.debian.org after a while.


The following is my testing environment which may be helpful to the
problem:

I tested the torrc.d feature in both Debian 8 and Whonix13(based on
Debian8). Instead of downloading from packages.debian.org, I download
tor from:
> deb http://deb.torproject.org/torproject.org jessie main deb-src
> http://deb.torproject.org/torproject.org jessie main deb
> http://deb.torproject.org/torproject.org tor-nightly-master-jessie 
> main

The Tor version I tested was:
> Tor version 0.3.1.3-alpha-dev (git-a73d0fe9a87df762+b433dff)


Again, thank you very much, teor and Daniel! I really appreciate your
help!

Best,
iry


[0]: https://trac.torproject.org/projects/tor/ticket/1922
[1]: https://packages.debian.org/source/experimental/tor
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZUb3/AAoJEKFLTbxtzdU8jQsP/2B29N3WpkypE7DQ1A2wtjd9
MP3Blz9lbJH8LQJw+juaHhzslokCXwpGJSl7OfyqhRL44VkXnTllfd88HacW5luM
PqZ4OeljB2UYrpDM7TypjdA+RXmSLTKNCmFifCESQPcmsu97qxlcvkgtF69fJ8eX
p/22PEOjsqnows37rYp0AZiLa7x9I1dZdjzD6tHfKNVylM5AuuyOExAZKlx90rlW
lL1nCJEuw/d6HBtVWWBgYDjeAMg5G0TpO2gU1j/A7kEzgZxWID6q/r1TvpDp1pi3
aJhjmyeZn2rVwdGPFX03pp7DWJetbYA5CuhGFucjPtkdXDCh2guuSsivcM6obpiA
EmI4QtedGGhy2Xp1ufLAHP89TuuSU1n9VaioHSpLlGkQA9v2PRjW4ChBVJwP6mVt
9XGhY7TgEQMVZWL/brCNI6aeCf8rfaBSHtMwAR6xQ6ofvYAjl7X1BpNOSx4s73B/
CWnGxvMNDPuu1scxkOF0y3M68p+xgT0UuHTx4JjUTQtESFTqtdua5JxLyzE2qGyz
pwzFjFzwoPBav5TPY7MB8WN79GImZFUiELA6vOL4CLaXEMCepsXYDhdP/3JLkD0e
GQfliduoa2KGUijKrzy+ZVrKwBjF63ylbKGrxJHnX1SB8OftYbdlIQRvhzwHwaOL
uSfnWGIg3Fo0fKs1/F/Q
=L3H9
-END PGP SIGNATURE-


0x6DCDD53C.asc
Description: application/pgp-keys


0x6DCDD53C.asc.sig
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Problems on torrc.d-style configuration directories

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello everyone!

I met some troubles when testing the new torrc.d-style configuration
directories feature
(https://trac.torproject.org/projects/tor/ticket/1922). Could anyone
share some ideas on the problem, please? I will be really appreciated.
The following is what I did:

1. add the following line to /etc/apt/sources.list.d/torproject.list:
deb http://deb.torproject.org/torproject.org tor-nightly-master-jessie
main
2. update Tor to nightly version: sudo apt-get update
3. tor --version: Tor version 0.3.1.3-alpha-dev
(git-a73d0fe9a87df762+b433dff).
4. sudo mkdir /etc/tor/services-available
5. sudo cp anon-connection-wizard.torrc /etc/tor/services-available/
6. sudo mkdir /etc/tor/services-enable
7. sudo ln -s /etc/tor/services-available/anon-connection-wizard.torrc
/etc/tor/services-enable/anon-connection-wizard.torrc
8. reload tor
9. since bridges are used in the anon-connection-wizard.torrc, when we
use arm to check the connections, tor should connect to one of the
bridges, if torrc.d style configuration worked. However, it didn't work.

I also tried to remove the /etc/tor/torrc, and tor could not find a
torrc file anymore.

The latest related discussion on the ticket is as follows:
> Weasel and I (aka Hans) sketched out how we would use it in the 
> Debian package, closely following the Apache pattern but with 
> naming that is more appropriate in Tor:
> 
> /etc/tor/torrc:: %include /etc/tor/services-enabled/*.torrc 
> %include /etc/tor/instances-enabled/*.torrc
> 
> These dirs are present for the actual snippet files: 
> /etc/tor/services-available /etc/tor/instances-available
> 
> These dirs include relative symlinks to *-available: 
> /etc/tor/services-enabled /etc/tor/instances-enabled
> 
> For example: /etc/tor/services-enabled/sparkleshare.torrc --> 
> ../services-available/sparkleshare.torrc
> 
> The sparkleshare package would include:
> 
> /etc/tor/services-available/sparkleshare.torrc
> 
> The davical package would include:
> 
> /etc/tor/services-available/davical.torrc

So I assumed it still worked.

Could anyone please help me point out what I have done wrong? Or could
anyone please point me to some docs about the new feature? I can see
the source code of core Tor and write some docs on this, if this will
be helpful, btw :)

I really appreciate your help!
Thank you!

Best,
iry
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZRvsbAAoJEKFLTbxtzdU86OkP/REdnsdcJJHoGyTdyXYoqJ6n
NgW3cKlEGjCZF5bxIQ+lIG6q85j3EfflPDov97VrVyCE8xr6TFG0dDs/sE4rPE/h
GjYhBzM1WC5o55vyvdehTh80wl3/hSj/LehCJLOpBKAjoxuzeDHtyrkd3LG22y8i
mi93wgfxBuEbqvstDVipWfJt/5JbBLtXS/QainQqFwwFHRxJpIZcSgvWR5UAXAyS
IQLW7m91lwl9W/irQvhM8d4nnk0ciTGMPKoyEt3FWHs9jP9ewKvIvWlxJVYZEefW
LlLHMVzbyqWZWnkLkCBNyBfZZ0Rk16YFrUuMkTUH83LO/kBSlWFOj3idN5gYwda/
aanJhtopLH1u1nP10TqF6c4e6Bu6tfCOUh8sdOp8s7iB7MJHvaPU3lJM1vDk55u1
+fSxcDOm7NuN7xrJ3elUKS+oeOU8Ah4h43L/9lJgrIZ6zdIdI1f0E4QXlIWbKIbf
dkQJrG760R/6jG6JMnbiOFPwoFelLna1hX6USpbnVEfhh33n3t/t5EpK5kH/q2m9
/lCkMcBpa5XXVquGaeCCQ+2X4wQ31wlhka12GADtVkq3SohOnfKzRauJYN8OcHZH
eNZlDMbO8j3y9IHEdM+mhT8a7XnnZokFINSjmjnOnAQdk8A8QjB5V/TIZQB1uJwd
1uUyayVwl9SQHy3P6yuH
=SLHC
-END PGP SIGNATURE-


0x6DCDD53C.asc
Description: application/pgp-keys


0x6DCDD53C.asc.sig
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Feature Request: please consider ship default Tor bridges

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Tor people!

A set of Tor bridges are shipped with Tor browser bundle[0], helping
users in Tor-censored area to connection to the Tor network. Since
system Tor users may also face the censorship problem, shall we
ship some Tor bridges along with the tor package?

The request is firstly reported[0] to Debian BTS and I got the
following reply by Peter:

> If upstream starts shipping bridges with their Tor releases, that
> would naturally result in the Tor package shipping bridges as
> well.
> 
> I do not know whether that's a good idea or not, but I don't think 
> deviating from upstream would be particularly worthwhile.

The following is some related information which may help the future
discussion:

The possible formats to hold those bridges can be:
1. JSON which is also the way tor-connection-wizard used so far[1];
2. plain text which is the same formatt given by the BridgeDB[2] by Tor
Project;
3. "Bridge" + plain text which is ready to be appended to a torrc file
or to be one of the torrc files in /etc/torrc.d/ (or whatever torrc.d
path Debain decides to use)

The default bridge shipped with tor package should be exactly the same
bridges contained in bridge_prefs.js[0] shipped with the latest stable
TBB. This is because:
1. The servers hosting default bridges are set up for huge amount of
traffic;
2. The servers hosting default bridges are probably audited by TPO for
better security;
3. Using a different set of bridges will distinguish the
anon-connection-wizard bridge users from the TBB bridge users, which
compromises their anonymity.

What do you think?

Looking forward to hearing your insights!

Best,
iry

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872456
[1]:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundl
e-Data/PTConfigs/bridge_prefs.js?h=7.5a3-linux
[2]:
https://github.com/irykoon/anon-connection-wizard/blob/master/usr/share/
anon-connection-wizard/bridges_default
[3]: https://bridges.torproject.org/options

Best,
iry
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZldAaAAoJEKFLTbxtzdU8QHEP/0DyAtD95JOKEkDulsyuuVfx
uYT+5WGaRSFntqRq91RcNkHLHDy61JtLXhr5VIcz/tYIIe3TVZhI9idqbPgJMZc+
xxS/4r5qhkkcJ5X99xo7Jerz/0Y/4CKboREAkSstz15RL3FNLF6mwFZgWsiZ4rMa
SkruE8qchz1KIUuWKZyx3HioloZgIHQkvqQ6fE4asGIs8gnaKeofpSwRGq85/Vcq
T8D0WTqCFweLFaYzCWMtO7bVKXrfqC8rGLesLPJhxZbl0MJ3H/5TdvbPHn6VwRH0
AZCT5q7A+0fC/+HHwsn9SFhMo0TaIOtZBonOH58X3OEamKrmJOwqESvCPqILtMC3
pU2PtoOSDQEd684b2hxoR+0uRMOew+CJ+U7lzyh7yYU9x3jv//9CsFGcKcD+FoFG
zrkDPJ75uzYGJjHZUFpnk8opwVy49TghYiVvjwm9/PXXQVvEiCGNEt7W1wTHX3Ja
DygMsGN8GXg6AqWRESg4NcI8N/4U2EUEt+Li45u0qsTJ/uYmfamsC/WoacfjznaD
JQVKjJQlhuk7F3qUPuxtxaGCLopLJd/uAUyYaI/HPrFeR3uIawSzCW9prTkk/E7n
wAop3mErdp6JYnTacUb4pcYINIQf1c7FymbngrAmJzljxH4apZpBPugitAYvtJ2X
2OBJpUV0CtEJH3poicdq
=oct9
-END PGP SIGNATURE-


0x6DCDD53C.asc
Description: application/pgp-keys


0x6DCDD53C.asc.sig
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Feature Request: please consider ship default Tor bridges

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



David Fifield:
> On Thu, Aug 17, 2017 at 05:19:44PM +0000, iry wrote:
>> A set of Tor bridges are shipped with Tor browser bundle[0], 
>> helping users in Tor-censored area to connection to the Tor 
>> network. Since system Tor users may also face the censorship 
>> problem, shall we ship some Tor bridges along with the tor 
>> package?
>> 
>> The request is firstly reported[0] to Debian BTS and I got the 
>> following reply by Peter:
>> 
>>> If upstream starts shipping bridges with their Tor releases, 
>>> that would naturally result in the Tor package shipping
>>> bridges as well.
>>> 
>>> I do not know whether that's a good idea or not, but I don't 
>>> think deviating from upstream would be particularly 
>>> worthwhile.
> 
> To get an idea of how frequently the list of default bridges has 
> changed, see the tbb-bridges keyword in the bug tracker: 
> https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges
ol=time=id=summary=keywords=status=1=time
>
>
> 
Thank you very much for informing us the way to check default bridges'
update frequency.

The frequency is generally once per month while sometime three times a
month.

This RSS feed may be helpful to immediately inform us the new changes:

https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges
mat=rss=id=summary=keywords=status=time=1
=time

>> The default bridge shipped with tor package should be exactly
>> the same bridges contained in bridge_prefs.js[0] shipped with
>> the latest stable TBB. This is because: 1. The servers hosting 
>> default bridges are set up for huge amount of traffic; 2. The 
>> servers hosting default bridges are probably audited by TPO for 
>> better security; 3. Using a different set of bridges will 
>> distinguish the anon-connection-wizard bridge users from the TBB 
>> bridge users, which compromises their anonymity.
> 
> There is an argument for using a different set of default bridges: 
> when one of the Tor Browser ones gets blocked, it won't affect the 
> Debian ones. For example, for a while, Orbot had some additional 
> bridges that Tor Browser did not have. When the firewall of China 
> blocked the Tor Browser bridges, the Orbot ones continued working 
> for another nine months (until they got blocked for a different 
> reason). We know that at least China and Kazakhstan pay attention 
> to the default Tor Browser bridges (and China blocks them as soon 
> as they enter the source code, even before a release).

> So having a few bridges that are not shared with Tor Browser has 
> that advantage, at least.

Thank you for offering me the interesting information. I did not
realize this advantage before.

The advantages 1 and 2 which I mentioned above will still be valid as
long as the bridges are TPO proved. Therefore, it sounds to be a good
idea to have some unique bridges shipped with Debian Tor (if including
Tor bridges is a good idea).

> Of course, it's basically security by obscurity, because a censor 
> that can discover the Tor Browser bridges can (in theory) also 
> discover some other static list of bridges. But in practice it
> will take censors time to build automation to read from a new list,
>  default bridges are security by obscurity anyway, though 
> surprisingly effective for that.

That is true. Using security by obscurity strategy in censorship
circumvention is more like a resource competition. When the adversary
is a country like China, we may not be confident to win in long term.

Btw, Collateral Freedom seems to be one of the most effective ways to
circumvent Internet censorship in China. Circumvention tools that
depend on Collateral Freedom usually works fine, including meek,
lantern, psiphon3 etc. Therefore, I see a lot of potential work which
may benefit the Internet freedom in China. For example:
1. package meek into Debian
2. host (part of the) BridgeDB mirror on Github or AWS
3. #22402: https://trac.torproject.org/projects/tor/ticket/22402
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZlfU8AAoJEKFLTbxtzdU8OOoQAIv+tJcNTi6hUExD2H/e8Wh6
YICR3OwSIp6v1kYD6aXWW+sL5OQzBe4K8pJsSD6IQzukfswytGd4BuTqYj2oiZSz
kBKWas9CdHF2nC3MThCL65ImSzPgg+z1hOsy1f7ur0yFh0tj7yCKaXQFQqCMOO5+
lGxMYJfjF22zIHg9j3Q/IgrMNojBOLKtFD9KLNOURA1WMJGnVzrTx4lEyw9WaKBI
A/eK1ZZWpRIiEYVyvvItU+/a54ax1Pirt2G4bZVKMnmiZ4evhjU8MuTOFPYRq/YI
bUe6G4YJvNgqVxj0RmSTxaJHfX2KHOUEZQMR4uhmWMVTch0093rQBk1ICJy89tyz
PWZmOzyp2H8QVSPxFPR5+5xzeinLDR5FsUc3Q9XeD1MiIlSk5W+EKGfQzVHpawGq
lfo8kBN+iExTx4KErJPLreqv3iol9XUQgN/kD4SjDaHlM/YXt34NpOHfdafFdqDj
yAwvAeGL5gSwDiV//Mie7fB493dcssaR70kl02hM51LuNywf0mzt0iYA9pyCv9Zo
vzDskzAYElIKoWQBIkt15R22uC0bG6VW/BaeHS2SXRqIDLEsaq/f46E+D/IP+8o5
kMU/M3JygjvtyM+iKbnEOvxRBVfCLL0c0rO57TOdGd5Ijmrlqcpf

[tor-dev] permission denied when running snowflake-client with debian-tor user

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Tor developers,

I met a problem when trying to use the snowflake-client binary
extracted from TBB 8.0a8 with the system Tor.

Specifically, it seems snowflake-client cannot be run by debian-tor
user, regardless of the permissions it is given.

I am posting the full steps below. A better formatted version of it
can be found here:
http://forums.whonix.org/t/replacing-meek-snowflake/5190/18

> Here is the original permission and ownership of snowflake-client:
> 
> user@host:~$ ls -l snowflake-client -rwx-- 1 user user 14160744
> Jun  4 06:17 snowflake-client
> 
> It can be executed by user user:
> 
> user@host:~$ sudo -u user ./snowflake-client 2018/06/04 06:18:21
> 
> 
> --- Starting Snowflake Client --- 2018/06/04 06:18:21 No HTTP
> signaling detected. Using manual copy-paste signaling. 2018/06/04
> 06:18:21 Waiting for a "signal" pipe... ^C
> 
> We now change the permission to let it executable by user
> debian-tor:
> 
> user@host:~$ sudo chmod 777 snowflake-client
> 
> 
> user@host:~$ sudo -u debian-tor ./snowflake-client 2018/06/04
> 06:18:43
> 
> Noticed the permission denied:
> 
> --- Starting Snowflake Client --- 2018/06/04 06:18:43 No HTTP
> signaling detected. Using manual copy-paste signaling. 2018/06/04
> 06:18:43 Waiting for a "signal" pipe... 2018/06/04 06:18:43 open
> signal: permission denied
> 
> We now change its ownership to debian-tor:debian-tor:
> 
> user@host:~$ sudo chown debian-tor:debian-tor snowflake-client 
> user@host:~$ ls -l snowflake-client -rwxrwxrwx 1 debian-tor
> debian-tor 14160744 Jun  4 06:17 snowflake-client
> 
> Still, permission denied:
> 
> user@host:~$ sudo -u debian-tor ./snowflake-client 2018/06/04
> 06:19:15
> 
> 
> --- Starting Snowflake Client --- 2018/06/04 06:19:15 No HTTP
> signaling detected. Using manual copy-paste signaling. 2018/06/04
> 06:19:15 Waiting for a "signal" pipe... 2018/06/04 06:19:15 open
> signal: permission denied
> 
> However, when executing it by user, it works fine:
> 
> user@host:~$ sudo -u user ./snowflake-client 2018/06/04 06:19:22
> 
> 
> --- Starting Snowflake Client --- 2018/06/04 06:19:22 No HTTP
> signaling detected. Using manual copy-paste signaling. 2018/06/04
> 06:19:22 Waiting for a "signal" pipe... ^C

I didn't find any special requirement for the user who runs
snowflake-client from the documentation, so it would be extremely
helpful and appreciated if you could share some insights on this
problem. :)

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlseXpcACgkQoUtNvG3N
1Tx/fBAAvnl84inklNYJ4N0QRz9X9FAtmTlTTb4mrtW+WM36oaDEFigSZeha7pmw
er+oV1hG1SlHf6iel2i6YyUXAi7r6YURqlv0fFtLMaelfAIda/ywEMwVsJ19VHzn
qPPEADQVY4c55KuOgkhCMSTxGUn2wXbM+PpFf/WTaZ40gjPOjucUXUxlhwj6X6EX
wTBiUEq2yjs4xyWSfgOinFuoPqLG5Hfx/z+1ZSyL2R0yeeK1kSiB5kD90mwfOeKq
EM32xbYLy4OmQQ3cABHB2mn0wDaS8E2t22sHXhPNANdJTdM/ztcjI7BZjNMUz1Ig
aQEVpLE2yvVQu4O3nyThLnH/b08z4a6oVVE7JQpG9rmLfoFuUbJ6vTF+l6nQTJOY
mnkiL6RwGVerm612OXFOLBpHSBbToEX12tqqjC569s/OExcFzHpiiTg22HcOYab/
YSu4zUTX23wRBQhOkBQ7EL+idHGK7lwGN5d0Y45H7cwOoIXwXTu3ff1e6yjuT9Bx
Pc+tlkw7vJGB5jhFuW9EYvjrWDklbpR7HZ7TTSkDvGvzXUkAZnCzyBAnePxwQbid
45Vwsn7QCFISsZdXCS53RPoVPbNGcSQTyWn4gv/U37Fb/pZ1LYYAJFcNOl5HB8fl
nhXL9D7Mey/79n3hepChBUXpaNeHX9J+7R91A8tUjzz9irmhU8o=
=Aie4
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] No Control Socket when DisableNetwork 1

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Tor Developers,

According to the Tor manual:
https://www.torproject.org/docs/tor-manual-dev.html.en

> DisableNetwork 0|1 When this option is set, we don’t listen for or
> accept any connections other than controller connections, and we
> close (and don’t reattempt) any outbound connections. Controllers
> sometimes use this option to avoid using the network until Tor is
> fully configured. (Default: 0)

However, it seems when DisableNetwork is set to 1,
/var/run/tor/control does not exist anymore making us cannot get a
controller from socket file.
(stem.control.Controller.from_socket_file() is affected in this case:
https://stem.torproject.org/api/control.html#stem.control.Controller.fro
m_socket_file)

To reproduce this, I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian
Stretch:

When DisableNetwork 0, run:
systemctl --no-pager restart tor@default

> user@host:~$ ls -l /var/run/tor/ total 1328 srw-rw 1 debian-tor
> debian-tor   0 Jan 19 21:14 control -rw-r- 1 debian-tor
> debian-tor  32 Jan 19 21:14 control.authcookie -rw-r- 1
> debian-tor debian-tor 1350116 Jan 19 21:14 log srw-rw-rw- 1
> debian-tor debian-tor   0 Jan 19 21:14 socks -rw-r--r-- 1
> debian-tor debian-tor   6 Jan 19 21:14 tor.pid

When DisableNetwork 1, run:
systemctl --no-pager restart tor@default

> user@host:~$ ls -l /var/run/tor/ total 1244 -rw-r- 1 debian-tor
> debian-tor  32 Jan 19 21:00 control.authcookie -rw-r- 1
> debian-tor debian-tor 1269005 Jan 19 21:00 log

I searched on Tor-trac but did not find any similar report. Therefore,
would you please tell me wether Tor intentionally behaves like this or
this is a bug? (If this is a bug, I can definitely help to report it
to Tor-trac.)

Thank you so much!

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlpifX0ACgkQoUtNvG3N
1TwLsBAAn8W3H7VMwiR9UwnVJoXOZ0iWRLbF/JdtDUjXcG1/cQmK5aEHtbVCy4Jl
VOWYKBJeHxZAmHlBC+ZR3E/vyDesatjPDIPvzUuwYN3T0COFpMyN71ipOjs1KqYP
GFFgLFzClQHvnThe59TIEomVcdXIt9ebPU3QmVxnNhvB/KKggKOgTuYd/n8R0efe
0kAl5/8vZZv4/IiorRkF/ltQwmnOTR1V2H1OrOOHM/AyxLGfwGO9KffznRDX/BN4
AdM4MWpMh3+DKCKgJZpf3Gzwcn7d6DvL74YQVIhmwofoxEOCBD/f+iYeJKkoVPw7
Pd8YHkYvXqCRqHBFfTEe4BtZdcxK2k3FXbUcbKahFDYMtdotdzknf542f6+Bbt+p
hmiuJT8bX/Kn2dBzonbqJuh2XEBA2y6OqqhJaVoJr5l6tWyghp18BsA2m6W4mg2H
ApkUTv0YsQ8guXckfJP2LOhXxKWN0yncQ7bMzGZSfSwtqGwrDxFFWk2V8vXIrWWL
X5pz3oObvQB9eUJcKix2C29kJSGBry68Ts1x4MnL14CDw0WqNqAqe0O3IAiCANjl
CU+z9P129eb/pdYXW/OTFnVyWhQBXNvCRHTZB7Yvym+dN4B6MD3uOkH9THf9BaCF
yVCOK1c04/sfqADnpE3Rhkr98iix3N2gbdOod/10T+GyG4OBh64=
=Oh0M
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> To be more precise, most tools accept files ending in ".conf". We
> might want tor to accept ".conf" for consistency.
> 
> I suggest we also accept files called "torrc", or ending in
> ".torrc". This should probably also include files called literally
> ".torrc".
> 

Thank you for your suggestions, teor! I have updated it in the ticket.

> Since this is a breaking change, we might want to check if any 
> distribution has adopted another naming scheme, and avoid breaking
> that naming schem
I agree. I will wait for a little bit before implementing it so that
we may get more input on the issue. :)

> If you'd like your patch to be reviewed quickly: * put the ticket
> in 0.3.3, because it's a bugfix * change the status to "needs
> review" once you have a patch

Thank you so much for your instructions!

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp3dnwACgkQoUtNvG3N
1TycXQ//X5m4c9gucDY2idIHULxzIDdfgAFnPOyjzyqDLjM8y4/Uu/3xV4SX3gX8
M2qguNmqMX2+OuoWTHPo+4S+L4qS12XibUha1lwcWxjXGyPkZ7iwIvj7a0RoBsb1
Ln6DcpBGcPt61trQg4eBLI2JbAOQRXh3J/jl9djNzs64uj/0WtxXcUhBDPiJyPz1
yunB8EuO3NJIZ9n1SoT6d9HpF8oLPu4E9PkhFi0uflPKdZhwAUqCLW4J4zqlK2eB
8cQezMHvqNmTYS9pmQgw6lz0xAL+6NQZWUeFLFE+TvIqB8RwFQkAcb3mfTfDFvpf
K/tOiSF+9OvMEVonB1efWUhaxSBHc8MwQFfWaWTNNndHkO6lVGYtwPC7UfrteTY5
cr0oB6xE5U+La/2GnwP5i2200v0IgNi1S82okXIbGbMyEgEXzkC4+6xIsq40ksGy
8hRHEusLz8FUefKioxdiyPmHZgrq1jzQGSgFQKafKLR0YkfFgnbIX1alMgVIatS0
xbr53GXtQVY658T/lAdXSIqwb5regJ9NB/+LtB7HvzFbFMCnT4g1yDYLSsiwWX/z
2KJH8+OOKy6WMRmoTbMXb1J+WnBTVfazUc+fOs4IK2tlnMDs7TukcS9FtNHS1G1d
AlgML+AfnuO3m8SKR1Vsbl5PRypA7Vz0a4kkzy1dLgpaqVxP6Rw=
=vdE1
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi teor!

> Could you please look at existing .d folders of any other projects 
> tell me what you think? Perhaps discuss this with Tor Project. 
> [...] From my quick search, it appears that the Debian feature 
> request is still open, and no other distro is using torrc.d yet. 
> But you should check, too.

I went through all Tor packages listed here:
https://trac.torproject.org/projects/tor/wiki/doc/packages and no
distros shipped a torrc with %include line enabled.

I know Whonix will not use torrc.d before next stable version. I also
did a grep -r -i "%include" on Tails source code and I do not think
Tails has enabled it by default.

nickm suggested proposed to create a new syntax to take care of the
compatibility:

> %include /etc/torrc.d/*.conf

Here is my thoughts on this:

1. I agree that "[a]nybody who currently has a working setup will have
it fail if we start requiring a suffix that they didn't know to
provide", which is not good for compatibility. But, letting people
still use or will be able to use a setting that is not recommended
anymore seems also not to be a very good idea? Considering the
potential danger of parsing all the files, shall we go a little bit
aggressive? I would rather break people's current potentially
dangerous settings. What do you think?

2. Since no distros I know has enabled this feature by default, I
guess there are only a very small number of users has enabled this
feature. Will an info in the release note saying "%include
/etc/torrc.d/ will only pase files suffixed with .torrc files" be
enough to inform them? Maybe we can even document the manual migration
somewhere.

3. %include /etc/torrc.d/*.conf syntax is very flexible so that Tor
does not have to decide which extension names should be parsed.

4. %include /etc/torrc.d/*.conf syntax explicitly says which extension
name will be used rather than the implicit document.

5. But is it a good idea to make the syntax that flexible? For
example, anon-connection-wizard will generate a torrc files in torrc.d
directory, I (and maybe many other developers) prefer writing to a
file that I can guarantee it will be parsed in most case. If I write
to 40_anon-connection-wizard.conf but some people set to pase .torrc
or anything else only, it will be not be very good? (I do not want
anon-connection-wizard to touch /etc/tor/torrc)

Finally, do you think it is a good idea to switch to the ticket for
further discussion to avoid cross posting and high volume on @tor-dev?

Thank you very much!

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp4pFoACgkQoUtNvG3N
1TwSkRAAnBRytWCeP8ocCOJ0FmJZVq4ANznDWWBoYg+iaRPUMYbU/Tro0j7ljJMe
snf0ji+Eu8DqTjg/HgmQ9gVuiJNWE7jfvnaAE7nDxeqd23J68ek5yHeIwonnaVPq
IrWeCQDAAUUz42rAcoHBsy/tGS/kiq0OMf3yf6Pzq02UsQ4Ob46kD4ySNnirRXce
a/mJG1zMXoAYnM84bKnm6bD4Gx5qiyK+O61e70z4b4ArPqRpxmfQoU5RAELMHAFU
hq9JtdxN/FBvNq7NUOboAYcX1FdkWLLEaQXWB/sgtS94OvCIX0hfrtis0/UFPTe5
wQN1FQCFBpPkHOLuvszNln9WvPf0XSWqCDVdZh7Fd9GrELfrVwEJYC2+1rukPWZq
U0ZJ0smDkdijHBc53i6+23175GyaQ+uMoSebouQ2vh9hbf2qx1EMnSFc5pSz8y5b
eJgUA6WFZvcTgUFmwYpe3X2E3QcoYHD8UNoBZiD0ehXrWTcxScT0kWNcF06v3dhr
4Doo9wxDmF/ZusRrpyTRCZ5LsPCCL1spphxNqlCIm9MsfUCHBUbULBKn+uV2fNb6
4Xk2gu6eA258ZEfYDhottLpsk8V15Jx7F+Jz/W0zlL5OCwDzhPcG44C7OfEzeW5u
h42Jw6YsQkAgGXnKzRG9lW7emVkLLhF0wlCSeWY8QxHGnxShdLY=
=EnSw
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] No Control Socket when DisableNetwork 1

[iry]

> My first suggestion would be 
> [...]
> My second suggestion would be to get a Tor binary and run it yourself,
> not as part of a package. If it works there, then you know that your
> next steps are to figure out why your package isn't working for you

Hi Yawning and Roger!

Thank you so much for trying to reproduce the bug and teaching me on the
generic Tor debugging steps! I agree with you that:

> If you can get a minimal case reproducing the bug without a package,
> systemd, etc, in the picture, that's a great time to file a trac ticket.

It turns out, to successfully reproduce this, we need:

0. set DisableNetwork to 1
1. use User option as part of the Tor configuration
2. run sudo Tor from a different user in a different group

Here are the specific steps to reproduce it. I tested it on Debian
Stretch but it should be distribution independent:

user@host:~$ cat /home/user/my.torrc
DataDirectory /tmp/tor
ControlSocket /tmp/tor/control.sock
ControlSocketsGroupWritable 1
CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /tmp/tor/control.authcookie
SocksPort unix:/tmp/tor/socks.sock

user@host:~$ sudo /usr/bin/install -Z \
-m 02755 -o debian-tor \
-g debian-tor -d /tmp/tor

user@host:~$ ls -ld /tmp/tor/; ls -l /tmp/tor/
drwxr-s--- 2 debian-tor debian-tor 40 Feb  3 18:19 /tmp/tor/
total 0

user@host:~$ sudo /usr/bin/tor \
-f /home/user/my.torrc \
--User debian-tor \
--DisableNetwork 1

There should be control.sock, but not:

user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/
drwx--S--- 2 debian-tor debian-tor 100 Feb  3 20:00 /tmp/tor/
total 8
-rw-r- 1 debian-tor debian-tor  32 Feb  3 20:00 control.authcookie
-rw--- 1 debian-tor debian-tor   0 Feb  3 20:00 lock
-rw--- 1 debian-tor debian-tor 215 Feb  3 20:00 state

To let Tor really open the control.sock, we need to reload Tor (yes,
even though we just start it):

user@host:~$ ps -A | grep tor
  863 ?00:00:00 xenstore-watch
  927 ?00:00:04 tor-controlport
11851 pts/000:00:00 tor

user@host:~$ sudo /bin/kill -HUP 11851

user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/
drwx--S--- 2 debian-tor debian-tor 120 Feb  3 20:01 /tmp/tor/
total 8
-rw-r- 1 debian-tor debian-tor  32 Feb  3 20:01 control.authcookie
srw-rw 1 debian-tor debian-tor   0 Feb  3 20:01 control.sock
-rw--- 1 debian-tor debian-tor   0 Feb  3 20:01 lock
-rw--- 1 debian-tor debian-tor 215 Feb  3 20:01 state

I guess the reason Yawning was not able to reproduce it is because User
option was not set:

user@host:~$ sudo -u debian-tor \
/usr/bin/tor -f /home/user/my.torrc \
--DisableNetwork 1

[notice] Opening Control listener on /tmp/tor/control.sock

I was thinking Tor fixing /tmp/tor/ to 2700 may be the reason, but then
I cannot explain why this will work with /tmp/tor/ set to 2700:

user@host:~$ sudo /usr/bin/tor \
-f /home/user/my.torrc \
--User debian-tor \
--DisableNetwork 0

[notice] Opening Control listener on /tmp/tor/control.sock

Would you please share some insights on the this?

For temporary workaround using systemd in Debian, I put this line in the
[Service] section of /lib/systemd/system/tor@default.service :

ExecStartPost=/bin/kill -HUP ${MAINPID}

Best Regards,
iry





signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

>> Therefore, may I propose to let Tor parse only the files whose
>> name ends with .torrc ?
> 
> Yes, this is standard behaviour among many tools.
> 
>> Or maybe even only parse number_filename.torrc for better
>> consistency and for more clear priority order?
> 
> No, this is counter-intuitive. It will confuse many users. It is
> not how most other tools work.

Thank you so much for the feedback, teor!

I have opened the ticket #25140 for this. Shall I try to make a patch
on this? Or is it preferred to leave it to developers from TPO?

Thank you very much!

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp2hnAACgkQoUtNvG3N
1Tz3GBAAghKBKm7JVd5PyO7HGBClshO/fUOG2ippVm5hY9sgmzVPxVauJC+CWJN9
RH6YfJwyLJeAHu0o3YD1+LBHvccxTKKQYL48q8aopfWkh8ALk4h9+O5hwpPPIsGC
qV7iJ+v4QfpxYkhAUFh8FOy+m5WqsOurScBzcjEnmu2IpIkpnwv1NKLaVrArpMv9
lrGtQds/7dCYC57boSUNgTTJtbuqgNhRBM1oqkGisHsKBiLYExvztS22aLj9uVEX
km5c+JJuwEKuuordP4YiFMdES1UYx9Bdm/LrUNWG4dB/ZfjwZYSu/KPsqQcDwmNy
25iovL5KUkVg8S05QwdcCnXm2B5oofLMJ4hW0bkjozjLUt3na131uJumOR7Q2W9f
9aKAGwRzQ624rDHn3SWCC1HKMhP0Y6EhCDyzX5914kRakikas6hmtUWmrSqFvZLO
p0WzWuNB05BdRXImTXxPdLyOxasB/eMt31mQXKBSSiwdzJxe3rfnDb//P2vcv9ex
ofQNx672qtAgmHp9WWeKY6qas36sZeckEigIlcUN27KFBwDyCGfCebk5tPIGDzC9
aAqmiTqqYCqphHb3i/xX3WwGwk6+Q1ixezOfYFxbAOa96NUDV2ldYIXgBcsAWh/+
RbZ8hI/oOwAug/C9ig5xFpZAy86bbqDApG6wrGNg5gp3qVKDlnA=
=zlMh
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal: only parse .torrc files in torrc.d directory

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Tor Developers,

I have been testing and using the torrc.d feature for a while, and
here is a potential improvement we may make.

Currently, when using a torrc.d directory, for example:
> %include /etc/torrc.d/

Every file in the directory will be treated and parsed as a valid Tor
configuration file. However, sometime, this may not be what users and
developers want.

For example, users may use /etc/torrc.d/50_user.torrc as the place to
put their own torrc configurations. But sometimes, when they use a
text editor to edit it, the text editor will leave a
/etc/torrc.d/50_user.torrc~ file which will also be treated as a valid
torrc file.

Another example that also happens very frequently is, when dpkg does
an update on /etc/torrc.d/30_distribution.torrc, users' previous
configuration can be saved as
/etc/torrc.d/30_distribution.torrc.dpkg-old which will also be parsed
by Tor.

In best case users will just be frustrated because Tor does not work
as expected and in worst case this could be dangerous. This could be a
severe problem especially because of the following reasons:
1. filename.torrc~ filename.torrc.dpkg-old has higher priority than
filename.torrc when Tor does the parsing.
2. In most cases, this will happen without being noticed by the normal
suer.

Therefore, may I propose to let Tor parse only the files whose name
ends with .torrc ? Or maybe even only parse number_filename.torrc for
better consistency and for more clear priority order?

Thank you very much! Looking forward to hearing your insights!

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp2Oa0ACgkQoUtNvG3N
1TxfBA/9FfFhBfI08ocI6Wluodg58lppbG+N1LOGxoTSH2iq53P7GaWvZd9OULP1
ezTDbnlPJ3jreBYRnze8/MaUFA/x6wJTAcyM71xktwuR1Np47StY8ishZnbLpI5z
D7r65kKZyxrcCht99oSOFuqakVb0bFJJJRF1rvgt9gDHZT9+0V1/GVAv0w1SEb7J
LYazQyjtIgCJQaDdZvRsulnlBuFF6KvVNZp4EEKfggihM480SJV1gRExDBrEYQEN
BqtYixEe2P2MHPZSV7Szp28D87I391GwrHuLGsrlhL92OPPygVlc+Amyw9rEMij4
y/sXlSN+62Q2UV2CvFGzxSJBNhstJ4Meh91yKDf+Lm0CER5ydEUWtLJLYaIGmjS/
iQNQUd/6Y2dIyzeZuXFm03cfIXtQNdQFAhahNvNEeUOcJ4Qk4IsHXUi7MSzHcQTb
lv0E/2IzleXWp57L9rDPayA7eUpNMHlZkVyH42WunGcK+uz6PIT/bvBc5L1b/z3/
zkaPleDivBV5czlBtQIwRURibbUuveDtGfacM/3pmQ5XuYYaA6UvRExHePMeQvM+
Y01YTMlEcqL4LcjHSJiGamdWRPtGazbXVT1bl4VRJ1RqGqrvFE65I+xdg01UnSWy
tgsOUhEwrMUxUdsumNpb6sEgpUmZ/NzKbi7zgGywEmxVkUN67lc=
=zue4
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory

[iry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thank you so much for the immediate feedback, teor!

Could you please help me to review the requirements (TODO list) below:

* %include /etc/torrc.d means parsing all the files in the directory
* implement %include /etc/torrc.d/*.extension syntax
* let Tor log each config file it loads
* warn on potentially unexpected files
* document *.conf as the recommend usage
* document how to manually migrate from * to *.conf
* recommend /etc/torrc.d/*.conf as "a default extension for packagers"

> In my experience, mailing lists are good for discussion, trac 
> tickets are good for tasks, and gitlab/oniongit are good for code 
> review.

Got it!

Thank you very much!

Best Regards,
iry
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp4wsIACgkQoUtNvG3N
1Tx3JA/5AXuMfqo7jww4LeRvIUfs69+Fu98MV8X1GLKaTnqDH7MnDhOW5KxUY8HU
FbVK040GhV7UGMCP83fCbSnFVw4uNFMENToYVFB649Lg5/BAOzbvQ0Lc6i1B+fUt
W5rq3rzJxvMSG3q8EXPgxxHWUGl2AKzGkKBeIxc4WYt1aZX9FXpbVCZn3Rnu5Gj1
OeesVXdkO0TGb0r99qEBg7CqGUUT28L8VveiJlZHyRUFpwrKdBlX8hVhpIaQYEDV
9NXMTtRd4eHUFrRs7ZINpg6LiUKcicVVOHj1p0qx1DV5T9tdXVpBemHTJQtmQAU+
3iJgyoNHDez0WBlIwhXm0zr3QFot2/MV2D+yKAIJGwVlWOtEFnqUGyX+LwxD6XQ8
Qzj4XcOLbs+hIB6h/QPXGgQnP7seLZhJMQAReMu64uvGx+zt15Avm3DAbz5rgwnR
pYQatcG/2/6sESgNz4NXjPaxz6nokylsKSMaynd1aHHzsOc3vLVWRbHbMvSoC8Mu
iKeUhhg01pO6eSzAzM9tnFGb0TaSrjR5NSnq3BoFeSnPNqZdsmehBOMMFXtj68QC
Dn78/gC0++W0DZONXSf2HdARwP+asNTzMnyobQHw3ikgLtCxCNjCLOTycyrCMkNS
Ar8cbOEVaDG802JWUMdWnFbbE6CfNWh5egx3jSzw19NDM+qGM8E=
=mJnZ
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The Tor project as a GSoC voucher for Whonix?

[iry]

Damian Johnson:
> Thanks teor! Quite side note: it would be helpful if such questions
> are broached earlier in the process. Google has been calling for org
> applications for several weeks now. Asking roughly a day before the
> deadline creates last minute confusion and reduces the chances of an
> affirmative response.
> 
> On Tue, Feb 5, 2019 at 8:06 AM teor  wrote:
>>
>> Dear Whonix Community,
>>
>> On February 5, 2019 2:20:18 PM UTC, iry  wrote:
>>>
>>>
>>> teor:
>>>> Dear Whonix Community,
>>>>
>>>> On February 4, 2019 11:52:44 PM UTC, iry  wrote:
>>>> Dear Tor Developers,
>>>>
>>>> Whonix is applying to be a Google Summer of Code organization this
>>>> year. I am writing on behalf of Whonix to ask if the Tor project
>>>> could be a voucher for Whonix. Specifically, in the application
>>>> form, it asks:
>>>>
>>>>>>> If you are a new organization to GSoC, is there a Google
>>>>>>> employee or previously participating organization who will
>>>>>>> vouch for you? If so, please enter their name, contact email,
>>>>>>> and relationship to your organization.
>>>>
>>>> Whonix community would be really appreciated if Tor can be our
>>>> voucher this year. And please feel free to contact me to provide
>>>> the information described above anytime before the deadline
>>>> (February 6, 2019 at 20:00 UTC).
>>>>
>>>> Thank you very much!
>>>>
>>>> Cheers, iry
>>>>
>>>> I have forwarded your request to the Tor Core Contributors.
>>>>
>>>> Some of us were at a hackfest and FOSDEM last week. A few are still
>>>> working or travelling. So I am not sure how many of us will check
>>>> our emails in the next 36 hours.
>>>>
>>>> I hope we will have a response for you around 24 hours from now.
>>>>
>>>
>>> Thank you so much for your help, teor!
>>>
>>> We really appreciate it!
>>
>> Tor won't be able to vouch for Whonix for GSoC 2019. I understand that you 
>> are on a tight deadline, so I wanted to let you know as soon as possible.
>>
>> I have received a range of responses from Tor Core Contributors over the 
>> past few hours. A number of people raised concerns about the Whonix 
>> community's culture, and whether it would be a good experience for students.
>>
>> I hope that we can give a more detailed and helpful response later. But it 
>> may take us some time, because we are still working through our internal 
>> community processes.
>>
>> T
>>
>> --
>> teor

Thank you for your response, teor and Damian!

I agree it would be better to ask earlier and I will remember that!

iry
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev