August 2021 - tor-dev - lists.torproject.org

What happens to my hidden service?
by Liste 29 Dec '25

29 Dec '25

Hidden service is unavailable, but tor is running. Tor's log: Dec 12 18:10:27.000 [notice] Your Guard SECxFreeBSD64 ($D7DB8E82604F806766FC3F80213CF719A0481D0B) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 199/285. Use counts are 101/101. 253 circuits completed, 0 were unusable, 54 collapsed, and 15 timed out. For reference, your timeout cutoff is 60 seconds. is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Dec 12 18:15:53.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service xxxxxxxxxxxxxxx. Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [268 similar message(s) suppressed in last 600 seconds] Dec 11 13:43:12.000 [warn] onion_skin_client_handshake failed. Dec 11 13:43:12.000 [warn] circuit_finish_handshake failed. Dec 11 13:43:12.000 [warn] connection_edge_process_relay_cell (at origin) failed. Dec 11 00:34:57.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service .... Dec 10 10:09:01.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:03.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:04.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 12:42:19.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t.

3 2

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

Client identification for authenticated onions
by cho8jeiv4aus＠paperboats.net 12 Dec '21

12 Dec '21

Hi there. I had an idea recently for an onion service to improve the UX of sites that require a login. The site would have two onions: one for those who want to use onion auth and another for those who don't or are still setting it up. A user would first sign in with a username+password on the unauthenticated onion and click a button to generate a certificate associated with their account. Then they would add the public key to their browser and visit the authenticated onion. The application server would then match the pubkey used to authenticate with an account in the database, and log them in automatically. I've looked in the mailing list archives and `man 1 tor` but didn't find anything that would facilitate this. The closest, it seems, is HiddenServiceExportCircuitID, but that is for *circuit* IDs, not *client* IDs. Is this possible to implement, either as an operator or as a Tor developer? As an operator, an alternative would be to generate one (authenticated) onion service per user and route them all to the same place with different Host headers, but that seems rather inefficient, and I don't know how well the tor daemon scales up to hundreds of onion services anyway. P.S. I didn't find an easy way to do full text search on the mailing list archives, so I wrote a little script to download them all. I've attached it in case it ends up useful. It requires python3.8+ and you'll need to `pip install aiohttp anyio BeautifulSoup4` first. After that you can run `./pipermail_fetch.py https://lists.torproject.org/pipermail/tor-dev/` and then something like `rg --context 3 --search-zip '^[^>].*search term here'` will do the trick.

3 2

IANA well-known URI suffix registration for tor-relay-fingerprints file
by nusenu 10 Oct '21

10 Oct '21

Hi, to reduce the risk of certain kinds of attacks I'm aiming to submit a short spec (like [1]) in accordance with RFC8615 https://tools.ietf.org/html/rfc8615#section-3.1 for the registration of of a suffix for the verifyurl from https://github.com/nusenu/ContactInfo-Information-Sharing-Specification#ver… The name I have in mind is: tor-relay-fingerprints The file contains comments (lines starting with #) and relay fingerprints. https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Let me know if you have any feedback on this and whether you have any opinion on whether you (The Torproject) wants to be the change controller. The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)? thanks, nusenu -- https://mastodon.social/@nusenu [1] https://keybase.io/docs/keybase_well_known

5 22

Updated Proposal 324: RTT-based Congestion Control for Tor
by Mike Perry 06 Oct '21

06 Oct '21

