Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:53:29Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26029onion_extend_cpath2020-06-27T13:53:29ZTraconion_extend_cpathtor_bug_occurred_(): Bug: !circuitbuild.c:2772: onion_extend_cpath: Non-fatal assertion info !|| client failed. (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
Bug: Non-fatal assertion info !|| client failed in onion_extend_cpath at !circuitbuild.c...tor_bug_occurred_(): Bug: !circuitbuild.c:2772: onion_extend_cpath: Non-fatal assertion info !|| client failed. (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
Bug: Non-fatal assertion info !|| client failed in onion_extend_cpath at !circuitbuild.c:2772. (Stack trace not available) (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
tor_bug_occurred_(): Bug: !circuitbuild.c:2779: onion_extend_cpath: Non-fatal assertion info failed. (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
Bug: Non-fatal assertion info failed in onion_extend_cpath at !circuitbuild.c:2779. (Stack trace not available) (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
tor_bug_occurred_(): Bug: !circuitbuild.c:2390: onion_pick_cpath_exit: Non-fatal assertion !(exit_ei == NULL) failed. (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
Bug: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit at !circuitbuild.c:2390. (Stack trace not available) (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
**Trac**:
**Username**: whiteshieldTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26152Improve errors on crypto/openssl_version badness2020-06-27T13:53:23ZNick MathewsonImprove errors on crypto/openssl_version badnessWhen these tests fail, they currently do so in an unhelpful way. They should log the offending strings when the version strings don't match.
Extracted from legacy/trac#25549.When these tests fail, they currently do so in an unhelpful way. They should log the offending strings when the version strings don't match.
Extracted from legacy/trac#25549.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26211torspec update for GETINFO md/all2020-06-27T13:53:21Zrl1987torspec update for GETINFO md/allTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26222Add a bandwidth-file line to votes in dir-spec.txt2020-06-27T13:53:20ZteorAdd a bandwidth-file line to votes in dir-spec.txtThis is an information line in votes, it does not end up in the consensus.
See legacy/trac#3723 for details.This is an information line in votes, it does not end up in the consensus.
See legacy/trac#3723 for details.Tor: 0.3.5.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/26223Allow longer bandwidth lines in bandwidth files2020-06-27T13:53:20ZteorAllow longer bandwidth lines in bandwidth filesBandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiply...Bandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiplying it by 4x, then rounding up to the nearest power of two.
We can use the examples in the spec if we need to:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt
Maybe we should wait until sbws has added all the new fields?Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26228Clarify/determine specification for padding bytes, (formerly also PADDING cell)2020-06-27T13:53:20ZdmrClarify/determine specification for padding bytes, (formerly also PADDING cell)**EDIT: strikethrough content below is now covered in legacy/trac#26870 instead**
==== Background
I was trying to interpret the tor-spec for padding bytes, and ending up asking nickm for some clarification over IRC.
nickm suggested most...**EDIT: strikethrough content below is now covered in legacy/trac#26870 instead**
==== Background
I was trying to interpret the tor-spec for padding bytes, and ending up asking nickm for some clarification over IRC.
nickm suggested most of the cc'd for the ticket - I added atagar, too.
==== Unclear areas
Here are the points that need clarification / specification:
* spec for padding bytes does not clearly say what senders `MUST` or `SHOULD` do, [[mentioning that padding is with 0 bytes](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt?id=f6e93d9751002d970614662c8173ff2fa5b7c193#n412|only)] or [[NUL bytes](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt?id=f6e93d9751002d970614662c8173ff2fa5b7c193#n1480|(elsewhere))]
* spec for padding bytes does not say what receivers `MUST` or `SHOULD` do, when receiving non-zero bytes in the Cell (e.g. warn? ignore?)
* ~~spec is a bit inconsistent with `PADDING` cells ^^[1^^]^^[2^^]~~
==== Discussion: padding bytes
For the padding bytes that are not part of `PADDING` cells, nickm offered the following as a non-exhaustive set of possible forward-compatible options:
* "the [padding] bytes SHOULD be zero, and that implementations MUST ignore them"
* "The first 8 padding bytes MUST be zero; all subsequent padding bytes SHOULD be randomized. Implementations MUST ignore padding bytes"
* "All padding bytes should be randomized; implemenations MUST ignore unrecognized padding bytes"
... and mentioned that "[he doesn't] know enough of the argument in favor of randomization to have a very strong preference"
==== ~~Inconsistency: `PADDING` cell payload~~
~~(see bullet above)~~
~~These references highlight the inconsistency:~~
~~^^[1^^] `PADDING: Payload is unused.` per [[3 "Cell Packet format"](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt?id=f6e93d9751002d970614662c8173ff2fa5b7c193#n469|sec)].~~
~~ implies 0 bytes of payload, so the rest should be padded per that section~~
~~^^[2^^] `The contents of a PADDING, VPADDING, or DROP cell SHOULD be chosen randomly, and MUST be ignored.` per [[7.2 "Link padding"](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt?id=f6e93d9751002d970614662c8173ff2fa5b7c193#n1723|sec)].~~
~~ implies the payload of a `PADDING` cell actually is the rest of the size of the cell, and that it SHOULD be chosen randomly~~
~~The `PADDING` cells were mentioned in IRC but not discussed.~~
~~I think a simple change to make the spec consistent between the two sections would be this:~~
~~`PADDING: Payload contains random data. (See Sec 7.2)`~~
~~However, given the other points here, is that correct?~~Tor: 0.3.5.x-finaldmrdmrhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26281Add .editorconfig?: it makes it easier to follow coding standards style with ...2020-06-27T13:53:18ZjugaAdd .editorconfig?: it makes it easier to follow coding standards style with many editorsSee more informatin in https://editorconfig.org/
Maybe it would be usefult to include it in the source code?.See more informatin in https://editorconfig.org/
Maybe it would be usefult to include it in the source code?.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26282Smartlist index implicitly converted to int2020-06-27T13:53:18Zrl1987Smartlist index implicitly converted to intWhen building with `DEBUG_SMARTLIST`:
```
src/common/util.c:4816:45: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *s = smartlist_get(env_vars, i);
...When building with `DEBUG_SMARTLIST`:
```
src/common/util.c:4816:45: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *s = smartlist_get(env_vars, i);
~~~~~~~~~~~~~ ^
src/common/util.c:4846:54: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *s = smartlist_get(env_vars_sorted, i);
~~~~~~~~~~~~~ ^
2 warnings generated.
```
```
src/common/util.c:4816:45: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *s = smartlist_get(env_vars, i);
~~~~~~~~~~~~~ ^
src/common/util.c:4846:54: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *s = smartlist_get(env_vars_sorted, i);
~~~~~~~~~~~~~ ^
2 warnings generated.
```
```
src/or/control.c:4627:43: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *arg = smartlist_get(args, i);
~~~~~~~~~~~~~ ^
1 warning generated.
```
```
src/or/geoip.c:153:57: warning: implicit conversion loses integer precision: 'intptr_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
geoip_country_t *c = smartlist_get(geoip_countries, idx);
~~~~~~~~~~~~~ ^~~
1 warning generated.
```
```
src/or/control.c:4627:43: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
const char *arg = smartlist_get(args, i);
~~~~~~~~~~~~~ ^
1 warning generated.
```
```
src/or/geoip.c:153:57: warning: implicit conversion loses integer precision: 'intptr_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
geoip_country_t *c = smartlist_get(geoip_countries, idx);
~~~~~~~~~~~~~ ^~~
1 warning generated.
```Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/26311Error in `/usr/bin/tor': free(): invalid next size (normal): 0x000055ed468598d02020-06-27T13:53:15ZcypherpunksError in `/usr/bin/tor': free(): invalid next size (normal): 0x000055ed468598d0
https://lists.torproject.org/pipermail/tor-relays/2018-June/015353.html
"
My very stable Tor relay 16102E458460349EE45C0901DAA6C30094A9BBEA is now
rebooting every two days since May 31, 2018.
Running Tor 0.3.3.5-rc (git-4fe9670741478...
https://lists.torproject.org/pipermail/tor-relays/2018-June/015353.html
"
My very stable Tor relay 16102E458460349EE45C0901DAA6C30094A9BBEA is now
rebooting every two days since May 31, 2018.
Running Tor 0.3.3.5-rc (git-4fe9670741478750) on Linux
with Libevent 2.0.21-stable, OpenSSL 1.1.0f, Zlib 1.2.8
You will find a short extract of the Tor log below :
May 31 23:12:27 mkuktra systemd[1]: tor@default.service: Main process
exited, code=killed, status=7/BUS
May 31 23:12:27 mkuktra systemd[1]: tor@default.service: Unit entered
failed state.
May 31 23:12:27 mkuktra systemd[1]: tor@default.service: Failed with
result 'signal'.
May 31 23:12:28 mkuktra systemd[1]: tor@default.service: Service
hold-off time over, scheduling restart.
Jun 05 03:17:59 mkuktra tor[23419]: *** Error in `/usr/bin/tor': free():
invalid next size (normal): 0x000055ed468598d0 ***
Jun 05 03:17:59 mkuktra tor[23419]: ======= Backtrace: =========
Jun 05 03:17:59 mkuktra tor[23419]:
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7fbb01af9bfb]
Jun 05 03:17:59 mkuktra tor[23419]:
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7fbb01afffc6]
"
trac search found also legacy/trac#15776Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26331Make queries to help with Tor rotations2020-06-27T13:53:14ZNick MathewsonMake queries to help with Tor rotationsVarious of our rotations -- especially bug triage -- would benefit from saved queries. We should add those, either as stored queries or links from one of our wiki pages.Various of our rotations -- especially bug triage -- would benefit from saved queries. We should add those, either as stored queries or links from one of our wiki pages.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26332Write up ticket triage process as algorithm or flowchart2020-06-27T13:53:14ZNick MathewsonWrite up ticket triage process as algorithm or flowchartTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26379Rend-spec isn't clear about role of first layer of descriptor encryption2020-06-27T13:53:11ZSteven MurdochRend-spec isn't clear about role of first layer of descriptor encryptionIn `[HS-DESC-FIRST-LAYER]` of `rend-spec-v3.txt` it says:
The first layer of HS descriptor encryption is designed to protect
descriptor confidentiality against entities who don't know the blinded
public key of the hidden service.
...In `[HS-DESC-FIRST-LAYER]` of `rend-spec-v3.txt` it says:
The first layer of HS descriptor encryption is designed to protect
descriptor confidentiality against entities who don't know the blinded
public key of the hidden service.
However the HSDir does know the blinded public key, as that's part of the `descriptor-signing-key-cert` described in `[DESC-OUTER]`. Should the above quote instead be "...against entities who don't know the _public identity master key_ of the hidden service"Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26383Move structures out of or.h2020-06-27T13:53:11ZNick MathewsonMove structures out of or.hAs part of the big 0.3.5 refactoring, we want to split or.h into lots of little headers. And as part of that, we want to get each structure into its own header.As part of the big 0.3.5 refactoring, we want to split or.h into lots of little headers. And as part of that, we want to get each structure into its own header.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26437Forking tests fails on Windows if there is a space in the path of the test ru...2020-06-27T13:53:09ZAlexander Færøyahf@torproject.orgForking tests fails on Windows if there is a space in the path of the test runnerTests that needs to fork fails on Windows if there is a space somewhere in the path.Tests that needs to fork fails on Windows if there is a space somewhere in the path.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26439Use the "commands" element of AC_CONFIG_FILES to make generated scripts execu...2020-06-27T13:53:09ZNick MathewsonUse the "commands" element of AC_CONFIG_FILES to make generated scripts executableHello71 pointed this out to me on a code review.Hello71 pointed this out to me on a code review.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26447Add check-includes to check-local?2020-06-27T13:53:08ZNick MathewsonAdd check-includes to check-local?We now have a handy tool that lets us check our includes for modularity violations. We could make it part of "make check", and have our CI enforce it for us!We now have a handy tool that lets us check our includes for modularity violations. We could make it part of "make check", and have our CI enforce it for us!Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26448Document check-includes in coding standards or helpful tools2020-06-27T13:53:08ZNick MathewsonDocument check-includes in coding standards or helpful toolsTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26457Rewrite the UTF-8 conformity section of prop#2852020-06-27T13:53:08ZteorRewrite the UTF-8 conformity section of prop#285I rewrote the UTF-8 conformity section of prop#285 to be more specific, use terminology from The Unicode Standard, and ban byte-swapped byte order marks.
Please see my branch utf-8-extra on https://github.com/teor2345/torspec.gitI rewrote the UTF-8 conformity section of prop#285 to be more specific, use terminology from The Unicode Standard, and ban byte-swapped byte order marks.
Please see my branch utf-8-extra on https://github.com/teor2345/torspec.gitTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26481Split src/common into src/lib2020-06-27T13:53:07ZNick MathewsonSplit src/common into src/libThis work has already begun; we should have a ticket for it.This work has already begun; we should have a ticket for it.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26482Refactor log.c and everything below it into separate libraries2020-06-27T13:53:06ZNick MathewsonRefactor log.c and everything below it into separate librariesThis is currently under review as https://github.com/torproject/tor/pull/174 -- but since it wasn't a same-day merge, I should really have a ticket for it.This is currently under review as https://github.com/torproject/tor/pull/174 -- but since it wasn't a same-day merge, I should really have a ticket for it.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson