Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:52:27Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33678Disable practracker in git hooks in maint-0.4.32020-06-13T15:52:27ZteorDisable practracker in git hooks in maint-0.4.3Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33674Check return value handling in the relay and dirauth stubs2020-06-13T15:52:27ZteorCheck return value handling in the relay and dirauth stubsIn #33668, we discovered a relay module stub that didn't handle an `int *have_low_ports_out` return value correctly.
We should check all the relay and dirauth module return values, including pointer out and inout return values.In #33668, we discovered a relay module stub that didn't handle an `int *have_low_ports_out` return value correctly.
We should check all the relay and dirauth module return values, including pointer out and inout return values.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33673Use the right DLLs and pkg-config path on Appveyor2020-06-13T15:52:26ZteorUse the right DLLs and pkg-config path on AppveyorWe want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from #33643, which is the urgent CI fix.We want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from #33643, which is the urgent CI fix.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-13T15:52:25ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2020-06-13T18:21:52ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33668--disable-module-relay yields to a Bug:2020-06-13T15:52:24Ztoralf--disable-module-relay yields to a Bug:At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and L...At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 19 19:44:35.840 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 19 19:44:35.840 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 19 19:44:35.840 [notice] Read configuration file "/etc/tor/torrc".
Mar 19 19:44:35.843 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:1473: options_switch_id: Assertion have_low_ports != -1 failed; aborting. (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.844 [err] Bug: Tor 0.4.3.3-alpha: Assertion have_low_ports != -1 failed in options_switch_id at src/app/config/config.c:1473: . Stack trace: (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(log_backtrace_impl+0x59) [0x5564677d3ab9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_assertion_failed_+0x150) [0x5564677cecb0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(set_options+0x404) [0x5564677535d4] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(+0x1648a0) [0x5564677548a0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_string+0x119) [0x556467754af9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_torrc+0x359) [0x5564677550f9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_init+0x1c7) [0x55646764ade7] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_run_main+0x71) [0x55646764b4e1] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_main+0x46) [0x55646764a006] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(main+0x19) [0x556467649bd9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ff9817b8f1b] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(_start+0x2a) [0x556467649c2a] (on Tor 0.4.3.3-alpha )
Aborted
```
The same tarball at the same system works fine with that option being enabled.
The config is
```
cat /etc/tor/torrc
User tor
PIDFile /var/run/tor/tor.pid
Log notice file /tmp/notice.log
DataDirectory /var/lib/tor/data
CookieAuthentication 1
ControlPort 9051
SocksPort 9050
SandBox 1
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33651Suspicious "fetched this many bytes" counts from #327202020-06-13T15:52:24ZRoger DingledineSuspicious "fetched this many bytes" counts from #32720Following #32720, now I have these log messages in my Tor client:
```
Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 166.22 ...Following #32720, now I have these log messages in my Tor client:
```
Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 166.22 MB and received 5.25 GB.
Mar 17 23:52:49.178 [notice] While bootstrapping, fetched this many bytes:
Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
Mar 17 23:52:49.178 [notice] While not bootstrapping, fetched this many bytes:
Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
Mar 17 23:52:49.178 [notice] Average packaged cell fullness: 52.843%. TLS write overhead: 3%
Mar 18 17:01:52.177 [notice] Your system clock just jumped 44387 seconds forward; assuming established circuits no longer work.
Mar 18 18:12:33.010 [notice] Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 166.25 MB and received 5.25 GB.
Mar 18 18:12:33.011 [notice] While bootstrapping, fetched this many bytes:
Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
Mar 18 18:12:33.011 [notice] While not bootstrapping, fetched this many bytes:
Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
Mar 18 18:12:33.011 [notice] Average packaged cell fullness: 52.898%. TLS write overhead: 3%
Mar 19 00:12:33.013 [notice] Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 166.26 MB and received 5.25 GB.
Mar 19 00:12:33.013 [notice] While bootstrapping, fetched this many bytes:
Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
Mar 19 00:12:33.013 [notice] While not bootstrapping, fetched this many bytes:
Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
Mar 19 00:12:33.013 [notice] Average packaged cell fullness: 52.953%. TLS write overhead: 3%
```
I'm running
```
Tor 0.4.4.0-alpha-dev (git-d4595b344a1a3254) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
```
It is surprising to me that I have the same number while bootstrapping and while not bootstrapping, and that number doesn't seem to go up.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33650Verify that intro2 cell extensions actually work2020-06-13T15:52:23ZRoger DingledineVerify that intro2 cell extensions actually workIn the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprisin...In the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprising asserts or surprising length enforcement.
(Now is the time to notice if things will go wrong, so we can fix them and deploy that fix, and then people will have upgraded by the time we're ready to actually use them.)
So: let's make a branch that adds "hi mom" on the client side, and reads it out again on the service side.
In spelunking through the code and the spec, I found that modern intro2 cells have an "extensions" field inside their encrypted component, which seems perfectly suited for transporting arbitrary blobs from client to service. Here's how we set it currently on the client side:
```
/* Set extension data. None are used. */
ext = trn_cell_extension_new();
tor_assert(ext);
trn_cell_extension_set_num(ext, 0);
trn_cell_introduce_encrypted_set_extensions(enc_cell, ext);
```
So that 0 needs to become a 1, and then we need something new that makes and sets a new extension in ext (modeled maybe on `build_establish_intro_dos_extension()`, and something on the receiving end that invokes trn_cell_extension_parse() and reads it out to us.
I am optimistic, because this thing is encrypted, so the intro point in the middle can't be looking at it very carefully. But if we have bugs on the client side or the service side, or surprise length enforcement in the middle, now is a great time to notice and fix them.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/33648vanguards: What is the recommended value?2020-06-13T15:52:22Zcypherpunksvanguards: What is the recommended value?Since your default configuration & github document doesn't tell me much, I'd like to hear developer's opinion on this.
vanguards.conf
Bandguards:
circ_max_age_hours = 1 (Mine is just simple WWW service without fancy WebSockets, downl...Since your default configuration & github document doesn't tell me much, I'd like to hear developer's opinion on this.
vanguards.conf
Bandguards:
circ_max_age_hours = 1 (Mine is just simple WWW service without fancy WebSockets, downloads or videos)
circ_max_hsdesc_kilobytes = 30
circ_max_megabytes = 5
Q1. Is using smaller value such as 1 for circ_max_age_hours have any problems regarding anonymity?
Q2. You didn't mention default size of hidden service descriptor. What value is it? This is not OnionShare or onionbalance.
(if you can do {circ_max_hsdesc_kilobytes != normal_desc_size kill_connection} that's great)
Q3. You said "HTTP GET can resume if this limit is hit, HTTP POST will not" in circ_max_megabytes. You better add this text, don't you think: "If the client reach this limit, we close the connection and create another one to continue operation. Client will experience small downtime."
Q4. Can you add an option to slow down packets on purpose, to prevent simple DDoS? e.g. 'limit_packets_per_seconds = 10' will allow 10 packets per seconds and delay exceeded packets (x) secondsTor: unspecifiedMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/33646Wrong list of enabled modules2020-06-13T15:52:22ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: #32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-13T15:52:21ZteorAppveyor: OpenSSL version mismatch in unit tests, 2020 editionIt's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like #32449, #28574, #28399 and #25942....It's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like #32449, #28574, #28399 and #25942.
We think our tests are fragile, because they are not copying the necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
```
ssl
crypto
lzma
event
zstd
```
We already copy zlib and ssp at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .
These libraries might have different dll prefixes or suffixes, for example, OpenSSL is:
```
/mingw32/bin/libcrypto-1_1.dll
/mingw32/bin/libssl-1_1.dll
```
https://packages.msys2.org/package/mingw-w64-i686-openssl
We might also want to copy these libraries into the same directory as the tor executable `${env:build}/src/app`, before we run the tests that launch tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33642Add *.a to .gitignore2020-06-13T15:52:20ZDavid Gouletdgoulet@torproject.orgAdd *.a to .gitignoreMade a mistake to add a .a file while switching from 043 and master into a branch.
I think adding `*.a` to .gitignore should be a reasonable idea since these files are always generated in our build system.Made a mistake to add a .a file while switching from 043 and master into a branch.
I think adding `*.a` to .gitignore should be a reasonable idea since these files are always generated in our build system.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33641Spurious coverity unreachable warning after all bugs are fatal test skip2020-06-13T15:52:19ZteorSpurious coverity unreachable warning after all bugs are fatal test skipThere's a spurious coverity warning about unreachable code, in tests that we're skipping when ALL_BUGS_ARE_FATAL is defined.
I guess we need to wrap those skips in `#ifndef COVERITY`.
```
** CID 1460753: Control flow issues (UNREACHA...There's a spurious coverity warning about unreachable code, in tests that we're skipping when ALL_BUGS_ARE_FATAL is defined.
I guess we need to wrap those skips in `#ifndef COVERITY`.
```
** CID 1460753: Control flow issues (UNREACHABLE)
/src/test/test_dir.c: 4998 in test_dir_purpose_needs_anonymity_returns_true_by_default()
________________________________________________________________________________________________________
*** CID 1460753: Control flow issues (UNREACHABLE)
/src/test/test_dir.c: 4998 in test_dir_purpose_needs_anonymity_returns_true_by_default()
4992 (void)arg;
4993
4994 #ifdef ALL_BUGS_ARE_FATAL
4995 tt_skip();
4996 #endif
4997
CID 1460753: Control flow issues (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
4998 tor_capture_bugs_(1);
4999 setup_full_capture_of_logs(LOG_WARN);
5000 tt_int_op(1, OP_EQ, purpose_needs_anonymity(0, 0, NULL));
5001 tt_int_op(1, OP_EQ, smartlist_len(tor_get_captured_bug_log_()));
5002 expect_single_log_msg_containing("Called with dir_purpose=0");
5003
** CID 1460752: Control flow issues (UNREACHABLE)
/src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
________________________________________________________________________________________________________
*** CID 1460752: Control flow issues (UNREACHABLE)
/src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
117 #ifdef ALL_BUGS_ARE_FATAL
118 tt_skip();
119 #endif
120
121 MOCK(count_acceptable_nodes, mock_count_acceptable_nodes);
122
CID 1460752: Control flow issues (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
123 tor_capture_bugs_(1);
124 setup_full_capture_of_logs(LOG_WARN);
125 r = new_route_len(CIRCUIT_PURPOSE_CONTROLLER, &dummy_ei, &dummy_nodes);
126 tt_int_op(DEFAULT_ROUTE_LEN + 1, OP_EQ, r);
127 tt_int_op(smartlist_len(tor_get_captured_bug_log_()), OP_EQ, 1);
128 tt_str_op(smartlist_get(tor_get_captured_bug_log_(), 0), OP_EQ,
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33640Add PATH_BIAS_TESTING purpose to specs2020-06-13T15:52:19ZGeorg KoppenAdd PATH_BIAS_TESTING purpose to specsSimilar to #33639 I found
```
2020-03-17 21:26:35,977 stem [INFO] CIRC event had an unrecognized purpose (PATH_BIAS_TESTING). Maybe a new addition to the control protocol? Full Event: 'CIRC 322 CLOSED $8E915C44FD55A433CCAFACF4902BF1B2B16...Similar to #33639 I found
```
2020-03-17 21:26:35,977 stem [INFO] CIRC event had an unrecognized purpose (PATH_BIAS_TESTING). Maybe a new addition to the control protocol? Full Event: 'CIRC 322 CLOSED $8E915C44FD55A433CCAFACF4902BF1B2B16DD36C~snap277,$ECE90C4159D916921F7C8DDF4D088AC3808C521D~piss PURPOSE=PATH_BIAS_TESTING TIME_CREATED=2020-03-17T20:26:15.358481 REASON=FINISHED'
```
in my `stem` logs and it seems `PATH_BIAS_TESTING` needs to get added to the specs as a "new" `PURPOSE` so `stem` can pick this up, too.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33639Add CHANNEL_CLOSED reason to specs2020-06-13T15:52:18ZGeorg KoppenAdd CHANNEL_CLOSED reason to specsI was recently looking at stem debug logs and found
```
2020-03-17 21:10:58,838 stem [INFO] CIRC event had an unrecognized remote_reason (CHANNEL_CLOSED). Maybe a new addition to the control protocol? Full Event: 'CIRC 6 FAILED $0CDD60E4...I was recently looking at stem debug logs and found
```
2020-03-17 21:10:58,838 stem [INFO] CIRC event had an unrecognized remote_reason (CHANNEL_CLOSED). Maybe a new addition to the control protocol? Full Event: 'CIRC 6 FAILED $0CDD60E4015EBF2C3B5D32A2B9CC8FE6C98A5C33~UnivUtah3 PURPOSE=GENERAL TIME_CREATED=2020-03-17T20:10:25.388134 REASON=DESTROYED REMOTE_REASON=CHANNEL_CLOSED'
```
I am not sure how the `stem` workflow works but I guess it's an implementation based on the spec(s) (not what is actually used/allowed in the tor code).
Thus, we should fix the spec(s) first so we can add the respective `stem` part later on.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33635Regenerate practracker exceptions in master2020-06-13T15:52:18ZteorRegenerate practracker exceptions in masterEvery so often, we do a full regenerate of the practracker exceptions file.
A full regenerate accepts the current state of the tor codebase, and clears the list of practracker warnings.
That way, reviewers can focus on new warnings. (A...Every so often, we do a full regenerate of the practracker exceptions file.
A full regenerate accepts the current state of the tor codebase, and clears the list of practracker warnings.
That way, reviewers can focus on new warnings. (And we aren't confusing new users.)
Ideally, we should slowly be removing files and functions from the exceptions file, as we resolve technical debt.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33633Move extend and reachability code to the relay module2020-06-13T15:52:17ZteorMove extend and reachability code to the relay moduleMost of the extend and reachability code is already in the relay module.
But some code was left behind in src/core/or/circuitbuild.c.Most of the extend and reachability code is already in the relay module.
But some code was left behind in src/core/or/circuitbuild.c.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33632List ed25519 fingerprints on the command line2020-06-13T15:52:16ZteorList ed25519 fingerprints on the command lineFor RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to #30642, which ...For RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to #30642, which adds an `ed25519-fingerprint` file.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33629Use stale bot to close old pull requests2020-06-13T15:52:16ZteorUse stale bot to close old pull requestsShould we automatically close stale pull request on GitHub?
Some GitHub users won't contribute to a project with lots of open pull requests, because they think it's been abandoned. (Or they think we're bad at merging PRs.)
But lots of ...Should we automatically close stale pull request on GitHub?
Some GitHub users won't contribute to a project with lots of open pull requests, because they think it's been abandoned. (Or they think we're bad at merging PRs.)
But lots of our PRs get left open because we've squashed and merged the PR, and GitHub doesn't recognise the squashed commits, so GitHub doesn't auto-close the PR.
Closing a PR:
* hides it from the default list of PRs
* hides its CI results in the PR itself (but they still appear in the PR list)
Anyone can reopen a closed PR. Re-opening a PR re-runs CI (which is usually what we want for old PRs).
I suggest we use probot stale:
https://probot.github.io/apps/stale/
With the following options:
* daysUntilStale: 60
* some backport PRs are older than 60 days, but their CI should have been checked when they were reviewed
* we don't merge very many stale PRs to master
* any period from 30 days (most reviews completed) to 6 months (release cycle) would probably work for us
* daysUntilClose: 7
* exemptLabels: pinned
* staleLabel: stale-closed
* markComment: (like the suggested one, but mention the "pinned" label)
* closeComment: false
On the following network team repositories:
* tor
* ~400 older than 2 months
* ~270 older than 6 months
* torspec
* 8 older than 2 months
* 6 older than 6 months
* chutney
* 1 older than 6 months, needs to be pinned?
* fallback-scripts
And the top-level GitHub config repository:
* .githubTor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33624Static building tor with openssl does not work2020-06-13T15:52:15ZDavid Gouletdgoulet@torproject.orgStatic building tor with openssl does not workWe have couple opened ticket about building OpenSSL statically: #31565 and #32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which we need to build tor w...We have couple opened ticket about building OpenSSL statically: #31565 and #32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which we need to build tor with openssl and libevent statically.
At current master, this is not working for build system and code reasons.
This ticket is to address it all so we can close all other related tickets.
Here is a raw tor.git diff that makes this work. There is still some think to consider especially with the `OPENSSL_VERSION`:
https://gitlab.torproject.org/dgoulet/tor-library-size/blob/master/tor.diffTor: 0.4.4.x-final