[tor-relays] Unsubscribe

[Jeremy]

Unsub


Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.


 Original Message 
Subject: tor-relays Digest, Vol 67, Issue 22
Local Time: August 8, 2016 2:00 AM
UTC Time: August 8, 2016 12:00 PM
From: tor-relays-requ...@lists.torproject.org
To: tor-relays@lists.torproject.org

Send tor-relays mailing list submissions to
tor-relays@lists.torproject.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
or, via email, send a message with subject or body 'help' to
tor-relays-requ...@lists.torproject.org

You can reach the person managing the list at
tor-relays-ow...@lists.torproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-relays digest..."


Today's Topics:

1. Re: tor-relays Digest, Vol 67, Issue 12 (grarpamp)
2. Re: is explicit DirPort needed anymore under Tor 0.2.8.6? (teor)
3. Re: [PATCH] debian package upgrade restart issue (nusenu)


--

Message: 1
Date: Mon, 8 Aug 2016 01:40:59 -0400
From: grarpamp <grarp...@gmail.com>
To: tor-relays@lists.torproject.org
Cc: flipc...@riseup.net
Subject: Re: [tor-relays] tor-relays Digest, Vol 67, Issue 12
Message-ID:
<CAD2Ti2-2R0KE+KA6EkMwVftA8G8Bi9OV4sYr0k=a-5CD=we...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On 8/5/16, Flipchan <flipc...@riseup.net> wrote:
> [bad netiquette]

When replying to digests...
- At minimum, change the subject to the original subject.
Optimally also include proper header threading.
Repliers should subscribe to per message distribution instead.
- Delete all content from the original except some minimum
needed to establish context to which you are replying,
instead of spamming out longquotes of already said longtext.
- Reply inline below each piece of context to which you are
replying, instead of top posting.


--

Message: 2
Date: Mon, 8 Aug 2016 17:33:42 +1000
From: teor <teor2...@gmail.com>
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] is explicit DirPort needed anymore under Tor
0.2.8.6?
Message-ID: <6aabda0a-4835-4b2c-a60d-a7a64568b...@gmail.com>
Content-Type: text/plain; charset="utf-8"


> On 3 Aug 2016, at 10:29, teor <teor2...@gmail.com> wrote:
>
> Clients on 0.2.7.6 and earlier still use the IPv4 DirPort.
> (Tor Browser is still 0.2.7.6, and apps in general may take some time to 
> upgrade.)
>
> Authorities on0.2.7.6 and earlier will only assign the HSDir flag to relays 
> with an IPv4 DirPort.
> (Authorities may take some time to upgrade, because running different 
> versions increases authority diversity.)

For the record, even though the man page entry for HidServDirectoryV2 says the 
DirPort is not required to be a HSDir, authorities on 0.2.7 and earlier still 
check for it before assigning the HSDir flag.

Authorities on 0.2.8 and later behave in a way that's consistent with 
HidServDirectoryV2, assigning the HSDir flag to any relay that wants to be a 
HSDir, and either supports being a directory cache, or has a DirPort.

HidServDirectoryV2 0|1
When this option is set, Tor accepts and serves v2 hidden service
descriptors. Setting DirPort is not required for this, because
clients connect via the ORPort by default. (Default: 1)

> Fallback directory mirrors must have a DirPort, and we'd only think about 
> changing that when:
> * all recommended relay versions are 0.2.8 and later, and
> * relays no longer fetch documents using the DirPort (so maybe never).
>
> All relays running any Tor version will continue to use the IPv4 DirPort to 
> fetch consensuses from other relays.
>
> So we haven't obsoleted the IPv4 DirPort yet. We've just made sure that 
> clients fetch directory documents over an encrypted channel.

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 
<http://lists.torproject.org/pipermail/tor-relays/attachments/20160808/b29f3270/attachment-0001.sig>

--

Message: 3
Date: Mon, 08 Aug 2016 11:53:00 +
From: nusenu <nus...@openmailbox.org>
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] [PATCH] debian package upgrade restart issue
Message-ID: <14e8de2a-577d-6498-e976-0002545b5...@openmailbox.org>
Content-Type: text/plain; charset="utf-8"

>> When upgrading, all running tor instances are stopped (not restarted, as 
>> expected)
>
> This might be your root-cause as well?
>
> https://github.com/

Re: [tor-relays] [PATCH] debian package upgrade restart issue

[nusenu]

