The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-05-16T19:28:57Zhttps://gitlab.torproject.org/tpo/web/blog/-/issues/40049make it possible to publish "same-day" posts2023-05-16T19:28:57ZIsabela Fernandesmake it possible to publish "same-day" postsHi there, this is a report from the comms team. Please keep in mind that the use case here is of a user that does not know command line.
- [x] web IDE crashes the browser because it requires so many resources from the computer. It take...Hi there, this is a report from the comms team. Please keep in mind that the use case here is of a user that does not know command line.
- [x] web IDE crashes the browser because it requires so many resources from the computer. It takes forever to load (15-45minutes) after many attempts. This is just to get to a place where you can upload an image, if an error occurs you have to start all over again. **action point**: document in a new issue in https://gitlab.torproject.org/tpo/web/lego/-/issues, see if it's possible to use lektor locally?
- [ ] takes ~15-30 minutes to upload a preview. normally the workflow involves a lot of back and forward with preview to fix markup mistakes. this 'editing and previewing' process ends up taking hours. **action point**: document in https://gitlab.torproject.org/tpo/web/blog/-/issues/40015
- [ ] if something in the build process breaks and the preview doesn't populate, it is not possible to tell what is wrong and more time is lost in figuring what to fix **action point**: document in a new issue in https://gitlab.torproject.org/tpo/web/blog/-/issues/
- [ ] doing anything more than adding a lead image (e.g., adding images inline, hyperlinking an inline image, resizing something) takes a
mixture of markup and HTML, which requires a lot of trial and error (see second item) **action point**: see if it's possible to use lektor locally?
- [ ] we always depend on a person to finalize the process, you have to (a) ask a web person to merge the request (b) keep checking the website for an hour+ to ensure its there (c) often ask the person to do another step to *actually* make the post live because something was forgotten in the merge process. this adds up to the time to complete the task. **action point**: request access to the web team
- [ ] currently is almost impossible to guarantee a post can be published on the "day-of", to do that we need to mobilize a lot of time to make sure the task can be done. **action point**: fix all of the above issues. :smile:Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/network-health/team/-/issues/264Create rust guidelines2023-05-16T14:43:31ZjugaCreate rust guidelinesIn a similar way to https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Python-guidelines.In a similar way to https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Python-guidelines.jugajugahttps://gitlab.torproject.org/tpo/core/arti/-/issues/856Ensure stable features don't depend on experimental ones.2023-05-16T11:09:18Zgabi-250Ensure stable features don't depend on experimental ones.For example, `tor-hsclient` depends on the `experimental-api` feature from `tor-error`. We should fix this before the next release.For example, `tor-hsclient` depends on the `experimental-api` feature from `tor-error`. We should fix this before the next release.https://gitlab.torproject.org/tpo/web/community/-/issues/310Remove check of Faravahar's IPv6 address on the relay post-install page2023-05-15T12:55:23ZGeorg KoppenRemove check of Faravahar's IPv6 address on the relay post-install pageSection 7 on https://community.torproject.org/relay/setup/post-install/ provides some IPv6 check command. However, executing the command results in an error as Faravahar is gone. Thus, we should at least update that command to exclude Fa...Section 7 on https://community.torproject.org/relay/setup/post-install/ provides some IPv6 check command. However, executing the command results in an error as Faravahar is gone. Thus, we should at least update that command to exclude Faravahar's IPv6 address.
Noted in our forum: https://forum.torproject.net/t/directory-authority-ipv6-2607154-3-unreachable/7222https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/42Don't log to logcat, or otherwise redact logs, in production builds2023-05-13T17:45:35ZetaDon't log to logcat, or otherwise redact logs, in production buildsOur logcat logs (from Rust and Java) contain a significant amount of information about what hosts the user is connecting to, etc. This is fine and useful for development, but we should take care to sanitize this before production; otherw...Our logcat logs (from Rust and Java) contain a significant amount of information about what hosts the user is connecting to, etc. This is fine and useful for development, but we should take care to sanitize this before production; otherwise, this is a massive information disclosure problem waiting to happen!
see also https://developer.android.com/topic/security/risks/log-info-disclosureOnionmasq 1.0.0: Initial releaseetaetahttps://gitlab.torproject.org/tpo/web/community/-/issues/259What happens to bad relays - outdated2023-05-11T18:39:05ZcypherpunksWhat happens to bad relays - outdatedThe page https://community.torproject.org/relay/community-resources/bad-relays/ lists three things that can happen with bad relays: BadExit, Invalid and Reject. As of now, relay cannot be made Invalid (since proposal 272), but can (or no...The page https://community.torproject.org/relay/community-resources/bad-relays/ lists three things that can happen with bad relays: BadExit, Invalid and Reject. As of now, relay cannot be made Invalid (since proposal 272), but can (or not yet? should be clarified) become MiddleOnly.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40781build boxes fail to update ubuntu chroots since bullseye upgrade2023-05-08T18:56:07Zanarcatbuild boxes fail to update ubuntu chroots since bullseye upgradeever since we upgraded the buildbox servers, we've been getting regular errors like this by email:
```
E: specified keyring file (/usr/share/keyrings/ubuntu-archive-keyring.gpg) not found
```
That's because the [ubuntu-keyring package]...ever since we upgraded the buildbox servers, we've been getting regular errors like this by email:
```
E: specified keyring file (/usr/share/keyrings/ubuntu-archive-keyring.gpg) not found
```
That's because the [ubuntu-keyring package](https://tracker.debian.org/pkg/ubuntu-keyring) was [removed from bullseye in 2019](https://tracker.debian.org/news/1047972/ubuntu-keyring-removed-from-testing/) because of a [release critical bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929165) that is still not fixed.
It looks like that specific bug requires some hacks with debhelper to be fixed, it would be nice of us to provide a patch to the package to implement those fixes. Alternatively, we could also use the package from buster, but that is bound to eventually bitrot as well.
@weasel also suggested turning off those chroots, but i'm not exactly sure how to do that myself, so I assigned him this ticket.
The full log is:
```
From: root@ci-runner-arm64-02.torproject.org (Cron Daemon)
Subject: Cron <root@ci-runner-arm64-02> sleep $((RANDOM % 36000)) && chronic setup-all-dchroots
To: root@ci-runner-arm64-02.torproject.org
Date: Wed, 01 Jun 2022 05:54:11 +0000
E: specified keyring file (/usr/share/keyrings/ubuntu-archive-keyring.gpg) not found
E: specified keyring file (/usr/share/keyrings/ubuntu-archive-keyring.gpg) not found
E: specified keyring file (/usr/share/keyrings/ubuntu-archive-keyring.gpg) not found
E: specified keyring file (/usr/share/keyrings/ubuntu-archive-keyring.gpg) not found
+ debootstrap --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --include=apt,gnupg,ca-certificates,apt-transport-https --variant=buildd --arch=arm64 xenial /srv/chroot/schroot-unpack/create-xenial-MqyCRi http://ports.ubuntu.com/ubuntu-ports /usr/share/debootstrap/scripts/xenial
+ do_cleanup
+ local cnt
+ cnt=2
++ seq 2 -1 0
+ for i in $(seq ${cnt} -1 0)
+ umount /srv/chroot/schroot-unpack/create-xenial-MqyCRi/sys
umount: /srv/chroot/schroot-unpack/create-xenial-MqyCRi/sys: no mount point specified.
+ true
+ for i in $(seq ${cnt} -1 0)
+ rm -r /srv/chroot/schroot-unpack/create-xenial-MqyCRi
+ for i in $(seq ${cnt} -1 0)
+ :
Error: setting up xenial:arm64 dchroot failed.
WARNING: tempfile is deprecated; consider using mktemp instead.
+ debootstrap --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --include=apt,gnupg,ca-certificates --variant=buildd --arch=arm64 bionic /srv/chroot/schroot-unpack/create-bionic-C1udMW http://ports.ubuntu.com/ubuntu-ports /tmp/fileqy2Sje
+ do_cleanup
+ local cnt
+ cnt=3
++ seq 3 -1 0
+ for i in $(seq ${cnt} -1 0)
+ rm /tmp/fileqy2Sje
+ for i in $(seq ${cnt} -1 0)
+ umount /srv/chroot/schroot-unpack/create-bionic-C1udMW/sys
umount: /srv/chroot/schroot-unpack/create-bionic-C1udMW/sys: no mount point specified.
+ true
+ for i in $(seq ${cnt} -1 0)
+ rm -r /srv/chroot/schroot-unpack/create-bionic-C1udMW
+ for i in $(seq ${cnt} -1 0)
+ :
Error: setting up bionic:arm64 dchroot failed.
WARNING: tempfile is deprecated; consider using mktemp instead.
+ debootstrap --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --include=apt,gnupg,ca-certificates --variant=buildd --arch=arm64 focal /srv/chroot/schroot-unpack/create-focal-O9eY7i http://ports.ubuntu.com/ubuntu-ports /tmp/file9YBgBL
+ do_cleanup
+ local cnt
+ cnt=3
++ seq 3 -1 0
+ for i in $(seq ${cnt} -1 0)
+ rm /tmp/file9YBgBL
+ for i in $(seq ${cnt} -1 0)
+ umount /srv/chroot/schroot-unpack/create-focal-O9eY7i/sys
umount: /srv/chroot/schroot-unpack/create-focal-O9eY7i/sys: no mount point specified.
+ true
+ for i in $(seq ${cnt} -1 0)
+ rm -r /srv/chroot/schroot-unpack/create-focal-O9eY7i
+ for i in $(seq ${cnt} -1 0)
+ :
Error: setting up focal:arm64 dchroot failed.
WARNING: tempfile is deprecated; consider using mktemp instead.
+ debootstrap --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --include=apt,gnupg,ca-certificates --variant=buildd --arch=arm64 hirsute /srv/chroot/schroot-unpack/create-hirsute-PXI7Uh http://ports.ubuntu.com/ubuntu-ports /tmp/fileMWqaJg
+ do_cleanup
+ local cnt
+ cnt=3
++ seq 3 -1 0
+ for i in $(seq ${cnt} -1 0)
+ rm /tmp/fileMWqaJg
+ for i in $(seq ${cnt} -1 0)
+ umount /srv/chroot/schroot-unpack/create-hirsute-PXI7Uh/sys
umount: /srv/chroot/schroot-unpack/create-hirsute-PXI7Uh/sys: no mount point specified.
+ true
+ for i in $(seq ${cnt} -1 0)
+ rm -r /srv/chroot/schroot-unpack/create-hirsute-PXI7Uh
+ for i in $(seq ${cnt} -1 0)
+ :
Error: setting up hirsute:arm64 dchroot failed.
```Debian 11 bullseye upgradeweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/core/arti/-/issues/841Upgrade rustls and async-rustls2023-05-08T16:45:59ZNick MathewsonUpgrade rustls and async-rustlsIt would be good to upgrade our rustls dependency; I expect it to be a nontrivial upgrade, though.It would be good to upgrade our rustls dependency; I expect it to be a nontrivial upgrade, though.https://gitlab.torproject.org/tpo/core/arti/-/issues/844Upgrade to `rsa` 0.92023-05-08T16:45:59ZNick MathewsonUpgrade to `rsa` 0.9There's a new version of the `rsa` crate; there is API breakage that makes the upgrade nontrivial.There's a new version of the `rsa` crate; there is API breakage that makes the upgrade nontrivial.https://gitlab.torproject.org/tpo/core/arti/-/issues/762Decide what to do about hs descriptor cert expiry etc.2023-04-25T16:06:37ZIan Jacksoniwj@torproject.orgDecide what to do about hs descriptor cert expiry etc.This will probably involve a spec clarification and/or investigation of what C Tor does.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/999#note_2874581
```
12:41 <+Diziet> nickm: Re descriptor-signing-key-cert validity p...This will probably involve a spec clarification and/or investigation of what C Tor does.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/999#note_2874581
```
12:41 <+Diziet> nickm: Re descriptor-signing-key-cert validity period.
Obviously every signature needs to have a time-limited validity
period.
12:42 <+Diziet> The outer descriptor is signed by KP_hs_blind_id. Is it enough
that KP_hs_blind_id itself is a key which is only valid for a
particular time period ?
13:07 <+nickm> the outer descriptor is not signed by KP_hs_blind_id; it's
signed by KP_hs_desc_sign, which is in turn signed by
KP_hs_blind_id
13:07 <+Diziet> I think maybe we want a ticket for this question.
13:08 <+nickm> no objection; maybe it is the same ticket as the related
question about the status of the certificates in the inner
document. Maybe not.
```Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/722Support isolation for onion services2023-04-25T16:00:51ZNick MathewsonSupport isolation for onion servicesIn C tor, I think there is no circuit isolation when using onion services, and I _know_ there is no cache isolation. We should figure out how we would like that to work in Arti, and keep in in mind when designing our cache and client AP...In C tor, I think there is no circuit isolation when using onion services, and I _know_ there is no cache isolation. We should figure out how we would like that to work in Arti, and keep in in mind when designing our cache and client APIs here.
The "easy" version of this would be to provide circuit-level isolation, such that if two contexts would not share an exit circuit, they can't share a rendezvous circuit either. Our current design provides that at no effort.
A harder version of this would be to implement isolation for descriptor cache information and introduction point status information. Since we are currently imagining those living outside of `tor-circmgr`, we'd need to make sure that our boxed isolation-type objects can be exported to higher level crates as part of their API.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/740Design a basic RPC interface for experimentation2023-04-25T15:40:49ZNick MathewsonDesign a basic RPC interface for experimentationWe should design (and possibly build) the basics of a socket based API. (Call it IPC or RPC if you like: it would perform a function for arti analogous to Tor's control port.)
If possible we could start development in ~Q1, but ~Q2 seem...We should design (and possibly build) the basics of a socket based API. (Call it IPC or RPC if you like: it would perform a function for arti analogous to Tor's control port.)
If possible we could start development in ~Q1, but ~Q2 seems more likely: This will take a lot of discussion with a lot of people.
See [`ExportedApiSketch.md`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/ExportedApiSketch.md) for early thoughts, and a set of issues that we need to solve.https://gitlab.torproject.org/tpo/core/arti/-/issues/688CircMgr: Support for anonymous circuit to target non-exit relay.2023-04-25T15:37:12ZNick MathewsonCircMgr: Support for anonymous circuit to target non-exit relay.For onion services, we will frequently need to build an anonymous circuit to a target non-exit relay. We use these circuits for anonymized directory connections, introduction circuits, and rendezvous circuits.
This will likely involve a...For onion services, we will frequently need to build an anonymous circuit to a target non-exit relay. We use these circuits for anonymized directory connections, introduction circuits, and rendezvous circuits.
This will likely involve a new usage in CircMgr. (Unlike other usages, these circuits cannot generally be shared for anything else.)Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/745hs descriptor encoder2023-04-25T15:35:52ZIan Jacksoniwj@torproject.orghs descriptor encoderWe need something to construct hidden service descriptors. These have multiple phases of construction, which use different private key material. This will need some kind of multi-stage API.
Part of #683We need something to construct hidden service descriptors. These have multiple phases of construction, which use different private key material. This will need some kind of multi-stage API.
Part of #683Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/685Encryption/decryption and signature checking for onion descriptors2023-04-25T15:32:35ZNick MathewsonEncryption/decryption and signature checking for onion descriptorsAs a follow-on or related issue to #683, we will neeed to encrypt/decrypt the inner part of an onion service descriptor using the correct keys, and validate signatures throughout.
See `rend-spec-v3.txt` section 2.5.As a follow-on or related issue to #683, we will neeed to encrypt/decrypt the inner part of an onion service descriptor using the correct keys, and validate signatures throughout.
See `rend-spec-v3.txt` section 2.5.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/758Use spec names for keys etc., not keyword names2023-04-25T15:25:24ZIan Jacksoniwj@torproject.orgUse spec names for keys etc., not keyword namesWhile reviewing arti!999, I was frequently confused by the discrepancy between netdoc document keywords, and the official names for information (as defined elsewhere in the spec). (Context: torspec#187.)
Because in Rust the names of s...While reviewing arti!999, I was frequently confused by the discrepancy between netdoc document keywords, and the official names for information (as defined elsewhere in the spec). (Context: torspec#187.)
Because in Rust the names of struct fields often end up driving the names of local variables, this meant that cryptographic keys, nonces, protocol elements, and so on, were named in the code after the document keyword rather than after their proper official name.
This is not particularly helpful, especially since the same piece of information is often introduced by *different* netdoc keywords in different contexts.
IMO we should switch to using the official names (`kp_hs_desc_enc`, say) *even in structs representing network documents*, rather than names derived from the netdoc keywords. This would relegate the keyword to the doc comment, sadly. But it would mean that the meat of the code would always be referring to a key by its official name, not by some random phrase that happened to be used by the netdoc spec author for that particular key in that particular place.
I don't think we can do this until @nickm's !999 is merged.Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/683Encode and decode onion service descriptors2023-04-25T15:20:28ZNick MathewsonEncode and decode onion service descriptorsOnion service descriptors use the same metaformat as other Tor network documents, and should probably be encoded/decoded behind an optional feature in `tor-netdoc`. The format is documented in `rend-spec-v3.txt` sections 2.4 and 2.5.
W...Onion service descriptors use the same metaformat as other Tor network documents, and should probably be encoded/decoded behind an optional feature in `tor-netdoc`. The format is documented in `rend-spec-v3.txt` sections 2.4 and 2.5.
We should separate encryption/decryption concerns from parsing/encoding concerns: this will probably mean a two-stage process for encoding/decoding.
To get example desriptors for testing, we can run a chutney network that uses onion services, with instrumentation in the C tor to cause it to dump the descriptors it generates.
Subtasks (may not be an exhaustive list):
* [x] #743 netdoc metaformat encoder
* [x] #744 hs descriptor decoder
* [x] #745 hs descriptor encoderArti: Onion service supporthttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/39abstract dialogue options2023-04-22T22:39:21Zn0tooseabstract dialogue optionsAs I was working on #15, I realized that I will most likely have to create two separate functions -- one for the desktop, and one for the Android versions of TBB. The functionality will be very similar (all database-related operations an...As I was working on #15, I realized that I will most likely have to create two separate functions -- one for the desktop, and one for the Android versions of TBB. The functionality will be very similar (all database-related operations and dialogue options), apart from details (such as the way the correct URL containing the correct file is determined).
As the same dialogue options may be used repeatedly across different functions, it may be a good idea to 'abstract' them (aka. put them in a different file) to make maintenance easier and improve readability.n0toosen0toosehttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/41start using plugins2023-04-22T12:49:06Zn0toosestart using pluginsWe want to avoid situations like: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/blob/3edfb1c091c3b918629f0d06e767fc0137ddbf9e/OnionSproutsBot/bot.py#L372-L383
The patch was still merged, as it went k...We want to avoid situations like: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/blob/3edfb1c091c3b918629f0d06e767fc0137ddbf9e/OnionSproutsBot/bot.py#L372-L383
The patch was still merged, as it went kind-of-out-of-scope and I wanted to provide translators with the few, slightly altered strings as soon as possible.
Pyrogram has a [built-in mechanism to specifically prevent this](https://docs.pyrogram.org/topics/smart-plugins), which I avoided using as I believed that "plugins", in this case, insinuated that they could be dynamically removed or added, which was very suboptimal, considering that the functions we wanted to "abstract" into separate files were linked to specific buttons under `bot.py` and we could not check whether a plugin was imported or not. Apparently, according to @StarByte, this doesn't matter as "plugins" can't be loaded or unloaded during runtime, and my confusion stemmed from my experience with other libraries that interface with instant messaging apps.
For this task to be complete, it'd be optimal to:
- separate some helper functions currently under `dialogue.py`
- shove all callback-needing functions in `dialogue.py` in a new file and remove the aforementioned "ugly hack" from bot.py
- move most of the functions in `bot.py` to a plugin file
~~(Note: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/issues/42 has to be dealt with first)~~n0toosen0toosehttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/122Update x/net and x/crypto to latest version in Obfs4proxy and Snowflake2023-04-20T08:36:45ZtlaUpdate x/net and x/crypto to latest version in Obfs4proxy and SnowflakeSomebody sent me an issue about this:
https://github.com/tladesignz/IPtProxy/issues/45
> For security purposes, golang.org/x/crypto and golang.org/x/net should be updated to latest versions. This also requires the obfs4 and snowflake s...Somebody sent me an issue about this:
https://github.com/tladesignz/IPtProxy/issues/45
> For security purposes, golang.org/x/crypto and golang.org/x/net should be updated to latest versions. This also requires the obfs4 and snowflake submodules to do the same thing, so there needs to be some coordination between all three projects for this to happen.
Please let me know, if this is valid, and if there's any problems with that request! Thank you!meskiomeskio@torproject.orgmeskiomeskio@torproject.org