Opened 6 years ago

Closed 6 years ago

#7826 closed defect (implemented)

Specs contain undocumented "ipv6-policy" lines

Reported by: atagar Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay doc tor-spec
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Oh how I love stem's descriptor tests. They're so wonderfully nit-picky.

The server descriptor for toorvoid (an IPv6 exit using Tor 0.2.4.7-alpha) contains an "ipv6-policy" line. This is mentioned in proposal 208 (IPv6 Exits Redux) but is not yet in the specs.

The spec has frequently been missing new tor additions. Is there anything that we can do to fix that? I flag spec changes in my email to make the corresponding changes in stem, so if the spec doesn't change then I'm unaware of it.

Here's the full descriptor...

@downloaded-at 2012-12-30 07:24:36
@source "188.138.104.154"
router toorvoid 83.212.96.201 443 0 993
or-address [2001:648:2ffc:1112:a80c:eaff:feda:b0db]:443
platform Tor 0.2.4.7-alpha on Linux
protocols Link 1 2 Circuit 1
published 2012-12-29 16:14:48
fingerprint 0B37 3232 98FF 98CD 86ED 4048 95BB 27B7 426E 8AE1
uptime 233569 
bandwidth 8704000 9216000 4171880
extra-info-digest 005AA0068E524A900D09FD949D1DB14C745B34E0
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAO0kckCtEvVIBVi+du47U/C7u1Ybal/Zl6XGTKh2C0yu1Iey32iwj/o9
pIHq3T7GdU9ZzwYSAsXSuDUN2g2D9B2kDHqO1k8DIfXDV/M8E+vpnuQ7dHNjJOBL
kLmxftOrf2eFr41lQyRQQ31IxojPPHSAIKhiEYrBSlOK0/fAvU2jAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMTezvB8ykqV7SpS4Lzv55UJnLy6PjSTirsYiUAFoAbMwr1vrQNPvDcd
8AAjgYZqUheCfrPffry/aAswS2QKSeYToFaCr1OGQ36xCWjXQLNS39RnnkXgVqqW
UefHaELcQ8FVUnr9vyIPCRJCFhpXrvK9G/ayZ0dass2vPrlLw3uFAgMBAAE=
-----END RSA PUBLIC KEY-----
family $7C312668970B5AA53DF89BD6B5394ED9019124D2
hidden-service-dir
contact 1024D/E4F4FFE6
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject 83.212.96.201:*
accept *:22
accept *:23
accept *:53
accept *:80
accept *:110
accept *:143
accept *:443
accept *:993
accept *:995
accept *:6667
accept *:6668
accept *:6669
accept *:6666
accept *:7000
accept *:8080
accept *:8443
accept *:554
accept *:1755
reject *:*
ipv6-policy accept 22-23,53,80,110,143,443,554,993,995,1755,6666-6669,7000,8080,8443
router-signature
-----BEGIN SIGNATURE-----
ejUGInU/ZbOOAACyC/coUJMg7r9obKLRRLef7aj6XjSUv6uKnvIyKEcXQVagjj0v
jc3os/aEbVHprOcjcTs0JIwOyII3c8s/7Zm5dtXgDnGrmKNiwktKmjAQ2swCKntA
vyWMrp2iqiKPsLTTMk0lZRZe105Dh9X/bhv23FAu/qs=
-----END SIGNATURE-----

Child Tickets

Change History (5)

comment:1 in reply to:  description Changed 6 years ago by nickm

Keywords: tor-relay spec doc added
Milestone: Tor: 0.2.4.x-final

Replying to atagar:

The spec has frequently been missing new tor additions. Is there anything that we can do to fix that? I flag spec changes in my email to make the corresponding changes in stem, so if the spec doesn't change then I'm unaware of it.

So, canonically the workflow is that any feature involving a change to a protocol starts life as a proposal. When it's implemented, the proposal's status becomes "finished." When any/all spec changes are merged, the proposal's status becomes "closed". So if you flag proposal status changes, that would give you another thing to see.

comment:2 Changed 6 years ago by nickm

Keywords: tor-spec added; spec removed

Bulk-replacing "spec" and "torspec" keywords with "tor-spec".

comment:3 Changed 6 years ago by nickm

Status: newneeds_review

I did this as part of ef5513b1ad3671153f20b3c3929e1acba1b873bc in branch "more-specs" in my public repository. (It's based on branch "document-ntor" for #8122).

comment:4 Changed 6 years ago by atagar

Commit ef5513b looks good to me. Thanks!

comment:5 Changed 6 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged; thanks!

Note: See TracTickets for help on using tickets.