As a heads up, I have updated Proposal 324: RTT-based Congestion Control for Tor - https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rt… The updated version has a new congestion control algorithm, detailed specifics on how to accurately measure RTT and BDP, and descriptions of algorithm parameter values and tuning experiments, among other improvements. A C implementation of these algorithms has been merged to tor.git orgin/main. They live in src/core/or/congestion_control_*.[ch]. These algorithms are not enabled yet; we still need to implement flow control and negotiation, as well as do shadow experimentation to determine good candidate parameter values to further tune on live. Here is a full changelog since the proposal was last published to tor-dev: - Correct algorithms to update once per congestion window - Add orconn blocking and edge connection checks as signals - Specify BDP estimators based on onion service testing and eval. - Specify a pure BDP tracking congestion control algorithm (TOR_NOLA) - Update consensus parameters with tuning notes - Document what we learned so far in live onion service experimentation - Mention that we need to test intermittent downloads in Shadow/live - Describe clock jump and stall detection during RTT measurement - Mention if we calculate package window, it can become negative - Break off the backwards ECN idea into a future idea draft: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/ideas/… - Update old trac URLs - Add Acknowledgements Review and comments are welcome! -- Mike Perry

1 1

Proposal 332: Ntor protocol with extra data, version 3.
by Nick Mathewson 18 Sep '21

18 Sep '21

``` Filename: 332-ntor-v3-with-extra-data.md Title: Ntor protocol with extra data, version 3. Author: Nick Mathewson Created: 12 July 2021 Status: Open ``` # Overview The ntor handshake is our current protocol for circuit establishment. So far we have two variants of the ntor handshake in use: the "ntor v1" that we use for everyday circuit extension (see `tor-spec.txt`) and the "hs-ntor" that we use for v3 onion service handshake (see `rend-spec-v3.txt`). This document defines a third version of ntor, adapting the improvements from hs-ntor for use in regular circuit establishment. These improvements include: * Support for sending additional encrypted and authenticated protocol-setup handshake data as part of the ntor handshake. (The information sent from the client to the relay does not receive forward secrecy.) * Support for using an external shared secret that both parties must know in order to complete the handshake. (In the HS handshake, this is the subcredential. We don't use it for circuit extension, but in theory we could.) * Providing a single specification that can, in the future, be used both for circuit extension _and_ HS introduction. # The improved protocol: an abstract view Given a client "C" that wants to construct a circuit to a relay "S": The client knows: * B: a public "onion key" for S * ID: an identity for S, represented as a fixed-length byte string. * CM: a message that it wants to send to S as part of the handshake. * An optional "verification" string. The relay knows: * A set of [(b,B)...] "onion key" keypairs. One of them is "current", the others are outdated, but still valid. * ID: Its own identity. * A function for computing a server message SM, based on a given client message. * An optional "verification" string. This must match the "verification" string from the client. Both parties have a strong source of randomness. Given this information, the client computes a "client handshake" and sends it to the relay. The relay then uses its information plus the client handshake to see if the incoming message is valid; if it is, then it computes a "server handshake" to send in reply. The client processes the server handshake, and either succeeds or fails. At this point, the client and the relay both have access to: * CM (the message the client sent) * SM (the message the relay sent) * KS (a shared byte stream of arbitrary length, used to compute keys to be used elsewhere in the protocol). Additionally, the client knows that CM was sent _only_ to the relay whose public onion key is B, and that KS is shared _only_ with that relay. The relay does not know which client participated in the handshake, but it does know that CM came from the same client that generated the key X, and that SM and KS were shared _only_ with that client. Both parties know that CM, SM, and KS were shared correctly, or not at all. Both parties know that they used the same verification string; if they did not, they do not learn what the verification string was. (This feature is required for HS handshakes.) # The handshake in detail ## Notation We use the following notation: * `|` -- concatenation * `"..."` -- a byte string, with no terminating NUL. * `ENCAP(s)` -- an encapsulation function. We define this as `htonll(len(s)) | s`. (Note that `len(ENCAP(s)) = len(s) + 8`). * `PARTITION(s, n1, n2, n3, ...)` -- a function that partitions a bytestring `s` into chunks of length `n1`, `n2`, `n3`, and so on. Extra data is put into a final chunk. If `s` is not long enough, the function fails. We require the following crypto operations: * `KDF(s,t)` -- a tweakable key derivation function, returning a keystream of arbitrary length. * `H(s,t)` -- a tweakable hash function of output length `DIGEST_LEN`. * `MAC(k, msg, t)` -- a tweakable message-authentication-code function, of output length `MAC_LEN`. * `EXP(pk,sk)` -- our Diffie Hellman group operation, taking a public key of length `PUB_KEY_LEN`. * `KEYGEN()` -- our Diffie-Hellman keypair generation algorithm, returning a (secret-key,public-key) pair. * `ENC(k, m)` -- a stream cipher with key of length `ENC_KEY_LEN`. `DEC(k, m)` is its inverse. Parameters: * `PROTOID` -- a short protocol identifier * `t_*` -- a set of "tweak" strings, used to derive distinct hashes from a single hash function. * `ID_LEN` -- the length of an identity key that uniquely identifies a relay. Given our cryptographic operations and a set of tweak strings, we define: ``` H_foo(s) = H(s, t_foo) MAC_foo(k, msg) = MAC(k, msg, t_foo) KDF_foo(s) = KDF(s, t_foo) ``` See Appendix A.1 below for a set of instantiations for these operations and constants. ## Client operation, phase 1 The client knows: B, ID -- the onion key and ID of the relay it wants to use. CM -- the message that it wants to send as part of its handshake. VER -- a verification string. First, the client generates a single-use keypair: x,X = KEYGEN() and computes: Bx = EXP(B,x) secret_input_phase1 = Bx | ID | X | B | PROTOID | ENCAP(VER) phase1_keys = KDF_msgkdf(secret_input_phase1) (ENC_K1, MAC_K1) = PARTITION(phase1_keys, ENC_KEY_LEN, MAC_KEY_LEN) encrypted_msg = ENC(ENC_K1, CM) msg_mac = MAC_msgmac(MAC_K1, ID | B | X | encrypted_msg) and sends: NODEID ID [ID_LEN bytes] KEYID B [PUB_KEY_LEN bytes] CLIENT_PK X [PUB_KEY_LEN bytes] MSG encrypted_msg [len(CM) bytes] MAC msg_mac [last MAC_LEN bytes of message] The client remembers x, X, B, ID, Bx, and msg_mac. ## Server operation The relay checks whether NODEID is as expected, and looks up the (b,B) keypair corresponding to KEYID. If the keypair is missing or the NODEID is wrong, the handshake fails. Now the relay uses `X=CLIENT_PK` to compute: Xb = EXP(X,b) secret_input_phase1 = Xb | ID | X | B | PROTOID | ENCAP(VER) phase1_keys = KDF_msgkdf(secret_input_phase1) (ENC_K1, MAC_K1) = PARTITION(phase1_keys, ENC_KEY_LEN, MAC_KEY_LEN) expected_mac = MAC_msgmac(MAC_K1, ID | B | X | MSG) If `expected_mac` is not `MAC`, the handshake fails. Otherwise the relay computes `CM` as: CM = DEC(MSG, ENC_K1) The relay then checks whether `CM` is well-formed, and in response composes `SM`, the reply that it wants to send as part of the handshake. It then generates a new ephemeral keypair: y,Y = KEYGEN() and computes the rest of the handshake: Xy = EXP(X,y) secret_input = Xy | Xb | ID | B | X | Y | PROTOID | ENCAP(VER) ntor_key_seed = H_key_seed(secret_input) verify = H_verify(secret_input) RAW_KEYSTREAM = KDF_final(ntor_key_seed) (ENC_KEY, KEYSTREAM) = PARTITION(RAW_KEYSTREAM, ENC_KEY_LKEN, ...) encrypted_msg = ENC(ENC_KEY, SM) auth_input = verify | ID | B | Y | X | MAC | ENCAP(encrypted_msg) | PROTOID | "Server" AUTH = H_auth(auth_input) The relay then sends: Y Y [PUB_KEY_LEN bytes] AUTH AUTH [DIGEST_LEN bytes] MSG encrypted_msg [len(SM) bytes, up to end of the message] The relay uses KEYSTREAM to generate the shared secrets for the newly created circuit. ## Client operation, phase 2 The client computes: Yx = EXP(Y, x) secret_input = Yx | Bx | ID | B | X | Y | PROTOID | ENCAP(VER) ntor_key_seed = H_key_seed(secret_input) verify = H_verify(secret_input) auth_input = verify | ID | B | Y | X | MAC | ENCAP(MSG) | PROTOID | "Server" AUTH_expected = H_auth(auth_input) If AUTH_expected is equal to AUTH, then the handshake has succeeded. The client can then calculate: RAW_KEYSTREAM = KDF_final(ntor_key_seed) (ENC_KEY, KEYSTREAM) = PARTITION(RAW_KEYSTREAM, ENC_KEY_LKEN, ...) SM = DEC(ENC_KEY, MSG) SM is the message from the relay, and the client uses KEYSTREAM to generate the shared secrets for the newly created circuit. # Security notes Whenever comparing bytestrings, implementations SHOULD use constant-time comparison function to avoid side-channel attacks. To avoid small-subgroup attacks against the Diffie-Hellman function, implementations SHOULD either: * Make sure that all incoming group members are in fact in the DH group. * Validate all outputs from the EXP function to make sure that they are not degenerate. # Notes on usage We don't specify what should actually be done with the resulting keystreams; that depends on the usage for which this handshake is employed. Typically, they'll be divided up into a series of tags and symmetric keys. The keystreams generated here are (conceptually) unlimited. In practice, the usage will determine the amount of key material actually needed: that's the amount that clients and relays will actually generate. The PROTOID parameter should be changed not only if the cryptographic operations change here, but also if the usage changes at all, or if the meaning of any parameters changes. (For example, if the encoding of CM and SM changed, or if ID were a different length or represented a different type of key, then we should start using a new PROTOID.) # A.1 Instantiation Here are a set of functions based on SHA3, SHAKE128, Curve25519, and AES256: ``` H(s, t) = SHA3_256(ENCAP(t) | s) MAC(k, msg, t) = SHA3_256(ENCAP(t) | ENCAP(k) | s) KDF(s, t) = SHAKE_128(ENCAP(t) | s) ENC(k, m) = AES_256_CTR(k, m) EXP(pk,sk), KEYGEN: defined as in curve25519 DIGEST_LEN = MAC_LEN = ENC_KEY_LEN = PUB_KEY_LEN = 32 ID_LEN = 32 (representing an ed25519 identity key) ``` Notes on selected operations: SHA3 can be pretty slow, and AES256 is likely overkill. I'm choosing them anyway because they are what we use in hs-ntor, and in my preliminary experiments they don't account for even 1% of the time spent on this handshake. ``` t_msgkdf = PROTOID | ":kdf_phase1" t_msgmac = PROTOID | ":msg_mac" t_key_seed = PROTOID | ":key_seed" t_verify = PROTOID | ":verify" t_final = PROTOID | ":kdf_final" t_auth = PROTOID | ":auth_final" ``` # A.2 Encoding for use with Tor circuit extension Here we give a concrete instantiation of ntor-v3 for use with circuit extension in Tor, and the parameters in A.1 above. If in use, this is a new CREATE2 type. Clients should not use it unless the relay advertises support by including an appropriate version of the `Relay=X` subprotocol in its protocols list. When the encoding and methods of this section, along with the instantiations from the previous section, are in use, we specify: PROTOID = "ntor3-curve25519-sha3_256-1" The key material is extracted as follows, unless modified by the handshake (see below). See tor-spec.txt for more info on the specific values: Df Digest authentication, forwards [20 bytes] Db Digest authentication, backwards [20 bytes] Kf Encryption key, forwards [16 bytes] Kb Encryption key, backwards [16 bytes] KH Onion service nonce [20 bytes] We use the following meta-encoding for the contents of client and server messages. [Any number of times]: TYPE [one byte] LEN [one byte] BODY [LEN bytes] We do not specify specific TYPE semantics here; we leave those for other proposals. All parties MUST reject messages that are not well-formed per the rules above. To avoid partitioning, clients MUST reject messages with TYPEs that they do not recognize. (Therefore, whenever we specify a new server message TYPE, we must say that it can only be included if the client signals that it understands it.) # A.3 How much space is available? We start with a 498-byte payload in each relay cell. The header of the EXTEND2 cell, including link specifiers and other headers, comes to 89 bytes. The client handshake requires 128 bytes (excluding CM). That leaves 281 bytes, "which should be plenty". # X.1 Negotiating proposal-324 circuit windows (We should move this section into prop324 when this proposal is finished.) We define a type value, CIRCWINDOW_INC. We define a triplet of consensus parameters: `circwindow_inc_min`, `cincwindow_inc_max`, and `circwindow_inc_dflt`. These all have range (1,65535). When the authority operators want to experiment with different values for `circwindow_inc_dflt`, they set `circwindow_inc_min` and `circwindow_inc_max` to the range in which they want to experiment, making sure that the existing `circwindow_inc_dflt` is within that range. vWhen a client sees that a relay supports the ntor3 handshake type (subprotocol `Relay=X`), and also supports the flow control algorithms of proposal 324 (subprotocol `FlowCtrl=X`), then the client sends a message, with type `CIRCWINDOW_INC`, containing a two-byte integer equal to `circwindow_inc_dflt`. The relay rejects the message if the value given is outside of the [`circwindow_inc_min`, `circwindow_inc_max`] range. Otherwise, it accepts it, and replies with the same message that the client sent.

