- tor-dev - lists.torproject.org

Summary of meek's costs, January 2015
by David Fifield 07 Feb '15

07 Feb '15

Here's the summary of meek's CDN fees for January 2015. Earlier reports: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 -- total by CDN $1065.00 + $1586.91 + $0.00 = $2651.91 grand total Usage jumped up again in January after a relatively flat December. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… (BTW thanks Karsten for getting the graph ready.) meek has so far been a smashing success. It's the #2 pluggable transport behind obfs3 and it moved over 5 TB of traffic last month. But the costs are starting to get serious. We need to find a good source of funding (e.g., donations), or else start degrading service in order to limit costs. If you are interested in helping with costs, or you know another good means of support, please get in touch with me (PGP AD1A B35C 674D F572 FBCE 8B0A 6BC7 58CB C11F 6276). == App Engine a.k.a. meek-google == Of the total of $464.37, $464.36 was covered by credits. But now we're really out of credits. If you know someone who can get Google credits, or wants to help cover the bill, please put them in touch with me. Here is how the costs broke down: 2944 GB $353.31 2221 instance hours $111.06 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Asia Pacific (Singapore) 147M requests $177.01 1122 GB $153.25 Asia Pacific (Sydney) 220K requests $0.27 1 GB $0.20 Asia Pacific (Tokyo) 57M requests $68.07 378 GB $48.26 EU (Ireland) 92M requests $110.70 726 GB $56.80 South America (Sao Paulo) 2M requests $4.78 10 GB $2.37 US East (Northern Virginia) 31M requests $31.12 212 GB $16.17 -- total 329M requests $391.95 2449 GB $277.05* https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… * The total is $0.02 less than the sum of the subtotals, probably because of rounding. == Azure a.k.a. meek-azure == I haven't been able to get estimated costs out of Azure. However I recently got an email that says, "...we are pleased to offer Microsoft Azure sponsored accounts as part of our Azure for Research (A4R) grants. The new model provides the ability to directly monitor Azure usage, and more options and flexibility for using Azure features and services." I'll try turning that on and see if it makes a difference. https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield

1 0

[PATCH] Fix comparison is always true due to limited range of data type
by Christian Kujau 07 Feb '15

07 Feb '15

