[tor-bugs] #22755 [Obfuscation/BridgeDB]: Use stem to create test descriptors
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Jul 7 02:22:35 UTC 2017
#22755: Use stem to create test descriptors
-------------------------------------------------+-------------------------
Reporter: atagar | Owner: isis
Type: enhancement | Status:
| needs_revision
Priority: Low | Milestone:
Component: Obfuscation/BridgeDB | Version:
Severity: Minor | Resolution:
Keywords: python, stem, bridgedb-parsers, | Actual Points:
bridgedb-ci |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by isis):
Hey Damian!
This is great!
[https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=feature/22755
-stem-descgen&id=5c67343191680326f2ea2ec1c880d41cbe47a58e I changed it a
bit] to write the descriptors all into the same files, the same way as the
files which come in to BridgeDB from the BridgeAuth.
Now that [https://travis-ci.org/isislovecruft/bridgedb/builds/250994880 CI
is slightly more happy], on to other review:
1. Is there a way to make the descriptors less sparse? Currently, the
server descriptors created by leekspin look like this:
{{{
@purpose bridge
router Attenuated 102.137.125.126 46184 0 0
or-address [9246:a438:f18e:8d3b:7057:68e2:3d1b:7945]:46183
platform Tor 0.2.4.5-alpha on Linux
protocols Link 1 2 Circuit 1
published 2017-07-06 07:10:48
fingerprint A5E0 18E5 60A0 BF4F 4C58 1774 B7B4 7F9D 2F09 CA49
uptime 35532496
bandwidth 737300203 833469795 641130611
extra-info-digest FDC1467C0EFEBCB9DF72A44222A8902EB65F019C
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAJsZUONLz6jmxwqvBfIU1C/6uAOq9mrjdsjIKztfqg8nCj8SS1yIsJIO
cweUOq1c0AjZQQrJPqM70V1IgfdqZ8oVhwFi81OJ3qJE5oJsWtVwHDL0mIfUhJlg
IRIqKY4wkl8KmVRlCM90jYqIO04DDrO+B3+/94KmAropRJUS8XHNAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALhm+utng4Wvm29HgLlsnuczcLE56etkRmkWLWXM/3K7zKS48X6rcWB+
O3O5IeV9caCpvPT4Z1p11IqiFVAeeXqUWbjc338M4H9yzTBeV23aSCFzUiKQOgq5
95atzhSYgi1lyPz1xpIwE/nDFZ8l6WiahDJ3ipFaRhcLJzCJDtchAgMBAAE=
-----END RSA PUBLIC KEY-----
contact Somebody <somebody at example.com>
reject *:*
router-signature
-----BEGIN SIGNATURE-----
TJ0d8FkDeLB0cistB3lBlNKsVyLORZ+yNNyBti8jEnNBKxXXk6Nvma1zC8G/Ksym
34K1DhXmNpkb07QHYJbteiAhxOW1JIQztkdUGQ1YaUMJdUhu6RIbsAY2U79W4FtU
6Sc4SQw24TQ8udvpyUQut09LrEu86KaVjYqMHmrTHmo=
-----END SIGNATURE-----
}}}
Whereas the new Stem-produced ones are like this:
{{{
router Unnamed101110983533 158.165.189.89 9001 0 0
published 2011-08-17 12:24:06
bandwidth 153600 256000 104590
reject *:*
onion-key
-----BEGIN RSA PUBLIC KEY-----
bymUV231gjwnd3ao0Qclm2JmvRH7J6pLv5xhWqD53KbRpkO60Fx/NSAvpOEf7+lG
gzFLmVp7mmUZI376ahK0FhKnOVO3wU2kdBAhNgecolI0wnjhP5dMu63ZfBKMOojh
V8WB8rCZXY++rSQ8c4WHtptWWlAcOj0FjTBtNYgL/MjGwK9jth2PpcEVkj8=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMwcInNw3myp4w9XJ3dFz43Dwr9bVqVT3L2rmgogU15sycj3Ng/NOvWz
ryJWoW8OmeBSuIEeRpBLKPKfB+wejgyFtAPgf82GJnv2jGxh2ISZ1JTH39lMYjzq
JySh2cUdDTbBSwJwRfTgfXe39ARWvySH3tubAh3nxmQ9GC8Rsnf7AgMBAAE=
-----END RSA PUBLIC KEY-----
fingerprint 0B87 6476 CECC 5DB8 3D39 9E3B F9B6 E689 DB2A CA1D
router-signature
-----BEGIN SIGNATURE-----
WX6uMBUPvhuVkGLyJ9R0s6K1lCMXXom9rZd1LYDAMVUhwaytaaGX5HzWsq8bgUUC
r7BvN2o+FmjRDdni9C1cHIU3GwNUgAhMAUa14VSdQiawEvegjRQCR8oNydODM1z4
Xf6jP3tTku0L47bhWFLipWVAOCH6z/lnmK1etAjSZ60=
-----END SIGNATURE-----
}}}
And a real bridge server descriptor for
[https://atlas.torproject.org/#details/8173D41CDD86471F2BA86B6C5B661EAE813A306E
noether, one of the default Tor Browser bridges] is like so:
{{{
@purpose bridge
router noether 192.99.11.54 63848 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABlybAYL6e+WjJYnWXtD2/bEhTQyikmzNUHWR4xxU5igkPzgdAQAgBADFQnrw
B0ffcBEUpeWZM2Y8H0qhvgB+r7fh4FcaLQv0EczLikcu5s8hqoKBT8+8o+QT2RRM
W7kH0XNRm9QL0vCO1wiXwEXm4nGE9gMCKu5//ttTolCPt2dcNIdyw3PNxQU=
-----END ED25519 CERT-----
master-key-ed25519 xUJ68AdH33ARFKXlmTNmPB9Kob4Afq+34eBXGi0L9BE
platform Tor 0.2.8.7 on Linux
protocols Link 1 2 Circuit 1
published 2017-07-06 15:52:40
fingerprint 7B12 6FAB 960E 5AC6 A629 C729 434F F84F B507 4EC2
uptime 26600081
bandwidth 1073741824 1073741824 9520756
extra-info-digest 9AFBEFB604AED8846C433DE19ED5BEAE630F0F40
CLpvIYPSqIh/eBYdTkuzTB4sxOkIiHP5CeJssYvILaw
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMWQ2jIGdJd6YvpIJSZYy/ELzuXX/FR3QoKpXvsxJNRxNkYmvOAAsm2E
puRI2Xznm0q1YUiufDUHfG7J0x/N1AhZrfpYbcbQCtIhDCr2l7b6IpMENdts8bWv
T5eXkUwXv/7Eb0Ur2HaLkGuACYN1Sd38/VQQLK0mXBRavkGgrd2HAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALbDk5BGi0N8V0eOoQTmOdw6CgkzeRjnMaEOAQpYRCbUnI0XVUjIMqA7
LHo7vbB91YCKZa1zsR2iKh5AnrrWe5wpLujMSRZA2yqwLW3V8/1fltF/1IndGlQD
okZr2uRNnDUKRckZzF4Naoo4PAzH9PT4wDSPzkPj+qENUdTWLlsnAgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
Qvi+cyQnlsThRnW/kiuhNf2LHzTZoPM/aqQbE4gvncEWP8CQc0XmtPkoCHlea3nZ
O3Dq6pGK8BDzK2DgYS1ZcpO9aPH9GfycZot1xEkg+z0NOYs3aoRZlM3skkLCWmgo
Hym76SzFMefH0vLWHfdSIsoqS+Tx/k59s12IZa5jZx8=
-----END CROSSCERT-----
ntor-onion-key-crosscert 0
-----BEGIN ED25519 CERT-----
AQoABluQAcVCevAHR99wERSl5ZkzZjwfSqG+AH6vt+HgVxotC/QRAKX3/P8JXZGs
TeOtNdPAIP96eWyZUBUksMsP535aQiJolw9nFR5bFswdX08GbQ3xwZ4zNzosDi77
qtUaywjC9AA=
-----END ED25519 CERT-----
hidden-service-dir
contact Henry de Valence <tor at hdevalence.ca>
ntor-onion-key xxgycE7BKQguv+uVqoAwwkb4tv9BOh5p9vH9MBo8M2w=
reject *:*
tunnelled-dir-server
router-sig-ed25519
ZU/p6qvbgdSdQfXC6/IBzk/gF7WYHXCzzOcQfkw3H3RvYRdICHnzNl0W0/Cty0Ks9hLYo3BWkCYuoMgvfsbeDQ
router-signature
-----BEGIN SIGNATURE-----
grlgvXFB337Sxj5J07Q3cC9sI57JB07dIlFHCWTAS4N30F6GgB/7WDUtpxG9DFwJ
ZomIdO5vA9AKfVarlnJFqF8Ks4IfJafqhi5mX+Qgr7ppfuwQc10UNIfJrADZXJP+
00HSOsQP0T9ZpLQz3BquMIQjHiWkc9fDXu3fZ12EaFM=
-----END SIGNATURE-----
}}}
I'm a bit scared of exercising less of the parsing code if the
descriptors are more sparse.
2. Same as above but for the extrainfo descriptors. (I'll attach all of
noether's descriptors in a second so that there's some good examples.)
3. Sort of inline with the last two things, we need the `extra-info-
digest` lines in the server descriptors for BridgeDB to know which extra
info is correct.
4. Some CI tests are broken because the extrainfo descriptors don't mock
`transport` lines.
5. Something is writing all the server and extrainfo descriptors to disk
in separate files, e.g. `server_descriptor_{0,1,2,…}` and
`extrainfo_descriptor_{0,1,2,…}`; is there a way to disable that?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22755#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list