Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:53:13Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17983Build tor with -ftrapv by default2020-06-13T14:53:13ZteorBuild tor with -ftrapv by defaultIf the CFLAGS passed to tor don't contain -ftrapv (or the undefined behaviour sanitiser), let's build with -ftrapv.
This resolves #13538 non-intrusively, and prevents an entire class of integer safety bugs. (That said, wrapping can hide...If the CFLAGS passed to tor don't contain -ftrapv (or the undefined behaviour sanitiser), let's build with -ftrapv.
This resolves #13538 non-intrusively, and prevents an entire class of integer safety bugs. (That said, wrapping can hide some issues rather than resolving them.)Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18604Deleting an ephemeral service doesn't always destroy intro circuits2020-06-13T14:55:17ZJohn BrooksDeleting an ephemeral service doesn't always destroy intro circuitsOn tor 0.2.7.6 with hidden services configured via ADD_ONION, this warning appeared several times:
```
log_warn(LD_REND, "Unrecognized service ID %s on introduction circuit %u.",
serviceid, (unsigned)circuit->base_.n_ci...On tor 0.2.7.6 with hidden services configured via ADD_ONION, this warning appeared several times:
```
log_warn(LD_REND, "Unrecognized service ID %s on introduction circuit %u.",
serviceid, (unsigned)circuit->base_.n_circ_id);
```
This happens when an introduction circuit finishes building and the service it was built for no longer exists.
When removing an ephemeral service, we close all S_ESTABLISH_INTRO or S_INTRO circuits that are CIRCUIT_STATE_OPEN. I suspect this warning happens when the service is removed before an introduction circuit reaches STATE_OPEN.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18620HSFORGET command to clear cached client state for a HS2020-06-13T14:55:29ZTracHSFORGET command to clear cached client state for a HSThis is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://cod...This is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://code.briarproject.org/akwizgran/briar/issues/115). It adds an `HSFORGET` command to the control protocol which clears any cached client state relating to a specified hidden service. This can be used to flush state that's likely to be stale before trying to connect to a hidden service via an unstable network connection (such as a mobile data connection).
**Trac**:
**Username**: str4dTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18668Numerous WSAStartup warnings in unit tests on windows2020-06-13T14:55:50ZNick MathewsonNumerous WSAStartup warnings in unit tests on windowsHead on over to Jenkins, and look at the windows builder output. It's complaining a lot that we aren't calling WSAStartup. We should fix that.
It's not causing bugs or preventing the tests from passing, but it sure is ugly.Head on over to Jenkins, and look at the windows builder output. It's complaining a lot that we aren't calling WSAStartup. We should fix that.
It's not causing bugs or preventing the tests from passing, but it sure is ugly.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18956Trivial memory leak when reading truncated ed25519 key files2020-06-13T14:57:00ZNick MathewsonTrivial memory leak when reading truncated ed25519 key filesFound while working on #16794. Will fix on that branch. Opening this ticket to give it a number.Found while working on #16794. Will fix on that branch. Opening this ticket to give it a number.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19044Turn on --enable-gcc-warnings-advisory by default2020-06-13T14:57:25ZJohn BrooksTurn on --enable-gcc-warnings-advisory by defaultI've had multiple patches fail due to missing the `--enable-gcc-warnings` flag in builds. I've also missed really important problems that these warnings would tell me about.
Turning on `--enable-gcc-warnings` by default is probably not ...I've had multiple patches fail due to missing the `--enable-gcc-warnings` flag in builds. I've also missed really important problems that these warnings would tell me about.
Turning on `--enable-gcc-warnings` by default is probably not a good choice, because GCC warnings vary quite a lot between versions and `-Werror` will cause these new warnings to break builds.
Without `-Werror`, there's no harm in enabling all of these warnings by default, and this makes us more likely to notice important warnings. We should do it.
I suggest:
1. Make the behavior of `--enable-gcc-warnings-advisory` default when supported by the compiler
2. Add an `--enable-fatal-warnings` option to turn on `-Werror`
3. Alias `--enable-gcc-warnings` to `--enable-fatal-warnings` for backwards compatibility
4. Deprecate or ignore `--enable-gcc-warnings-advisory`
5. Optionally, we could have a `--disable-extra-warnings` flag, if there's a case where someone wants to turn off these warningsTor: 0.2.9.x-finalNick MathewsonNick Mathewson