4 7

Next public Arti meeting happening on September 8th at 1500 UTC
by Gaba 26 Aug '21

26 Aug '21

Hi! We are canceling the meeting on September 1st. Our next meeting will be on September 8th (and then every 2 weeks). Meeting's room: https://tor.meet.coop/gab-sis-ldw-xad Meeting notes in: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/art… Recording of previous meetings: https://www.youtube.com/playlist?list=PLwyU2dZ3LJErozq7cTtImuWkSn_34pEpq Agenda - status of Arti development and planning - user stories for Arti API https://pad.riseup.net/p/MUjnic0eRT0WrDW7M-us cheers gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Arti report 4: August 4 through August 18
by Nick Mathewson 18 Aug '21

18 Aug '21

# Arti Report 3: August 4 through August 18 At last we're done with circuit timeout inference! See the last weeks update for an overview of what this was, and why it was hard. As of last Friday, we've finally got an Arti implementation that builds testing circuits as appropriate, infers reasonable timeouts, and remembers those timeouts across runs. As a side-benefit to this work, we've found a number of points where we need to clarify the Tor specification to be more precise about correct behavior for a Tor client. (For example, how to break ties when deciding on the most populous histogram bins.) I'm taking some time to circle back and fix those in the Tor specs. Here is the first recorded persistent state from an Arti implementation, lightly reformatted: version = 1 histogram = [[415, 1], [495, 2], [515, 1], [535, 1], [545, 1], [555, 1], [625, 1], [655, 1], [665, 1], [785, 1], [835, 1], [865, 2], [885, 3], [955, 1], [965, 1], [975, 2], [985, 1], [1005, 2], [1025, 1], [1035, 2], [1055, 3], [1065, 1], [1075, 1], [1085, 2], [1095, 1], [1115, 2], [1135, 2], [1145, 2], [1175, 1], [1185, 1], [1195, 2], [1205, 3], [1215, 1], [1235, 2], [1245, 6], [1255, 1], [1265, 2], [1285, 2], [1295, 3], [1305, 1], [1315, 1], [1355, 2], [1375, 2], [1385, 2], [1405, 2], [1435, 1], [1455, 1], [1465, 1], [1495, 1], [1505, 1], [1525, 1], [1535, 1], [1555, 1], [1565, 1], [1605, 1], [1625, 1], [1665, 1], [1765, 1], [1785, 1], [1825, 1], [1965, 1], [2165, 1], [2495, 1], [3025, 1], [3855, 1], [4265, 1], [4795, 1], [4935, 1], [5435, 1], [6825, 1]] current_timeout = 1592 abandoned_circs = 0 successful_circs = 20 ## Other work We've continued to review and merge volunteer patches. Thanks, everybody! In response to a patch documenting a number of possible panics, I've taken a pass through the code to reduce the number of functions that could panic. I've also been spending some time improving test coverage: while doing so, I found an incorrect behavior when checking whether two IPv6 addresses were on the same network. (Tests are great and need to be everywhere, apparently.) ## Coming up Our current priorities are: * Starting API design work. So far we've been feeling our way forward, and it's time to get more systematic. * Improving our APIs and internal functionality for stream isolation, to support a variety of usecases more like what can be done with current Tor. * Kicking off the work on a Guard implementation. This is the last key feature we need for a basic level of privacy. * Lots more interviewing job candidates. Let's see how far we get in the next two weeks!

