Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:40Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34254Jenkins fails with hs_service.c:3118:3: error: comparison of unsigned express...2020-06-13T15:53:40ZGeorge KadianakisJenkins fails with hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenk...```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenkins.torproject.org/job/tor-ci-windows-master/659/consoleFull
Seems to be a by-product of #33400.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/34224Update analysis results file version to 2.02020-06-13T18:04:38ZKarsten LoesingUpdate analysis results file version to 2.0We added a new field to the analysis results file format in #26673, but we did not yet increment the format version number. The current version field is a floating point number, which doesn't work well for versioning. We should use a ver...We added a new field to the analysis results file format in #26673, but we did not yet increment the format version number. The current version field is a floating point number, which doesn't work well for versioning. We should use a version string here. Given that this change alone is going to be backward-incompatible, we'll have to call the new version 2.0. I'm preparing a patch.https://gitlab.torproject.org/legacy/trac/-/issues/34154Extend BlockedBridges table2020-06-13T18:30:04ZPhilipp Winterphw@torproject.orgExtend BlockedBridges tableBridgeDB has a (currently unused) table in its SQLite database that captures where a bridge is blocked. We are going to use this table as part of our work on #32740. It currently has the following fields:
* ID (primary key)
* hex_key (fi...BridgeDB has a (currently unused) table in its SQLite database that captures where a bridge is blocked. We are going to use this table as part of our work on #32740. It currently has the following fields:
* ID (primary key)
* hex_key (fingerprint)
* blocking_country (country code)
A fingerprint can relate to a bridge's OR port or any of its pluggable transports but these endpoints can be blocked independently. To remove this ambiguity, we should add additional fields for a bridge's IP address, port, and perhaps for an autonomous system because blocking isn't always uniform across a country.https://gitlab.torproject.org/legacy/trac/-/issues/34109Download and parse OnionPerf analysis .json files instead of .tpf files2020-06-13T18:09:38ZKarsten LoesingDownload and parse OnionPerf analysis .json files instead of .tpf filesWith #34070 and #34072 being merged and deployed we can now change metrics-web to download and parse OnionPerf analysis .json files instead of .tpf files.With #34070 and #34072 being merged and deployed we can now change metrics-web to download and parse OnionPerf analysis .json files instead of .tpf files.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34024Reduce timeout and stallout values2020-06-13T18:04:30ZKarsten LoesingReduce timeout and stallout valuesOn #33974 we discussed a suggestion to reduce timeouts for our three downloads as follows:
- 50 KiB download with 15 seconds timeout rather than 295 seconds,
- 1 MiB download with 60 seconds timeout rather than 1795 seconds, and
- 5 ...On #33974 we discussed a suggestion to reduce timeouts for our three downloads as follows:
- 50 KiB download with 15 seconds timeout rather than 295 seconds,
- 1 MiB download with 60 seconds timeout rather than 1795 seconds, and
- 5 MiB download with 120 seconds timeout rather than 3595 seconds.
Similarly, stallouts would be dropped entirely:
- 50 KiB download with 0 seconds stallout rather than 300 seconds,
- 1 MiB download with 0 seconds stallout rather than 1800 seconds, and
- 5 MiB download with 0 seconds stallout rather than 3600 seconds.
After discussing this with irl we concluded that we might want to pick values somewhere in the middle. The smaller values above are being used by TGen for generating load for Shadow simulations, in that case it makes sense to use timeouts similar to how users would behave. But in the measurements we're doing with OnionPerf we can easily record more data even after a human user would have given up and later filter out measurements taking longer than whatever timeouts we want to use.
In particular, it would be important for us to use timeouts that are higher than timeouts used internally by the Tor client, so that we can observe what happens in those cases. Even if a human user would long have given up.
How about we use timeouts and stallouts close to 5 minutes, so that we avoid overlapping measurements? Like 270 seconds for all three download sizes? What would we use as stallout value here? 0?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/33917Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL2020-06-13T15:53:09ZteorMake IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33716Create user accounts for Metrics Team and add SSH keys2020-06-13T17:48:44ZirlCreate user accounts for Metrics Team and add SSH keysCurrently machines are only accessible by the user that created them, unless more keys are added manually. This will also help us to keep SSH keys in sync if they are changed.Currently machines are only accessible by the user that created them, unless more keys are added manually. This will also help us to keep SSH keys in sync if they are changed.irlirlhttps://gitlab.torproject.org/legacy/trac/-/issues/33675Search microdescriptor files for relay ed25519 keys2020-06-13T13:31:47ZteorSearch microdescriptor files for relay ed25519 keysYour code in #33428 needs to pass your local "make test-network-all", before you start this ticket.
We need to enable searching for ed25519 keys in relay microdescriptor files.
There are instructions and a draft search pattern here:
ht...Your code in #33428 needs to pass your local "make test-network-all", before you start this ticket.
We need to enable searching for ed25519 keys in relay microdescriptor files.
There are instructions and a draft search pattern here:
https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L1325
Please open a new pull request for this ticket. Your branch should be based on the final version of #33428.
Before you push new changes to your pull request, your chutney code should pass:
* "make test-network-all" on tor master
* "make test-network-all" on tor maint-0.3.5
You can build a tor branch using these commands:
```
cd tor
git checkout -b <branch>
make
```
Where <branch> is master or maint-0.3.5https://gitlab.torproject.org/legacy/trac/-/issues/33587puppet certificate revocation anomaly2020-06-13T17:01:14Zanarcatpuppet certificate revocation anomalytoday i revoked cupani's cert by mistake:
```
anarcat@curie:tsa-misc(master)$ ./retire -v -H cupani.torproject.org retire-all -p unifolium.torproject.org
checking for ganeti master on node unifolium.torproject.org
omeiense.torproject....today i revoked cupani's cert by mistake:
```
anarcat@curie:tsa-misc(master)$ ./retire -v -H cupani.torproject.org retire-all -p unifolium.torproject.org
checking for ganeti master on node unifolium.torproject.org
omeiense.torproject.org
polyanthum.torproject.org
instance cupani.torproject.org not running, no shutdown required
undefining instance cupani.torproject.org on host unifolium.torproject.org
error: failed to get domain 'cupani.torproject.org'
error: Domain not found: no domain with matching name 'cupani.torproject.org'
instance cupani.torproject.org not found on unifolium.torproject.org assuming retired: error: failed to get domain 'cupani.torproject.org'
error: Domain not found: no domain with matching name 'cupani.torproject.org'
scheduling cupani.torproject.org disk deletion on host unifolium.torproject.org
checking for path "/srv/vmstore/cupani.torproject.org/" on unifolium.torproject.org
scheduling rm -rf "/srv/vmstore/cupani.torproject.org/" to run on unifolium.torproject.org in 7 days
warning: commands will be executed using /bin/sh
job 4 at Tue Mar 17 17:45:00 2020
scheduling cupani.torproject.org backup disks removal on host bungei.torproject.org
checking for path "/srv/backups/bacula/cupani.torproject.org/" on bungei.torproject.org
scheduling rm -rf "/srv/backups/bacula/cupani.torproject.org/" to run on bungei.torproject.org in 30 days
warning: commands will be executed using /bin/sh
job 22 at Thu Apr 9 17:45:00 2020
Notice: Revoked certificate with serial 30
Notice: Removing file Puppet::SSL::Certificate cupani.torproject.org at '/var/lib/puppet/ssl/ca/signed/cupani.torproject.org.pem'
cupani.torproject.org
Submitted 'deactivate node' for cupani.torproject.org with UUID 7b5e6d74-cb31-4929-9082-4a2bcda08b88
```
i was following the migration procedure as part of #33446 and got over enthusiastic about the process. the cert shouldn't have been revoked, of course, as the machine is still up.
but when i tried to see the effect of this, it seemed the certificate still worked! cupani can do puppet runs without problems, even though the on-disk certificate is gone:
```
root@pauli:~# ls -al /var/lib/puppet/ssl/ca/signed/cupani.torproject.org.pem
ls: cannot access '/var/lib/puppet/ssl/ca/signed/cupani.torproject.org.pem': No such file or directory
```
so it seems our certificate revocation routine:
```
con.run('puppet node clean %s' % instance)
con.run('puppet node deactivate %s' % instance)
```
... does not work.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/33545assertion failure when "all zero" client auth key provided2020-06-13T15:53:04ZMark Smithassertion failure when "all zero" client auth key providedWhile doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:142...While doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:1423: decrypt_descriptor_cookie: Assertion !fast_mem_is_zero((char *) client_auth_sk, sizeof(*client_auth_sk)) failed; aborting. (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
```
As it turns out, I happened to enter a key that is consists entirely of zero bits. This is an unusual thing to do, but I do not think tor should exit.
Steps to reproduce in Tor Browser:
1. Try to load an http or https page for a v3 onion service that requires client authentication, e.g., dgoulet's test server.
2. Enter 56 'A's when prompted for a client auth key.
Result: tor exits due to the assertion failure. Behind the scenes, the browser installs the key via a control port command like the following:
```
onion_client_auth_add <onion-addr> x25519:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
```
and then tries to access the onion service again (page reload).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33435Document BASETORRC environment variable2020-06-13T18:04:27ZAna CusturaDocument BASETORRC environment variableOP can configure the Tor client through the BASETORRC environment variable. This should be added to the documentation with examples.OP can configure the Tor client through the BASETORRC environment variable. This should be added to the documentation with examples.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33400hs-v3: Log why we can't upload a descriptor2020-06-13T15:53:40ZDavid Gouletdgoulet@torproject.orghs-v3: Log why we can't upload a descriptorWe still have report of services that stop working and the logs suggest they simply stopped uploading their descriptors.
We need to know why and thus add logging. TIcket #24346 had an attempt at it but it was abandoned. I'm reviving the...We still have report of services that stop working and the logs suggest they simply stopped uploading their descriptors.
We need to know why and thus add logging. TIcket #24346 had an attempt at it but it was abandoned. I'm reviving the logging part due to still getting reports of the issue.
Logging the reason is tricky due to the rate and multiple descriptor object.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33353Split chutney's diagnostics into a new script2020-06-13T13:31:32ZteorSplit chutney's diagnostics into a new scriptChutney's failure diagnostics are currently in the Travis CI config file.
But we want to use them in tor's CI. And maybe chutney users want to use them as well.Chutney's failure diagnostics are currently in the Travis CI config file.
But we want to use them in tor's CI. And maybe chutney users want to use them as well.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33339Add script to check ordering of options in manpage2020-06-13T15:51:26ZTaylor YuAdd script to check ordering of options in manpageAdd a script to check the ordering of option names within a manpage section.
This will be an initial version that doesn't restrict section names and doesn't recognize pragma comments that mark intentionally out-of-order option names.
#...Add a script to check the ordering of option names within a manpage section.
This will be an initial version that doesn't restrict section names and doesn't recognize pragma comments that mark intentionally out-of-order option names.
#32621 will contain a more fully-functional script suitable for automation.Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/33299Remove retired pluggable transports from BridgeDB2020-06-13T18:29:57ZPhilipp Winterphw@torproject.orgRemove retired pluggable transports from BridgeDBBridgeDB still hands out obfs3, ScrambleSuit, and FTE bridges. Tor Browser no longer supports FTE (see #29319), so we should remove it. I suggest also removing obfs3 and ScrambleSuit because these transports don't offer anything that obf...BridgeDB still hands out obfs3, ScrambleSuit, and FTE bridges. Tor Browser no longer supports FTE (see #29319), so we should remove it. I suggest also removing obfs3 and ScrambleSuit because these transports don't offer anything that obfs4 doesn't already provide.
As of today, BridgeDB knows about 1,316 bridges. Among these:
* 31 support FTE. 29 of these wouldn't be handed out because they also support obfs4 (see #28655). The remaining two bridges run FTE/obfs3 and ScrambleSuit/obfs3/FTE.
* 34 support ScrambleSuit. 32 of these also support obfs4 and only two don't. Instead, they run obfs3/ScrambleSuit and ScrambleSuit/obfs3/FTE.
* 106 support obfs3. Only seven of these don't support obfs4.
Considering the above, I think it's safe to retire FTE, ScrambleSuit, and obfs3.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32860Bridge Dockerfile for Raspberry Pi 32020-06-13T15:49:39ZTracBridge Dockerfile for Raspberry Pi 3It would be great to see support for these devices, as they are getting more and more popular.
I can provide a Dockerfile for a Bridge+obfs4 for Raspberry Pi 3, based on phw@ work
**Trac**:
**Username**: qdiiIt would be great to see support for these devices, as they are getting more and more popular.
I can provide a Dockerfile for a Bridge+obfs4 for Raspberry Pi 3, based on phw@ work
**Trac**:
**Username**: qdiiPhilipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32818Standardise EXPOSE and INTERNAL macros to PRIVATE2020-06-13T15:49:28ZteorStandardise EXPOSE and INTERNAL macros to PRIVATEWe should rename all our EXPOSE and INTERNAL macros to PRIVATE.
Then we can simplify the PRIVATE patterns in #32798 and #32522.We should rename all our EXPOSE and INTERNAL macros to PRIVATE.
Then we can simplify the PRIVATE patterns in #32798 and #32522.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32739Bump clang to 8.0.12020-06-16T01:10:17ZGeorg KoppenBump clang to 8.0.1While rebuilding a lot of our toolchains for #32053 anyway let's fix clang bugs that already got fixed in the 8.0 cycle and bump our clang to 8.0.1While rebuilding a lot of our toolchains for #32053 anyway let's fix clang bugs that already got fixed in the 8.0 cycle and bump our clang to 8.0.1Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/32683Relay Search should be able to handle non-numbers in "as:" parameter2020-06-13T18:08:26ZKarsten LoesingRelay Search should be able to handle non-numbers in "as:" parameter```
01:44:28 <+arma2> irl, karsten:
https://metrics.torproject.org/rs.html#search/as:azure tells me i
have a problem with my javascript. but my javascript is fine. maybe
that "as:"...```
01:44:28 <+arma2> irl, karsten:
https://metrics.torproject.org/rs.html#search/as:azure tells me i
have a problem with my javascript. but my javascript is fine. maybe
that "as:" syntax expects a number only?
06:33:53 <+karsten> arma2: yes, "as:" expects a number, but you can use "as_name:" if
you have part of the name.
06:34:05 <+karsten> arma2: still, it shouldn't throw a javascript error at you. I'll
open a ticket.
06:35:56 <+arma2> ah, and i guess part of your ticket should be: in the text input
box on https://metrics.torproject.org/rs.html#advanced called "AS",
maybe it should figure out whether you put in a name or a number
```https://gitlab.torproject.org/legacy/trac/-/issues/32658Create new MAR signing key for Tor Browser2020-06-16T01:10:10ZGeorg KoppenCreate new MAR signing key for Tor BrowserWe want to create a new MAR signing key for the yearly key rotation.We want to create a new MAR signing key for the yearly key rotation.Georg KoppenGeorg Koppen