>>> I'm generating instance names based on IP addresses_ORport (so they
>>> contain "." and "_") and are therefore filtered by the generator.
>>>
>>> Is it acceptable to add "." and "_" to the whitelist?
>>>
>>> (patches attached)
>>
>> Based on the output of 'systemd-escape' (a tool that escapes strings for
>> use in unit names) it is safe to use "." and "_" in unit names.
> 
> I am always wary of allowing dots in anything.  Allowing dots and
> thereby also allowing ".." is the origin of many vectors.  This doesn't
> necessarily mean that it's a problem here, but it's the reason I usually
> exclude periods from.


Since systemd devs deem it safe to use "." (and also "..") in unit files
would you share their opinion or will "." stay excluded?

You are tending towards not adding it?
Either way it would be nice to have a decision so I could move forward
(either by simply waiting for an package update or if rejected, by
finding a not-to-ugly work around for that limitation).

> Another is that I want to be able to move foo to foo.disabled or
> foo.bak, and have it not get picked up.

That does not conflict with the idea to allow dots, yes?


thanks,
nusenu



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

Re: [tor-relays] [PATCH] debian package upgrade restart issue

[Peter Palfrader]

On Mon, 08 Aug 2016, nusenu wrote:

> >> When upgrading, all running tor instances are stopped (not restarted, as 
> >> expected)
> > 
> > This might be your root-cause as well?
> > 
> > https://github.com/nusenu/ansible-relayor/issues/72
> > 
> > I'm generating instance names based on IP addresses_ORport (so they
> > contain "." and "_") and are therefore filtered by the generator.
> > 
> > Is it acceptable to add "." and "_" to the whitelist?
> > 
> > (patches attached)
> 
> Based on the output of 'systemd-escape' (a tool that escapes strings for
> use in unit names) it is safe to use "." and "_" in unit names.

I am always wary of allowing dots in anything.  Allowing dots and
thereby also allowing ".." is the origin of many vectors.  This doesn't
necessarily mean that it's a problem here, but it's the reason I usually
exclude periods from.

Another is that I want to be able to move foo to foo.disabled or
foo.bak, and have it not get picked up.

I could see adding underscores and hyphens, to match run-parts.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [PATCH] debian package upgrade restart issue

[nusenu]

>> When upgrading, all running tor instances are stopped (not restarted, as 
>> expected)
> 
> This might be your root-cause as well?
> 
> https://github.com/nusenu/ansible-relayor/issues/72
> 
> I'm generating instance names based on IP addresses_ORport (so they
> contain "." and "_") and are therefore filtered by the generator.
> 
> Is it acceptable to add "." and "_" to the whitelist?
> 
> (patches attached)

Based on the output of 'systemd-escape' (a tool that escapes strings for
use in unit names) it is safe to use "." and "_" in unit names.



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

Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6?

[teor]

> On 3 Aug 2016, at 10:29, teor  wrote:
> 
> Clients on 0.2.7.6 and earlier still use the IPv4 DirPort.
> (Tor Browser is still 0.2.7.6, and apps in general may take some time to 
> upgrade.)
> 
> Authorities on0.2.7.6 and earlier will only assign the HSDir flag to relays 
> with an IPv4 DirPort.
> (Authorities may take some time to upgrade, because running different 
> versions increases authority diversity.)

For the record, even though the man page entry for HidServDirectoryV2 says the 
DirPort is not required to be a HSDir, authorities on 0.2.7 and earlier still 
check for it before assigning the HSDir flag.

Authorities on 0.2.8 and later behave in a way that's consistent with 
HidServDirectoryV2, assigning the HSDir flag to any relay that wants to be a 
HSDir, and either supports being a directory cache, or has a DirPort.

HidServDirectoryV2 0|1
   When this option is set, Tor accepts and serves v2 hidden service
   descriptors. Setting DirPort is not required for this, because
   clients connect via the ORPort by default. (Default: 1)

> Fallback directory mirrors must have a DirPort, and we'd only think about 
> changing that when:
> * all recommended relay versions are 0.2.8 and later, and
> * relays no longer fetch documents using the DirPort (so maybe never).
> 
> All relays running any Tor version will continue to use the IPv4 DirPort to 
> fetch consensuses from other relays.
> 
> So we haven't obsoleted the IPv4 DirPort yet. We've just made sure that 
> clients fetch directory documents over an encrypted channel.

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays