Opened 7 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 Changed 7 years ago by
| Keywords: | tor-relay spec doc added |
|---|---|
| Milestone: | → Tor: 0.2.4.x-final |
comment:2 Changed 7 years ago by
| Keywords: | tor-spec added; spec removed |
|---|
Bulk-replacing "spec" and "torspec" keywords with "tor-spec".
comment:3 Changed 6 years ago by
| Status: | new → needs_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:5 Changed 6 years ago by
| Resolution: | → implemented |
|---|---|
| Status: | needs_review → closed |
Merged; thanks!
Replying to atagar:
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.