- 29 Jul, 2018 2 commits
-
-
Karsten Loesing authored
Implements another part of #23713.
-
Karsten Loesing authored
Implements part of #23713.
-
- 24 Jul, 2018 1 commit
-
-
Karsten Loesing authored
Implements #25448.
-
- 16 Jul, 2018 1 commit
-
-
Karsten Loesing authored
-
- 13 Jul, 2018 1 commit
-
-
Iain R. Learmonth authored
The filter is applicable to both bridges and relays. It uses basic string operations to extract the operating system from the platform line of descriptors. Fixes: #6946
-
- 11 Jul, 2018 1 commit
-
-
Karsten Loesing authored
A missing descriptor directory has caused an IllegalStateException when we attempted to write our parse history files. Let's be more careful about this case and skip this history file if there is no such directory. Fixes #26711.
-
- 10 Jul, 2018 1 commit
-
-
Iain R. Learmonth authored
Indexes are created for relays with no known country code or autonomous system number using the special values "xz" and "AS0" respectively. No changes are made to the summary or details documents. Fixes: #26665
-
- 09 Jul, 2018 1 commit
-
-
Iain R. Learmonth authored
This commit adds two new fields: {un,}verified_host_names. Whereas previously InetAddress was used to resolve reverse domain names, this instead changes the lookup mechanism to use JNDI allowing for a deeper view into the DNS. It also accounts for the fact that multiple PTR records are not forbidden in the DNS specification and are often used in shared hosting scenarios. A host name is considered verified if it has a matching forward record. If a PTR value is found to have multiple A records, it will be considered verified if any one of the A records matches the original address. If no matching record is found, it will be reported as an unverified host name. Previously, unverified host names were discarded internally by the InetAddress lookup mechanism and so this data could not be used. To maintain "bug compatibility" with the previous implementation of the "host_name" field, which will now be deprecated, the IP address is returned when a lookup fails. The host_name field continues to be used, but now will consider all verified and unverified host names. If finer grained filtering is needed, then a seperate ticket could be filed for that, but it is unclear that it is useful enough to justify the work. Fixes: #18342
-
- 29 May, 2018 2 commits
-
-
Karsten Loesing authored
-
Karsten Loesing authored
Update metrics-lib dependency to 2.4.0. Adapt touched logging statements to our standards. Implements #25848.
-
- 17 Apr, 2018 2 commits
-
-
Karsten Loesing authored
-
Karsten Loesing authored
Fixes #25332.
-
- 16 Apr, 2018 1 commit
-
-
iwakeh authored
Also adapt tests to check the new functionality. Implements task-25740.
-
- 06 Apr, 2018 1 commit
-
-
Karsten Loesing authored
-
- 05 Apr, 2018 1 commit
-
-
Karsten Loesing authored
Fixes #25700.
-
- 04 Apr, 2018 1 commit
-
-
Karsten Loesing authored
Implements #24256.
-
- 27 Mar, 2018 1 commit
-
-
iwakeh authored
Add a utility method for only un-escaping valid utf and supply a test as well as test data for this issue. Fixes task-22594.
-
- 13 Mar, 2018 3 commits
-
-
Karsten Loesing authored
-
Karsten Loesing authored
-
iwakeh authored
Part of task-25002.
-
- 08 Mar, 2018 1 commit
-
-
Karsten Loesing authored
-
- 07 Feb, 2018 3 commits
-
-
Karsten Loesing authored
-
Karsten Loesing authored
-
Karsten Loesing authored
Rather than on system time we're now depending on the last time a relay or bridge was seen in a consensus or status to determine when history ends for this relay. This has the advantage of making the write step deterministic, and it produces the exact same graph intervals for the different documents of a given relay or bridge. A minor downside is that we're now depending on node statuses _and_ another status file in order to produce a history document. Should be okay. Define graph end as last full data point before the relay/bridge was last seen. Also make sure that graphs end at that defined graph end and do not continue just because there's more history available. This is mostly to exclude falsely-reported statistics. Implements #16513.
-
- 20 Dec, 2017 1 commit
-
-
Karsten Loesing authored
-
- 28 Nov, 2017 1 commit
-
-
Karsten Loesing authored
-
- 18 Nov, 2017 4 commits
-
-
Karsten Loesing authored
Add a "recommended_version" parameter to return only relays and bridges running a Tor software version that is recommended or not recommended by the directory authorities. Implements #23544.
-
Karsten Loesing authored
Add a "recommended_version" field to bridge details documents based on whether the directory authorities recommend the bridge's version. Implements #21827.
-
Karsten Loesing authored
Extend the "version" parameter to also return bridges with the given version or version prefix. Implements #23962.
-
Karsten Loesing authored
Add a "version" field to relay details documents with the Tor software version listed in the consensus and similarly to bridge details documents with the Tor software version found in the server descriptor. Implements #22488.
-
- 17 Nov, 2017 4 commits
-
-
Karsten Loesing authored
-
Karsten Loesing authored
-
Karsten Loesing authored
Implements #21637.
-
Karsten Loesing authored
Implements #16553.
-
- 03 Nov, 2017 1 commit
-
-
Karsten Loesing authored
-
- 30 Oct, 2017 1 commit
-
-
Karsten Loesing authored
With this patch, the "search" parameter does not only accept unquoted qualified search terms like `search=contact:John Doe` where "John" would be looked up in the contact line and "Doe" in the nickname or base64-encoded fingerprint. It also accepts quoted qualified search terms like `search=contact:"John Doe"` where "John Doe" would be looked up in the contact line. It further accepts escaped double quotes (\") within quoted qualified search terms. Implements #21366.
-
- 26 Oct, 2017 1 commit
-
-
Karsten Loesing authored
There's a relay running an alternate Tor version that produces descriptors without "uptime" line, and the directory authorities don't include a "v" line for that relay, likely because its platform string does not include the magic word "Tor". Fixes #24012.
-
- 09 Oct, 2017 1 commit
-
-
Karsten Loesing authored
-
- 19 Sep, 2017 2 commits
-
-
iwakeh authored
Implements task-23778.
-
Karsten Loesing authored
When we set this field in the update process, we only looked whether the bridge is contained in the last known bridge network status. We also need to check whether it has the "Running" flag assigned there. This is different from relays, because the consensus only lists relays with the "Running" flag since a couple of years, whereas the bridge network status lists all known bridges. Fixes #23467. Spotted by nusenu.
-