Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:19:59Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28025unintended consequence of geographically distributed bandwidth servers: highe...2020-06-13T16:19:59Zstarlightunintended consequence of geographically distributed bandwidth servers: higher vote instabilityThe manner in which ticket #24674 was implemented has caused Torflow voting to become increasing unstable.
IIUC Torflow switches from one configured bandwidth server to the next in succession, but does not maintain separate sets of meas...The manner in which ticket #24674 was implemented has caused Torflow voting to become increasing unstable.
IIUC Torflow switches from one configured bandwidth server to the next in succession, but does not maintain separate sets of measurement data for each server. Thus if a scan is performed against a server in fast region such as central Europe and next in a slow region such as South America, new slow measurements are compared against the fast average bandwidth established in the preceding cycle, and vice-versa.
The moria1 scanner appears to recently have commenced operating with multiple servers configured while the maatuska scanner remains configured with one server. A recent synchronous pair of scan results from the two illustrates this problem and is attached. Moria1 results show much higher variance in pid_delta values than maatuska results: sorted by slice from highest down
moria1 pid_delta variances:
scanner1: 2.35 2.32 1.01 1.32 0.65 0.79 0.76 0.51 1.12 0.43
scanner2: 0.97 0.94
maatuska pid_delta variances:
scanner1: 0.31 0.42 0.41 0.41 0.26 0.27 0.38 0.49 0.28 0.36 0.34
scanner2: 0.42 0.36 0.46
At a minimum SBWS should address this issue by segregating measurment data by scanner.
For the present my opinion is that Torflow configurations should be reverted to one-server-per scanner to reduce vote instability and restore it to what it was before ticket #24674 was implemented.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/26675Incorrect ancillory data presented on Torflow guard relay "update" vote lines2020-06-13T16:19:58ZstarlightIncorrect ancillory data presented on Torflow guard relay "update" vote linesI realize little appetite exists for correcting Torflow issues at this juncture, but I came across an inexplicable behavior that is either my inability to unravel the code or a bug serious enough to merit fixing even at this stage of the...I realize little appetite exists for correcting Torflow issues at this juncture, but I came across an inexplicable behavior that is either my inability to unravel the code or a bug serious enough to merit fixing even at this stage of the new scanner development.
Investigating the scenario where the current measurement of a Guard relay is disregarded and instead the most recent voted measurement revised, I found this:
first archive appearance of new measurement vote
https://bwauth.ritter.vg/bwauth/bwscan.20180629-0645
```
1530271972
node_id=$4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2 bw=11500 nick=Binnacle measured_at=1530271632 updated_at=1530271632 pid_error=0.34411159803 pid_error_sum=0.34411159803 pid_bw=11467418 pid_delta=-0.0875088625329 circ_fail=0.0 scanner=/scanner.5/scan-data/bws-51.6:52.4-done-2018-06-29-06:27:12
@type server-descriptor 1.0
router Binnacle 108.53.208.157 443 0 80
published 2018-06-29 00:29:07
fingerprint 4F0D B7E6 87FC 7C0A E55C 8F24 3DA8 B0EB 27FB F1F2
bandwidth 1073741824 1073741824 8531597
```
first subsequent no-measurement vote update
https://bwauth.ritter.vg/bwauth/bwscan.20180701-0545
```
1530441163
node_id=$4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2 bw=20100 nick=Binnacle measured_at=1530271632 updated_at=1530439657 pid_error=0.34411159803 pid_error_sum=0.34411159803 pid_bw=11467418 pid_delta=-0.0875088625329 circ_fail=0.0 scanner=/scanner.4/scan-data/bws-38.6:39.4-done-2018-07-01-05:07:37
@type server-descriptor 1.0
router Binnacle 108.53.208.157 443 0 80
published 2018-06-30 12:30:08
fingerprint 4F0D B7E6 87FC 7C0A E55C 8F24 3DA8 B0EB 27FB F1F2
bandwidth 1073741824 1073741824 9458512
```
reading aggregate.py it appears this case his handled by lines 678-688 with kp=1 ki=0 and kd=0:
```
# Don't use feedback here, but we might as well use our
# new measurement against the previous vote.
n.copy_vote(prev_votes.vote_map[n.idhex])
if cs_junk.use_desc_bw:
n.new_bw = n.get_pid_bw(prev_votes.vote_map[n.idhex],
cs_junk.K_p,
cs_junk.K_i,
cs_junk.K_d,
0.0, False)
def get_pid_bw(self, prev_vote, kp, ki, kd, kidecay, update=True):
if not update:
return self.use_bw \
+ kp*self.use_bw*self.pid_error \
+ ki*self.use_bw*self.pid_error_sum \
+ kd*self.use_bw*self.pid_delta
line 591
n.use_bw = n.desc_bw
line 556
prev_votes = VoteSet(argv[-1])
line 205
try:
self.pid_error = float(re.search("[\s]*pid_error=([\S]+)[\s]*", line).group(1))
def copy_vote(self, vote):
self.new_bw = vote.bw*1000 # Not set yet
self.pid_bw = vote.pid_bw # Not set yet
self.pid_error_sum = vote.pid_error_sum # Not set yet
self.pid_delta = vote.pid_delta # Not set yet
```
My reading indicates `new_bw` is calculated by applying the last vote pid_error to the current descriptor bandwidth. Comment appears misleading, but the logic seems sensible enough.
Problem is that 9458512 + 9458512 * 0.34411159803 is 12713,296 rather than the published value of 20100. _If_ my understanding of the code is correct, the actual behavior here does not reflect the intended behavior and the result is egregiously incorrect. I suspect a bug, but the code is complex and in the absence of debugging a live Torflow instance my analysis could be wrong.
Perhaps Mike Perry could chime in here?Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24730Clarify the bandwidth authority spec to include client and server/service paths2020-06-13T16:19:57ZteorClarify the bandwidth authority spec to include client and server/service pathsIt's unclear whether the "average stream capacity regardless of path" includes the path from the client to the entry, and the exit to the internet server. Pragmatically, in the current design, it has to include client and internet server...It's unclear whether the "average stream capacity regardless of path" includes the path from the client to the entry, and the exit to the internet server. Pragmatically, in the current design, it has to include client and internet server. (Or, in the case of onion services, client and service.)
I don't know if this affects our design at all, but it should be clarified in the spec.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24674Bandwidth authorities should use geographically distributed bandwidth servers2020-06-13T16:19:57ZteorBandwidth authorities should use geographically distributed bandwidth serversWhen a bandwidth authority is configured with a nearby bandwidth server, it measures nearby relays really high.
Its measurements for those relays don't help "to balance load across the network such that a user can expect to have the sam...When a bandwidth authority is configured with a nearby bandwidth server, it measures nearby relays really high.
Its measurements for those relays don't help "to balance load across the network such that a user can expect to have the same average stream capacity regardless of path".
​https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.spec.txt#n353
Instead, bandwidth authorities should use a geographically distributed set of bandwidth servers. We can do this by:
* each operator setting up their own set of geographically distributed bandwidth servers
* using one or more CDNs (#24506)
* sharing the current bandwidth servers between bandwidth authorities
Ideally, every bandwidth authority would use the same set of bandwidth servers. That would eliminate one source of bias.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24506Move some bandwidth authority servers to a CDN2022-03-10T10:27:40ZteorMove some bandwidth authority servers to a CDNWe've experimented with using fastly as a bandwidth server.
Once the bandwidth authority code is stable, we should test this in parallel for a week or two, then make the switch.We've experimented with using fastly as a bandwidth server.
Once the bandwidth authority code is stable, we should test this in parallel for a week or two, then make the switch.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24499Bandwidth determination is flawed2020-06-13T16:19:55ZTracBandwidth determination is flawedI'm running a non-exit node in Australia. Please read "Australia" as a high latency area, that has not many other nodes around. I set RelayBandwidthRate to 1100, which is around 20% of my connection.
Just like all people who start up a ...I'm running a non-exit node in Australia. Please read "Australia" as a high latency area, that has not many other nodes around. I set RelayBandwidthRate to 1100, which is around 20% of my connection.
Just like all people who start up a new node, I was wondering why the bandwidth was not used. Unfortunately most information, that can be found about the topic on the web is very outdated and does not apply to my situation.
The measured bandwidth never exceeded 200 kb/s on atlas. So I decided to use my node as bridge and send junk traffic. Just downloading Ubnuntu and doing unnecessary uploades and running the CLI speedcheck script through the network. Now the nodes, that I am connected to, ackowledge, how much data can be send from/to my node and the bandwidth estimation on atlas suddenly goes up extremely. Beyond 500 (still not 1100 though).
I thought I fixed it and turn my dummy-traffic-script off again. Now the estimation is down again, my node is mostly unused and I'll probably turn it off soon as it is just a waste of electricity.
Apparently the bandwidth is measured in that useless 50-kilobytes-way, that the tor client does for the original setup. Well, sending 50 kilobytes to a node and measuring the time is mostly a test of latency. So the test is currently faulty, it should actually send a few megabytes, or anything that results in a few seconds of measurement. Additionally it should also send 1 byte, to measure the latency and deduct it from the other measurement.
Currently nodes in Australia, even if they have a high bandwidth fibre connection are largely disadvantaged. Only because the 'authorities' or the majority of the network is in Europe.
Please don't get me wrong. I understand that a extremely high latency is also bad. A 1 BGit/s connection is maybe not particularly useful if it has a latency of 30 seconds for each TCP packet. So latency should not go unnoticed. But you could at least be so kind and announce on your website, that nodes in Australia are not welcome and will be disadvantaged by the algorithm. Therefore people who live in areas like Australia (high bandwidth, high latency, high electricity costs) can at least be aware, that is is useless to run a node and they don't need to bother with it.
Problems:
1. The bandwidth estimation can be largely varied by sending unnecessary junk data over the tor network.
2. The bandwidth estimation WILL be influenced, because the network uses it as a measure to determine if a node is "good" or should be used a lot.
3. The bandwidth estimation measures latency and not bandwidth.
4. Nodes that don't have many other nodes near, will be marked as useless, will go unused and therefore be turned off soon.
5. The network will convert (or has already converted) to be concentrated in one location only, which is the highly connected areas in central Europe. The high speed nodes in North America are anyway on the ignore list of most people, right?
**Trac**:
**Username**: HasspredigerTom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24267bwauth scanner.9 fills disk again2020-06-13T16:19:55ZSebastian Hahnbwauth scanner.9 fills disk again```
Stream 30192 FAILED with TIMEOUT
Stream 30192 CLOSED with TIMEOUT
Wedged Tor stream. Closing all streams
mer exceeded limit: 360.031718016
Child Process Spawned...
Router B07569EDA6F8B7529F61136DE432536331191E16 changed names from U...```
Stream 30192 FAILED with TIMEOUT
Stream 30192 CLOSED with TIMEOUT
Wedged Tor stream. Closing all streams
mer exceeded limit: 360.031718016
Child Process Spawned...
Router B07569EDA6F8B7529F61136DE432536331191E16 changed names from UbuntuCore188 to UbuntuCore196
Router ABCD91C1DE58A91567E12F74AE1B82F8EB0F445E changed names from UbuntuCore188 to UbuntuCore196
No routers left after restrictions applied: NodeRestrictionList(['UnmeasuredPercentileRestriction(0,100)', 'OrNodeRestriction(["FlagsRestriction([\'BadExit\'],[])", \'ConserveExitsRestriction()\'])', "FlagsRestriction(['Running'],[])"])
No viable nodes in consensus for restrictions.
No routers left after restrictions applied: NodeRestrictionList(['UnmeasuredPercentileRestriction(0,100)', 'OrNodeRestriction(["FlagsRestriction([\'BadExit\'],[])", \'ConserveExitsRestriction()\'])', "FlagsRestriction(['Running'],[])"])
```
the last messages get repeated infinitely until the disk is fullTom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24248bwauth goes crazy in test network with no measured nodes2020-06-13T16:19:54ZSebastian Hahnbwauth goes crazy in test network with no measured nodesI have a small test network with 3 authorities, 5 Exits, 6 Fast relays, 3 Guards, 13 Running relays. Starting a bwauth leads to this and the last two log messages are repeated infintely, quickly filling my disk.
The network has nodes al...I have a small test network with 3 authorities, 5 Exits, 6 Fast relays, 3 Guards, 13 Running relays. Starting a bwauth leads to this and the last two log messages are repeated infintely, quickly filling my disk.
The network has nodes all living inside 10.0.0.0/8 address space but it's a real Tor network deployed over several machines.
The following options are set:
ExtendAllowPrivateAddresses 1
EnforceDistinctSubnets 0
ClientRejectInternalAddresses 0
ClientDNSRejectInternalAddresses 0
```
NOTICE[Sat Nov 11 16:13:10 2017]:TorFlow Version: master 75abb44bf73b3a061063145ebdb97029afe91fb7
NOTICE[Sat Nov 11 16:13:10 2017]:TorCtl Version: detached c8fcb25b079d52a20cafc7f7adf178e90ab76338
NOTICE[Sat Nov 11 16:13:10 2017]:Child Process Spawned...
NOTICE[Sat Nov 11 16:14:13 2017]:Starting slice for percentiles 0-100
NOTICE[Sat Nov 11 16:14:15 2017]:Ran out of choices in ExactUniformGenerator. Incrementing nodes
NOTICE[Sat Nov 11 16:14:15 2017]:Ran out of routers during buildpath..
NOTICE[Sat Nov 11 16:14:15 2017]:Ran out of choices in ExactUniformGenerator. Incrementing nodes
NOTICE[Sat Nov 11 16:14:15 2017]:Ran out of routers during buildpath..
```Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24242Resolve warnings on NEWCONSENSUS / NEWDESC events2020-06-13T16:19:53ZteorResolve warnings on NEWCONSENSUS / NEWDESC eventsI see hundreds of warnings like this whenever a new consensus arrives in the bandwidth scanner:
```
WARN[Sat Nov 11 23:03:55 2017]:Need to getinfo ns/id for router desc: 5EED8CE170B8889F6C041C26C934304FCCF02955
WARN[Sat Nov 11 23:03:55 2...I see hundreds of warnings like this whenever a new consensus arrives in the bandwidth scanner:
```
WARN[Sat Nov 11 23:03:55 2017]:Need to getinfo ns/id for router desc: 5EED8CE170B8889F6C041C26C934304FCCF02955
WARN[Sat Nov 11 23:03:55 2017]:NS map count of 6618 is below consensus count 6619
WARN[Sat Nov 11 23:03:55 2017]:No router desc for 602239BF846FA9A201E0ADA89FF83DC3E1F9766E after NEWDESC
```
We should either:
* fix the underlying issues that are causing these warnings, or
* downgrade them to NOTICE or INFOTom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24225Update torflow's TorCtl submodule to latest pytorctl version2020-06-13T16:19:53ZteorUpdate torflow's TorCtl submodule to latest pytorctl versionOnce we're happy with a set of pytorctl tickets, we should update the TorCtl submodule in torflow with the latest pytorctl commit, and push the submodule change to torflow master.Once we're happy with a set of pytorctl tickets, we should update the TorCtl submodule in torflow with the latest pytorctl commit, and push the submodule change to torflow master.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24224When a bwauthority circuit fails, it is very noisy2020-06-13T16:19:53ZteorWhen a bwauthority circuit fails, it is very noisyThis was logged for a single circuit failure when an outgoing connection was blocked by my firewall:
```
WARN[Fri Nov 10 23:14:36 2017]:Error building circ: ("551 Couldn't start circuit",)
NOTICE[Fri Nov 10 23:14:36 2017]:Closing stream ...This was logged for a single circuit failure when an outgoing connection was blocked by my firewall:
```
WARN[Fri Nov 10 23:14:36 2017]:Error building circ: ("551 Couldn't start circuit",)
NOTICE[Fri Nov 10 23:14:36 2017]:Closing stream 452
ERROR[Fri Nov 10 23:14:36 2017]:An unknown HTTP error occured
Traceback (most recent call last):
File "bwauthority_child.py", line 148, in http_request
reply = urllib2.urlopen(request, context=context)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
WARN[Fri Nov 10 23:14:36 2017]:No circuit for 452 circ: 0
WARN[Fri Nov 10 23:14:36 2017]:Stream 452 FAILED from no circuit with reason: DESTROY
WARN[Fri Nov 10 23:14:36 2017]:No circuit for 452 circ: 0
WARN[Fri Nov 10 23:14:36 2017]:Stream 452 CLOSED from no circuit with reason: DESTROY
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 447, in _open
'_open', req)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1241, in https_open
context=self._context)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1195, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1042, in request
self._send_request(method, url, body, headers)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1082, in _send_request
self.endheaders(body)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1038, in endheaders
self._send_output(message_body)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 882, in _send_output
self.send(msg)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 844, in send
self.connect()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1255, in connect
HTTPConnection.connect(self)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 821, in connect
self.timeout, self.source_address)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 566, in create_connection
sock.connect(sa)
File "../libs/SocksiPy/socks.py", line 369, in connect
self.__negotiatesocks5(destpair[0],destpair[1])
File "../libs/SocksiPy/socks.py", line 236, in __negotiatesocks5
raise Socks5Error((ord(resp[1]),_socks5errors[ord(resp[1])]))
Socks5Error: (1, 'general SOCKS server failure')
```Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24223bwauths can output percentile ranges greater than 1002020-06-13T16:19:52Zteorbwauths can output percentile ranges greater than 100Split off #4269:
Also related to this is that we can output seemingly nonsensical result files at the end of the scan for percentile ranges of 99-102. The result files contain valid data, but perhaps we should have lumped it in with the...Split off #4269:
Also related to this is that we can output seemingly nonsensical result files at the end of the scan for percentile ranges of 99-102. The result files contain valid data, but perhaps we should have lumped it in with the previous slice if it either has no exits or is below a minimum size?Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24221gitignore more things in torflow2020-06-13T16:19:52Zteorgitignore more things in torflowTom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24219Avoid aggregate.py error when no nodes are measured2020-06-13T16:19:51ZteorAvoid aggregate.py error when no nodes are measuredIf the scanner cron runs early, errors like this can happen:
```
Traceback (most recent call last):
File "/Users/bwauth/torflow/NetworkScanners/BwAuthority/aggregate.py", line 894, in <module>
main(sys.argv)
File "/Users/bwauth/t...If the scanner cron runs early, errors like this can happen:
```
Traceback (most recent call last):
File "/Users/bwauth/torflow/NetworkScanners/BwAuthority/aggregate.py", line 894, in <module>
main(sys.argv)
File "/Users/bwauth/torflow/NetworkScanners/BwAuthority/aggregate.py", line 798, in main
nodes.itervalues())))
ValueError: min() arg is an empty sequence
```https://gitlab.torproject.org/legacy/trac/-/issues/24216Make p global in the sigterm handler2020-06-13T16:19:51ZteorMake p global in the sigterm handlerThis causes errors like:
```
./bwauthority.py:71: SyntaxWarning: name 'p' is assigned to before global declaration
global p
```
in some recent python versions.
It appears to be one of those lovely python hiesenbugs that appears and di...This causes errors like:
```
./bwauthority.py:71: SyntaxWarning: name 'p' is assigned to before global declaration
global p
```
in some recent python versions.
It appears to be one of those lovely python hiesenbugs that appears and disappears depending on python version, OS, and other code changes.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24094measured bw percentage is always 1002020-06-13T16:19:50ZSebastian Hahnmeasured bw percentage is always 100Using tor 0.3.1.7, I get this right from the first start:
NOTICE[Tue Oct 31 12:45:15 2017]:Measured 100.0% of all tor nodes (100.0% of previous consensus bw).
the bwscan-file is produced but only contains 400 lines.Using tor 0.3.1.7, I get this right from the first start:
NOTICE[Tue Oct 31 12:45:15 2017]:Measured 100.0% of all tor nodes (100.0% of previous consensus bw).
the bwscan-file is produced but only contains 400 lines.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24091Recommend system-installed tor2020-06-13T16:19:50ZSebastian HahnRecommend system-installed torPointing the bwauth at a system-installed tor should not cause any trouble, I've been running the older code with that for years and the new code seems to work too. Just set TOR_EXE to the absolute path of the system tor.Pointing the bwauth at a system-installed tor should not cause any trouble, I've been running the older code with that for years and the new code seems to work too. Just set TOR_EXE to the absolute path of the system tor.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24090Remove default bwserver2020-06-13T16:19:49ZSebastian HahnRemove default bwserverBy not providing a bwserver in the config, we can make sure people actually think about what they want to use. That's much better than them accidentally all using the same one.By not providing a bwserver in the config, we can make sure people actually think about what they want to use. That's much better than them accidentally all using the same one.Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24089requirements.txt uses peep format2020-06-13T16:19:49ZSebastian Hahnrequirements.txt uses peep formatpeep is deprecated and shouldn't be used if at least pip 8 is available (even stretch has pip 9 already). Also, it sets --no-index which prevents it from working and --no-use-wheel which is unnecessary when using pip.
This could be the ...peep is deprecated and shouldn't be used if at least pip 8 is available (even stretch has pip 9 already). Also, it sets --no-index which prevents it from working and --no-use-wheel which is unnecessary when using pip.
This could be the file:
```
pysqlite==2.6.3 --hash=sha256:fe9c35216bf56c858b34c4b4c8be7e34566ddef29670e5a5b43f9cb8ecfbb28d
SQLAlchemy==0.7.10 --hash=sha256:77aa39d65c9d043eba6ba329b359ff867424fd6c403b7c0cb112b65e507e1d66
Elixir==0.7.1 --hash=sha256:a7ef437f25b544e4f74fb3236fc43cd25f5d6feb6037dd7c66931046d75439e9
```Tom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/legacy/trac/-/issues/24088Remove setup.sh2020-06-13T16:19:48ZSebastian HahnRemove setup.shSetting up a real bwauth shouldn't hide steps from the operator. It's important the operator knows what software plays a part, which parts won't get updated by themselves, etc. setup.sh hides all that from the operator and makes bad assu...Setting up a real bwauth shouldn't hide steps from the operator. It's important the operator knows what software plays a part, which parts won't get updated by themselves, etc. setup.sh hides all that from the operator and makes bad assumptions on top (it forces installation of deprecated dependencies that touch the network like an old version of pip and peep which has also been deprecated gets installed needlessly as well).Tom Rittertom@ritter.vgTom Rittertom@ritter.vg