1 0

txtorcon 21.1.0
by meejah 16 Aug '21

16 Aug '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm pleased to announce txtorcon 21.1.0. This fixes some incorrectly-skipped tests in 21.0.0 * Fix some incorrect unit-test skipping logic (thanks Jean-Paul Calderone) https://github.com/meejah/txtorcon/issues/354 and https://github.com/meejah/txtorcon/issues/352 * Fix broken tests revealed by previous fixes (thanks Jean-Paul Calderone) https://github.com/meejah/txtorcon/issues/356 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/21.1.0 https://github.com/meejah/txtorcon/releases/tag/v21.1.0 Releases are also available from the hidden service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… 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 aebf0b9ec6c69a029f6b61fd534e785692e28fdcd2fd003ce3cc132b9393b7d6 dist/txtorcon-21.1.0.tar.gz bcc54299e5119d6a9ace889bbefc1ff93108a204824b738e9c77bdb71f61661f dist/txtorcon-21.1.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmEa1UoRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaad3/gf/S0mneFfvY0CdqR3DyIOgjX29lIotkDzf 1SeTnLdSU2SYXj89d8TnCUONkQiFZvruGcQufASA+mbIFKC+2KwZ7BVJLlYJ9MGu Cyjt+1jr2xXGmAEVqLcDwCZM7v4BknD/W2jxZqLx3CjDuU3U1abjcJUBlt2Pq/uA B5wWK6PAxIE1rksGtk+ftMf+jMIRwTb5hNj9HynDuGzW3MFbmanyQh2eBfQPlrve 1FqmQUEaOKMM6S34mvExRIjB5/q1SNs8+zX9oAR5wrLh3NVCsiVyXtVOvU949sLy HKVm9nHzgemRrj/nsKetLahM5MYpRYFMhZVYTK+nyotK+I5tRfrXGQ== =e+mc -----END PGP SIGNATURE-----

1 0

This week's arti meeting rescheduled: 18 August, 1600 UTC
by Nick Mathewson 16 Aug '21

16 Aug '21

Hi! Because of a scheduling conflict, our biweekly Arti meeting is rescheduled (for this Wednesday only). The time this week will be at 18 August, 1600 UTC, at https://tor.meet.coop/gab-sis-ldw-xad . This week we'll be brainstorming API ideas, use cases, and user stories. Don't worry if you can't make it: we record our meetings and put them online on Tor's youtube channel. (And this won't be your last chance to influence the API; it's just an initial brainstorming session.) cheers, -- Nick

1 0