Hi, I was unable to compile Tor for powerpc32 for a while but I was unable to bisect it because of other compilation errors (and "git bisect skip" did not help): ----------------------------------------------- CC src/or/scheduler.o In file included from src/or/or.h:91:0, from src/or/scheduler.c:9: src/or/scheduler.c: In function 'scheduler_adjust_queue_size': src/or/scheduler.c:623:18: error: comparison is always true due to limited range of data type [-Werror=type-limits] (dir >= 0) ? "+" : "-", ^ src/or/../common/torlog.h:190:55: note: in definition of macro 'log_debug' log_fn_(LOG_DEBUG, domain, __PRETTY_FUNCTION__, args); \ ^ src/or/scheduler.c:631:11: error: comparison is always true due to limited range of data type [-Werror=type-limits] if (dir >= 0) { ^ cc1: all warnings being treated as errors ----------------------------------------------- The last good version to compile for me was 4ae729683 ("Try to fix test_checkdir windows compilation more"). Below is my attempt to fix this issue by declaring "dir" as "signed char". It compiles now (4.6.3 and 4.9.1) for powerpc32 and Tor seems to work - but please have a look if this is the Right Thing To Do. Thanks, Christian. Declare "char dir" as signed, otherwise compilation on powerpc32 would fail with: ------------------------------------- CC src/or/scheduler.o In file included from src/or/or.h:91:0, from src/or/scheduler.c:9: src/or/scheduler.c: In function 'scheduler_adjust_queue_size': src/or/scheduler.c:623:18: error: comparison is always true due to limited range of data type [-Werror=type-limits] (dir >= 0) ? "+" : "-", ^ src/or/../common/torlog.h:190:55: note: in definition of macro 'log_debug' log_fn_(LOG_DEBUG, domain, __PRETTY_FUNCTION__, args); \ ^ src/or/scheduler.c:631:11: error: comparison is always true due to limited range of data type [-Werror=type-limits] if (dir >= 0) { ^ cc1: all warnings being treated as errors ------------------------------------- Signed-off-by: Christian Kujau <lists(a)nerdbynature.de> scheduler.c | 2 +- scheduler.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/or/scheduler.c b/src/or/scheduler.c index f3fbc4a..78db274 100644 --- a/src/or/scheduler.c +++ b/src/or/scheduler.c @@ -613,7 +613,7 @@ scheduler_touch_channel(channel_t *chan) */ void -scheduler_adjust_queue_size(channel_t *chan, char dir, uint64_t adj) +scheduler_adjust_queue_size(channel_t *chan, signed char dir, uint64_t adj) { time_t now = approx_time(); diff --git a/src/or/scheduler.h b/src/or/scheduler.h index 70f6a39..111e23a 100644 --- a/src/or/scheduler.h +++ b/src/or/scheduler.h @@ -29,7 +29,7 @@ void scheduler_channel_wants_writes(channel_t *chan); MOCK_DECL(void,scheduler_release_channel,(channel_t *chan)); /* Notify scheduler of queue size adjustments */ -void scheduler_adjust_queue_size(channel_t *chan, char dir, uint64_t adj); +void scheduler_adjust_queue_size(channel_t *chan, signed char dir, uint64_t adj); /* Notify scheduler that a channel's queue position may have changed */ void scheduler_touch_channel(channel_t *chan); -- BOFH excuse #103: operators on strike due to broken coffee machine

2 1

Bridge users by transport is broken
by Kevin P Dyer 06 Feb '15

06 Feb '15

The "Bridge users by transport" [1] graph on metrics.torproject.org abruptly stops at Dec. 12 for all transports. Has anyone had an opportunity to troubleshoot this issue? -Kevin [1] https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst…

4 8

Doxbin files
by doxbin＠cmail.nu 06 Feb '15

06 Feb '15

Hi, can anyone please reupload the Doxbin files ( https://archive.today/hsIOj from the https://lists.torproject.org/pipermail/tor-dev/2014-November/007731.html post). I want to review it for vulns on my spare time. Thanks in advance! --

1 0

Re: [tor-dev] Understanding the HS subsystem
by George Kadianakis 04 Feb '15

04 Feb '15

[Declassifying this discussion and posting on [tor-dev]] David Goulet <dgoulet(a)ev0ke.net> writes: > Hello HS elves! > > I wrote a document to organize my thought and also list what we have in > the bug tracker right now about HS behaviours that we want to > understand/measure/assess/track. > > It's a bit long but you can pass the first section describing the > tickets and go right into the How and The Work to be done. > > Nick, you will see there is a SponsorS component but I didn't go into > hard details there. We all know we need a testing network but for now > I'm more focuses on making sure we can collect the right data (for HS). > > Very important part I would like feedback on is the "HS health service" > for which I would like that we all agree of it's usefulness and way to > do it properly. > > Cheers! > David > > This document describes the methodology and technical details of an hidden > service measurement framework/tool/<insert what this is>. > > NOTE: This is NOT intended to be run in the real Tor network. ONLY testing. > > Why and What > ----- > > The goal is to answer some questions we have regarding HS behaviours. Most > of them have a ticket assigned to them but needs an experiment or/and added > feature(s) so we can measure what we need. > > - Is rend_cache_clean_v2_descs_as_dir cutoff crazy high? > https://trac.torproject.org/projects/tor/ticket/13207 > > In order to address this, it seems we need a way to measure all the > interactions with the cache of an HSDir and a client. We need to assess > the rend cache cleanup timing values which will also helps with the upload > and refetch timings. > > - What's the average number of hsdir fetches before we get the hsdesc? > https://trac.torproject.org/projects/tor/ticket/13208 > > Using the control port for that is trivial but this needs a testing > network to be setup and has actual load on it. > > It could also be setup as a feature of an "HS health measurement tool" > with a client fetching over and over the same .onion address randomly over > time. > > - Write a hidden service hsdir health measurer > https://trac.torproject.org/projects/tor/ticket/13209 > > This is a useful one, being able to correlate relay churn and HS desc. > fetch. This one needs more brainstorming on how we could setup some sort > of client or service that report/logs the results on crunching the > consensus for HSDir for a specific .onion address that we know and > control. > > - Refactor rend_client_refetch_v2_renddesc() > https://trac.torproject.org/projects/tor/ticket/13223 > > Insure correctness of this very important function that do fetches for the > client. It's in there that the HSDir (with replicas) are looped on so the > descriptor can be fetched. > > - Maybe we want three preemptive internal circs for hidden services? > https://trac.torproject.org/projects/tor/ticket/13239 > > That's pretty trivial to measure and quantify with the tracing > instrumentation added in Tor. No need for a new feature but an experiment > has to be designed to measure 2 internal circuits versus 3. > > - rend_consider_services_upload() sets initial next_upload_time which is > clobbered when first intro point established? > https://trac.torproject.org/projects/tor/ticket/13483 > > Do the RendPostPeriod option is working correctly. What's the exact > relation in time of service->desc_is_dirty and upload time of a new > descriptor. > > - Do we have edge cases with rend_consider_descriptor_republication()? Can > we refactor it to be cleaner? > https://trac.torproject.org/projects/tor/ticket/13484 > > This is a core function that is called every second so we should make sure > it behaving as expected and not trying to do uneeded upload. > Hello, nice list of tickets. Here are some more ideas if you are looking for more brainstorming action. There is #3733 which is about a behavior that affects performance and could benefit from a testing network. And there is #8950 which is about the number of IPs per hidden service. It's very unclear whether this functionality works as intended or whether it's a good privacy idea. And there is also #13222 but it's probably easier to hack the solution here, than to measure its severity. > > How > ----- > > Here are some steps I think are needed to be able to measure and answer the > Why section. > 2> 1) Dump the uploaded/fetched HS in a human readable way. > * Allows us to track descriptor over time while testing and analyse them > afterwards by correlating events with a readable desc. This kind of > feature will also be useful for people crawling HS on SponsorR. > * Should be a control event like for instance (ONLY client side): > > setconf HSDESC_DUMP /tmp/my/dir > > 2) On how many HSDir (including replicas) have been probed for one > single .onion request. (Which should be repeated a lot for significant > results.) > * Why have we probed 1 or 5? > * What made us retry? Failure code? > * Did the descriptor was actually alive on the HSDir? If not, when did > it move? (Correlate timings between HSdir and client in a testing network) > > 3) HS desc cache tracker. We want to know, very precisely, how things are > moving in the cache especially on the HSDir cache side. > * When and why an HS desc is removed? > * Why it hasn't been stored in the cache? > * Count and when a descriptor is requested. > > 4) Track the HS descriptor upload. Log at what time it was done. Use this > to correlate with RendPostPeriod or when desc_is_dirty is set. Also should > be correlate with the actual state of the HSDir. Did it already have it? > Is the HSDir gone? > > > What to be done > ---------------- > > * Collect data > > "Collect it all" --> https://i.imgur.com/tVXAcGGl.jpg > > It's clear that we have to collect more data from the HS subsystem. Most of > it can be collected through the control port but some are missing. > Measuring precise timing of HS actions (for instance let say descriptor > store) is not possible with the control port right now and also might not be > that relevant since the job of this feature is to report high level events > and push command to the tor daemon. > > Tracing should be used here with a set of events added to the HS subsystem > to collect the information we need so it can be analyzed after the > experiment is run. This is only for performance measurement, the rest should > as much as possible use the control port. > > * Testing network (much SponsorS) > > Once we are able to extract all the data we need, time to design experiment > that allows us to run scenarios and collect/analyze what we want. A scenario > could be this example with a set of questions we want to answer going with > it: > > * 50 clients randomly accessing an HS in a busy tor network. > - What is the failure rate of desc. fetch, RP establishment, ...? > - What are the timings of each component of the HS subsystem? > - What are the outliers of the whole process of establishing a connection > to the HS? > - How much relay churn affected HS reachability. > > And dump a human readable report/graphs whatever is useful for us to > investiguate or assess the HS functionnalities. > > * HS health service > > ref: https://trac.torproject.org/projects/tor/ticket/13209 > > What about a web page that prints the result of: > > 1) Fetch last 3 concensuses (thus 3 hours) > 2) Find the union of all HSDir responsible for a.onion (we control that > HS service and should be up at all time else the results are meaningless.) > 3) Fetch the descriptor on each of them > 4) Graph/log how many of them had it thus giving us a probability of > reaching the HS within a time period. > > So 3) is the tricky one. There are multiple ways of achieving that possibly: > > i) New SOCKS command to tor that a client could use. > - Command would have an onion address with it and the reply should be 0 > or 1 (successful attempt or not) with the HSDir fingerprint with it. > > ii) Control event. > > setconf HSDESC_FETCH_ALL <this_is_a.onion> > [...] > Prints out the results as they come in with the HSDir information. > > iii) A weird way of doing this with an option "tor --fetch-on-all-hs-dir > this_address.onion", print out the results and quit. > > I much prefer i) and ii) here. Not sure which one is best though. Hm, I think I like (ii) here. It doesn't seem to be much more work than (i) and a few researchers have been asking for such functionality for years.

1 0

ANN: txtorcon 0.12.0
by meejah 03 Feb '15

03 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce txtorcon 0.12.0. Full list of improvements: * doc, code and import cleanups from Kali Kaneko * HiddenServiceDirGroupReadable support * Issue #80: honour "ControlPort 0" in incoming TorConfig instance. The caller owns both pieces: you have to figure out when it's bootstraped, and are responsible for killing it off. * Issue #88: clarify documentation and fix appending to some config lists * If GeoIP data isn't loaded in Tor, it sends protocol errors; if txtorcon also hasn't got GeoIP data, the queries for country-code fail; this error is now ignored. * 100% unit-test coverage! * PyPy support (as in: all tests pass) * TCP4HiddenServiceEndpoint now waits for descriptor upload before the listen() call does its callback (this means when using "onion:" endpoint strings, or any of the endpoints APIs your hidden service is 100% ready for action when you receive the callback) * "TorControlProtocol now has an ".all_routers" member, which is a set() of all Routers * TimeIntervalCommaList from Tor config supported * documentation fix from "sammyshj" You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.12.0 https://github.com/meejah/txtorcon/releases/tag/v0.12.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.12.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.12.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 206b1bd8a840119c12d9b85d638ab9defec5b376436fa36be9139ab1ebc8cd78 txtorcon-0.12.0.tar.gz 4e4f6aa2ec677f6c27bff41d17888d31a979f6b831a20501101b39ca93ede9da txtorcon-0.12.0-py2-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJU0TWHAAoJEMJgKAMSgGmnDEoH/AriLbAyImmcfmRy5C2YcVth eJyXRhHTXc6WBh0tBgryt88o5n55XAwiqNoAwslLvS4RS6w9NEzA9zusimuVYEZs CV10NeC5PiXHJ6qDlcJ+FPsHhWk4zt49wGtaqyfGK/8aZm9enQwiMH6j9Iwx6il0 rLFwm7RoukPTW8dn3oR67QFYwdpHD7cCQW8e6uajpQuBCeNr2nljRpVLFM/6hueh shIAAmPGfBQ2vR16QOQDyJMCLk7oKj0xtzok8O4fWBof1+h3JvMQqphEYlgtE5Lh 9W0XgG/ugrrhjIIoKc29+4Io5vaqKjHcGfqEyJyEimppgGB/6YTX2fJNw2R3Op4= =vaqH -----END PGP SIGNATURE-----

1 0

[Proposal 241] Resisting guard-turnover attacks [DRAFT]
by Nick Mathewson 03 Feb '15

03 Feb '15

Filename: 241-suspicious-guard-turnover.txt Title: Resisting guard-turnover attacks Author: Aaron Johnson, Nick Mathewson Created: 2015-01-27 Status: Draft 1. Introduction Tor uses entry guards to prevent an attacker who controls some fraction of the network from observing a fraction of every user's traffic. If users chose their entries and exits uniformly at random from the list of servers every time they build a circuit, then an adversary who had (k/N) of the network would deanonymize F=(k/N)^2 of all circuits... and after a given user had built C circuits, the attacker would see them at least once with probability 1-(1-F)^C. With large C, the attacker would get a sample of every user's traffic with probability 1. To prevent this from happening, Tor clients choose a small number of guard nodes (currently 1: see proposal 236). These guard nodes are the only nodes that the client will connect to directly. If they are not compromised, the user's paths are not compromised. But attacks remain. Consider an attacker who can run a firewall between a target user and the Tor network, and make many of the guards they don't control appear to be unreachable. Or consider an attacker who can identify a user's guards, and mount denial-of-service attacks on them until the user picks a guard that the attacker controls. In the presence of these attacks, we can't continue to connect to the Tor network unconditionally. Doing so would eventually result in the user chosing a hostile node as their guard, and losing anonymity. 2. Proposed behavior Keep a record of all the guards we've tried to connect to, connected to, or extended circuits through in the last PERIOD days. (We have connected to a guard if we authenticate its identity. We have extended a circuit through a guard if we built a multi-hop circuit with it.) If the number of guards we have *tried* to connect to in the last PERIOD days is greater than CANDIDATE_THRESHOLD, do not attempt to connect to any other guards; only attempt the ones we have previously *tried* to connect to. If the number of guards we *have* connected to in the last PERIOD days is greater than CONNECTED_THRESHOLD, do not attempt to connect to any other guards; only attempt ones we have already *successfully* connected to. If we fail to connect to NET_THRESHOLD guards in a row, conclude that the network is likely down. Stop/notify the user; retry later; add no new guards for consideration. [[ optional If we notice that USE_THRESHOLD guards that we *used for circuits* in the last FAST_REACT_PERIOD days are not working, but some other guards are, assume that an attack is in progress, and stop/notify the user. ]] 2.1. Suggested parameter thresholds. PERIOD -- 60 days FAST_REACT_PERIOD -- 10 days CONNECTED_THRESHOLD -- 8 CANDIDATE_THRESHOLD -- 20 NET_THRESHOLD -- 10 (< CANDIDATE_THRESHOLD) [[ optional USE_THRESHOLD -- 3 (< CONNECTED_THRESHOLD) ]] (Each of the above should have a corresponding consensus parameter.) 2.2. What do we mean by "Stop/warn"? By default, we should probably give warnings in most of the above cases for the first version that deploys them. We can have an on/off/auto setting for whether we will build circuits at all if we're in a "stopped" mode. Default should be auto, meaning off for now. The warning needs to be carefully chosen, and suggest a workaround better than "get a better network" or "clear your state file". 2.3. What's with making USE_THRESHOLD optional? Aaron thinks that getting rid of it might help in the fascistfirewall case. I'm a little unclear whether that makes any of the attacks easier. 3. State storage requirements Right now, we save for each guard that we have made contact with: ID Added is dircache? down-since last-attempted bad-since chosen-on-date, chosen-by-version path bias info (circ_attempts, successes, close_success) To implement the above proposal, we'll need to add, for each guard *or guard candidate*: when did we first decide to try connecting to it? when did we last do one of: decide to try connecting to it? connect to it? build a multihop circuit through it? which one was it? Probably round these to the nearest day or so. 4. Future work We need to make this play nicely with mobility. When a user has three guards on port 9001 and they move to a firewall that only allows 80/443, we'd prefer that they not simply grind to a halt. If nodes are configured to stop when too many of their guards have gone away, this will confuse them. If people need to turn FascistFirewall on and off, great. But if they just clear their state file as a workaround, that's not so good. If we could tie guard choice to location, that would help a great deal, but we'd need to answer the question, "Where am I on the network", which is not so easy to do passively if you're behind a NAT. Appendix A. Scenario analysis A.1. Example attacks * Filter Alice's connection so they can only talk to your guards. * Whenever Alice is using a guard you don't control, DOS it. A.2. Example non-attacks * Alice's guard goes down. * Alice is on a laptop that is sometimes behind a firewall that blocks a guard, and sometimes is not. * Alice is on a laptop that's behind a firewall that blocks a lot of the tor network, (like, everything not on 80/443). * Alice has a network connection that sometimes turns off and turns on again. * Alice reboots her computer periodically, and tor starts a little while before the network is live. Appendix B. Acknowledgements Thanks to Rob Jansen and David Goulet for comments on earlier versions of this draft.

3 2

[RESEARCH] Student of University of Verona, Thesis about TOR
by Diego Sempreboni 02 Feb '15

02 Feb '15

Hi, I am a student of Engineering of the University of Verona. For my master's thesis, I decided to analyze TOR network, analyzing various attack scenarios. By consulting several documents have not been able to obtain a pattern of messages exchanged during the handshake protocol nor other details about the packets exchanged later. It would be possible to have some information about this? I write hoping someone can help me. Thank you.

3 2

Estimating censorship lag by obfs4 blocking
by David Fifield 02 Feb '15

02 Feb '15

According to a couple of blog comments on February 1, 2015, the default obfs4 bridges are blocked by GFW. https://blog.torproject.org/blog/tor-browser-45a3-released#comment-86416 https://blog.torproject.org/blog/tor-browser-45a3-released#comment-86907 The obfs4 bridges were introduced on November 17, 2014. https://blog.torproject.org/blog/tor-browser-45-alpha-1-released I have a message from Yawning Angel verifying that the obfs4 bridges were reachable on December 2, 2014. With this information, we can put rough bounds on how long it took the GFW to react to a new circumvention system: between 2 and 10 weeks. Does anyone know information that could tighten up the bounds, a date between December 2 and February 1 when obfs4 bridges were known to be either accessible or inaccessible? David Fifield

1 0

Damian's Status Report - January 2015
by Damian Johnson 01 Feb '15

01 Feb '15

Greetings wonderful world. January has been delightfully focused on a couple substantial feature branches that are now merged! -------------------------------------------------------------------------------- Descriptor Lazy Loading -------------------------------------------------------------------------------- When reading descriptors without validation (which is now the default) Stem is 25-70% faster! https://lists.torproject.org/pipermail/tor-dev/2015-January/008211.html This is because we now parse descriptors fields on-demand. Just need a server descriptor's exit policy? That's all we'll bother reading. This is why the heavier the descriptor type the larger the benefit. -------------------------------------------------------------------------------- Unified Python 2/3 Codebase -------------------------------------------------------------------------------- Thanks to Foxboron Stem now has a unified python 2/3 codebase! https://trac.torproject.org/projects/tor/ticket/14075 This means that Stem now runs directly with any version of python from 2.6 to 3.x. Prior to this Stem did a 2to3 export when you installed it to provide cross-version compatibility. For users, the benefit of Foxboron's overhaul is that python3 installation and test runs are now much, much quicker. -------------------------------------------------------------------------------- Beside these a few other noteworthy tasks were... * Nick had a handful of suggestions for testing improvements, neatest of which was to include the command to re-run just individual tests when we have a failure. (#14113) * Our port_usage() function always returned None. (#14046) * Proc connection resolution could fail on busy systems. (#14048) * Fixed how the 'strict' argument works with exit policies. (#14314) Cheers! -Damian

1 0