Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:17:02Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4991Use standard windows-detection macros2020-06-13T14:17:02ZNick MathewsonUse standard windows-detection macrosIn our code, we mostly use MS_WINDOWS to detect windows; we sometimes use WIN32 to detect windows; and we sometimes use _WIN32.
_WIN32 is standard; WIN32 is obsolete; MS_WINDOWS is our own silliness. Let's be consistent and standard a...In our code, we mostly use MS_WINDOWS to detect windows; we sometimes use WIN32 to detect windows; and we sometimes use _WIN32.
_WIN32 is standard; WIN32 is obsolete; MS_WINDOWS is our own silliness. Let's be consistent and standard and just use WIN32.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7977Have autoconf detect signed enum2020-06-13T14:26:33ZNick MathewsonHave autoconf detect signed enumOn MSVC, enums are always signed. With #7305, we made an ENUM_BF macro to avoid problems with signed enums. But that macro needs to know whether by default enum types are signed or not. It would be better to detect this with autoconf ...On MSVC, enums are always signed. With #7305, we made an ENUM_BF macro to avoid problems with signed enums. But that macro needs to know whether by default enum types are signed or not. It would be better to detect this with autoconf than just to check for defined(_MSC)Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8160Create separate pending counters during circuit construction2020-06-13T14:27:08ZMike PerryCreate separate pending counters during circuit constructionWhile testing the path bias code, I noticed a source of rounding error when we scaled our counts down while circuits are open. I corrected for this by counting the number of open circuits during scaling and subtracting that from our coun...While testing the path bias code, I noticed a source of rounding error when we scaled our counts down while circuits are open. I corrected for this by counting the number of open circuits during scaling and subtracting that from our counts where appropriate, but a better fix might be to actually store separate pending counters that we don't transfer into the official, scaled counters until circuit closure.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8325Remove unused functions and macros2020-06-13T14:27:45ZNick MathewsonRemove unused functions and macrosIt's time again to scrub some cruft. I've got a patch in branch "unused_stuff" in my public repo that deletes a bunch of functions and macros which we don't use, and in some cases deletes their unit tests too.
This doesn't delete every...It's time again to scrub some cruft. I've got a patch in branch "unused_stuff" in my public repo that deletes a bunch of functions and macros which we don't use, and in some cases deletes their unit tests too.
This doesn't delete every unused function or macro; I left a few which in my judgment seemed likely to get used some time in the not-too-distant future. Also I probably missed some.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9045Don't let the call frequency of update_networkstatus_downloads() depend on To...2020-06-13T14:29:39ZLinus Nordberglinus@torproject.orgDon't let the call frequency of update_networkstatus_downloads() depend on TorTestingNetworkIn #8532 we start calling update_networkstatus_downloads() more often when TorTestingNetwork is set. That shouldn't be necessary but is the safe thing to do for now. It should go away at some point though.In #8532 we start calling update_networkstatus_downloads() more often when TorTestingNetwork is set. That shouldn't be necessary but is the safe thing to do for now. It should go away at some point though.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10481connection_mark_unattached_ap_: checking always true edge_has_sent_end2020-06-13T14:33:33Zcypherpunksconnection_mark_unattached_ap_: checking always true edge_has_sent_end```
ENTRY_TO_EDGE_CONN(conn)->edge_has_sent_end = 1; /* no circ yet */
```
```
if ((edge_conn->on_circuit != NULL || edge_conn->edge_has_sent_end) &&
connection_edge_is_rendezvous_stream(edge_conn)) {
rend_client_note_conn...```
ENTRY_TO_EDGE_CONN(conn)->edge_has_sent_end = 1; /* no circ yet */
```
```
if ((edge_conn->on_circuit != NULL || edge_conn->edge_has_sent_end) &&
connection_edge_is_rendezvous_stream(edge_conn)) {
rend_client_note_connection_attempt_ended(
edge_conn->rend_data->onion_address);
}
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11444Drop support for long-obsolete versions of Windows2020-06-13T14:40:18ZNick MathewsonDrop support for long-obsolete versions of WindowsWhen we started writing Tor, Windows 98 was still a going concern. Now... it is less so.
We should identify and drop support code for all windows versions before Windows XP. This is mainly going to be a matter of identifying cases whe...When we started writing Tor, Windows 98 was still a going concern. Now... it is less so.
We should identify and drop support code for all windows versions before Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
(Dropping support for windows XP is a separate ticket.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11445Drop support for Windows XP2020-06-13T14:40:18ZNick MathewsonDrop support for Windows XPWindows XP hit its end-of-life today (April 8, 2014).
We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-...Windows XP hit its end-of-life today (April 8, 2014).
We should identify and drop support code for Windows XP. This is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs, and looking for opportunities to move from old busted APIs to fresh new ones.
I'm making this a separate ticket from #11444 (removing support from pre-XP versions) since the timing on the two can be argued to be separate. Nonetheless, if we agree to do both at once, that might be clever.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11446Remove Windows CE support2020-06-13T14:35:21ZNick MathewsonRemove Windows CE supportLong ago we merged some patches to support WinCE. I am pretty sure that nobody actually uses Tor on WinCE now, and I doubt that the code works any more. We should just strip it out.Long ago we merged some patches to support WinCE. I am pretty sure that nobody actually uses Tor on WinCE now, and I doubt that the code works any more. We should just strip it out.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16134The various stream lists tied to the circuit structures should use tor_queue.h2020-06-13T14:46:25ZYawning AngelThe various stream lists tied to the circuit structures should use tor_queue.hOffshoot of #16052.
Every list that uses `edge_connection_t.next_stream`, should be converted to a `TOR_SLIST` for maintainability/sanity. Carved off into a separate ticket because #16052 will probably get a 0.2.6 backport, while this ...Offshoot of #16052.
Every list that uses `edge_connection_t.next_stream`, should be converted to a `TOR_SLIST` for maintainability/sanity. Carved off into a separate ticket because #16052 will probably get a 0.2.6 backport, while this should not as it is rather intrusive (if mechanical).Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/16350tor.pid should be deleted on exit in every case possible, like assert termina...2020-06-13T14:46:51Zyurivict271tor.pid should be deleted on exit in every case possible, like assert termination, and catchable signalsI had tor fail with assertion, printing message into log and exiting, yet it left tor.pid. It could have easily delete it, since this wasn't the non-catchable signal.
It doesn't make sense to leave tor.pid when tor exited.
0.2.6.7 on F...I had tor fail with assertion, printing message into log and exiting, yet it left tor.pid. It could have easily delete it, since this wasn't the non-catchable signal.
It doesn't make sense to leave tor.pid when tor exited.
0.2.6.7 on FreeBSDTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17225Merge NS_EXPIRY_SLOP and REASONABLY_LIVE_TIME2020-06-13T14:49:49ZteorMerge NS_EXPIRY_SLOP and REASONABLY_LIVE_TIMEThese are now the same value (24 hours) so they can be merged into a common header, and the relevant comments removed.These are now the same value (24 hours) so they can be merged into a common header, and the relevant comments removed.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19531Major cleanup in our baseXX APIs2020-06-13T14:59:06ZDavid Gouletdgoulet@torproject.orgMajor cleanup in our baseXX APIsOur base16/32/64 APIs are quite inconsistent and a timebomb of possible errors and issues. Here is some recommendation with this:
1) We should have for _each_ type of encoding a function that returns the encoded size using a source leng...Our base16/32/64 APIs are quite inconsistent and a timebomb of possible errors and issues. Here is some recommendation with this:
1) We should have for _each_ type of encoding a function that returns the encoded size using a source length. We have such function for baese32 and base64 but they are not consistent:
- base32: `base32_encoded_size()` returns the size including the NUL byte
- base64: `base64_encode_size()` has a different name and does NOT add the NUL byte.
They should all return the size with the extra NUL byte because every `_encode()` function we have requires it in the first place. The other solution is to have a new function `baseXX_encoded_string_size()` or something that return the NUL byte and the non string function returns the value without it.
Else we end up with this kind of code pattern:
```
len = base64_encoded_size() + 1
buf = tor_malloc_zero(len)
ret = base64_encode()
tor_assert(ret == len - 1)
```
or the +1 added explicitly like so which is _not_ good.
```
base32_encode(serviceid, REND_SERVICE_ID_LEN_BASE32+1,
circuit->rend_data->rend_pk_digest, REND_SERVICE_ID_LEN);
```
or even better:
```
base16_encode(hex, 2*CONDITIONAL_CONSENSUS_FPR_LEN+1,
ds->v3_identity_digest, CONDITIONAL_CONSENSUS_FPR_LEN);
```
2) Source length requirement issue. I think though most of them are fixed except base64 API with ticket #17868.
I do see this in the `base16_decode` which could either be a _hard_ requirement assert or assume that if it gets 9 bytes in srclen, well only 8 are decoded. We have callsites that do NOT check the returned value so...
```
if ((srclen % 2) != 0)
return -1;
```
3) Every baseXX_encode/decode should return the amount of bytes that has been encoded or decoded. They also should return `ssize_t;` but that's another ticket I feel like because it's a large refactoring. Here are the missing pieces:
- `base16_encode()` returns void so it should return `int` as the encoded length.
- `base32_encode()` returns void.
- `base32_decode()` returns 0 on success.
4) We should also have macros for the encoded length computation else we ended up with stuff like this (taken from the prop250 branch).
```
#define SR_SRV_VALUE_BASE64_LEN \
(((DIGEST256_LEN - 1) / 3) * 4 + 4)
```
or flat values
```
#define REND_DESC_COOKIE_LEN_BASE64 22
```
This is a static calculation so most of the times that macro would be more useful than the function since it could be used for stack allocation which is a BIG use case of ours.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22086Make NO_METHOD a real legit compression method2020-06-13T15:08:14ZNick MathewsonMake NO_METHOD a real legit compression methodThere are a few places in the code that do something like
```
if (compressing) {
tor_compress(...)
} else {
memcpy(...)
}
```
Wouldn't it be great if they could just call tor_compress unconditionally?
They can, if NO_ME...There are a few places in the code that do something like
```
if (compressing) {
tor_compress(...)
} else {
memcpy(...)
}
```
Wouldn't it be great if they could just call tor_compress unconditionally?
They can, if NO_METHOD is treated as a real compression method!Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26142replace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h ...2020-06-13T15:25:48ZTaylor Yureplace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h equivalentsThere are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For exampl...There are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For example, `U64_FORMAT` is equivalent to `PRIu64` in inttypes.h.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28913Base32_decode should return the length of its result.2020-06-13T15:53:46ZNick MathewsonBase32_decode should return the length of its result.The base32_decode() API, for consistency with base64_decode, should return the number of bytes written.
This would also enable us to fuzz it with fuzz_strops.cThe base32_decode() API, for consistency with base64_decode, should return the number of bytes written.
This would also enable us to fuzz it with fuzz_strops.cTor: 0.4.1.x-finalNick MathewsonNick Mathewson