Re: [tor-dev] Updating Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count)

failures. > > An older version of this document is available here: > https://gitweb.torproject.org/torspec.git/tree/proposals/299-ip-failure-count.txt > > I have attached an updated copy of this proposal to this message. This > includes the changes recommended by teor at > https://lists.t

[tor-dev] March Network Team Meeting Schedule

UTC We'll have a similar schedule in April, except for the company holiday on April 22. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor

[tor-dev] Speeding up your Tor Appveyor Builds

the previous build, and start a build with the latest changes." That's it. Your builds will be a bit faster! T -- teor -- signature.asc Description: Message signed with OpenPGP

Re: [tor-dev] Proposal: Don't include package fingerprints in consensus documents

> On 27 Feb 2019, at 02:30, Iain Learmonth wrote: > > On 25/02/2019 23:30, teor wrote: >> Looks good to me, let's merge it as an "accepted" proposal? > > Is there some action I should take here like opening a PR or does > someone just pick up the text and comm

Re: [tor-dev] Proposal: Don't include package fingerprints in consensus documents

> On 23 Feb 2019, at 02:10, Iain Learmonth wrote: > > Signed PGP part > Hi all, > > On 22/02/2019 12:29, Nick Mathewson wrote: >>> I had to read this paragraph twice to understand it. >>> The way it's written, it sounds like we're doing a bad thing. >>> (Until I read the "security" section at

Re: [tor-dev] Proposal: Don't include package fingerprints in consensus documents

Hi, > On 22 Feb 2019, at 07:59, Iain Learmonth wrote: > > Signed PGP part > Hi All, > > #28465 [0] needed a proposal. Feedback is welcome and encouraged. I've > not written a proposal before, so if someone could let me know if I'm > following the process OK (or not) then that is useful too. >

Re: [tor-dev] Testing Network: Circuit buildup errors and missing guards

Hi, > On 14 Feb 2019, at 23:50, Katharina Kohls wrote: > >> >> We recently changed the bootstrap percentages and messages in Tor. >> Please paste the log lines that containing these bootstrap messages. >> And any error messages near those lines. > Feb 14 10:37:46.000 [notice] Bootstrapped 10%:

Re: [tor-dev] Proposal Idea: Consensus Options

> On 21 Feb 2019, at 00:29, Nick Mathewson wrote: > > On Mon, Feb 11, 2019 at 7:00 AM teor wrote: >> >> Hi all, >> >> I have a Tor proposal idea: we should make it easier for tor to get options >> from the consensus. >> >> At the m

Re: [tor-dev] Marking Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count) as Accepted

Hi Neel, > On 17 Feb 2019, at 08:10, n...@neelc.org wrote: > > My proposal "Preferring IPv4 or IPv6 based on IP Version Failure Count" > (a.k.a. Prop299) is here: > https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt That's a link to the proposals process document. The

Re: [tor-dev] Testing Network: Circuit buildup errors and missing guards

>> On 14 Feb 2019, at 02:57, Katharina Kohls wrote: >> >>> All nodes bootstrap properly and reach 100%, the authorities both manage to >>> vote and exchange information. Also the relays and the client bootstrap to >>> 100%. >> >> When are these messages logged? > Sorry, I must update this:

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

(until these versions are unsupported) * 1 passthrough distinguisher * 1-3 walking onions stage 0/1/2 distinguisher(s) T -- teor -- ___ tor-dev mailing list tor-dev@list

Re: [tor-dev] Testing Network: Circuit buildup errors and missing guards

Hi, > On 12 Feb 2019, at 21:22, Katharina Kohls wrote: > > All nodes bootstrap properly and reach 100%, the authorities both manage to > vote and exchange information. Also the relays and the client bootstrap to > 100%. When are these messages logged? > Nevertheless, the consensus seems to

Re: [tor-dev] Proposal 299: Preferring IPv4 or IPv6 based on IP Version Failure Count

e this. Also, >thank you teor for aiding me on my first proposal. > >My proposal is available on torspec here: >https://gitweb.torproject.org/torspec.git/tree/proposals/299-ip-failure-count.txt > >Now that my proposal "Preferring IPv4 or IPv6 based on IP Version >Failure Cou

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

require a valid set of authority signatures. We could encourage implementers to check the signature first by putting it first in the document, or adding a signature offset field to the header. Or we could document this issue in a security considerations secti

Re: [tor-dev] The Tor project as a GSoC voucher for Whonix?

Dear Whonix Community, On February 5, 2019 2:20:18 PM UTC, iry wrote: > > >teor: >> Dear Whonix Community, >> >> On February 4, 2019 11:52:44 PM UTC, iry wrote: >> Dear Tor Developers, >> >> Whonix is applying to be a Google Summer of Code organ

Re: [tor-dev] tor relay process health data for operators (controlport)

ats are bad for users. And have rules about retention periods. But these rules won't be as critical as they are now, because the rules will only be needed for edge cases. (Like a single client that uses moat of a relay, which we can't hide very well, no matter what we do.) Adding noise will be easier o

Re: [tor-dev] New Proposal: Preferring IPv4 or IPv6 based on IP Version Failure Count

NS to discover relay addresses. If we did re-implement rfc6724 in Tor, it wouldn't make much difference. Most relays are IPv4-only, so there is no address choice. For dual-stack relays, it would choose between one IPv4 and on

Re: [tor-dev] New Proposal: Preferring IPv4 or IPv6 based on IP Version Failure Count

d work for the week, and we have an in-person meeting next week. So it might take us a few weeks to review your proposal. We do a lot of our reviews on GitHub pull requests. Proposals usually go in https://github.com/torproject/torspec/tree/m

Re: [tor-dev] Modifying Path Selection based on geography

Hi, > On 19 Jan 2019, at 21:21, sarpedon montecarlo wrote: > > the event handlers i register, streams and circuits events, freeze and stops > working. this is not happening from the beginning but when some streams show > up, it seems like some stack somewhere that i am not aware of, stock at

Re: [tor-dev] Modifying Path Selection based on geography

Hi, > On 17 Jan 2019, at 23:39, sarpedon montecarlo wrote: > > I recently started to do some modifications on tor path selection by using > stem, torflow/op-addon and txtorconn. but as long as i enable > __LeaveStreamsUnattached option, tor will not function properly.

Re: [tor-dev] Reviewer for Bug #27491: Prefer IPv4 or IPv6 based on the number of failures

Hi Neel, > On 17 Jan 2019, at 09:14, Neel Chauhan wrote: > > I noticed the assigned reviewer for my bug/patch #27491 > (https://trac.torproject.org/projects/tor/ticket/27491), mikeperry, has not > yet reviewed my bug since he was assigned to my bug/patch back in December. I > understand that

[tor-dev] Upcoming Network Team Meetings

is just after FOSDEM, we'll get back to you with a date. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https

Re: [tor-dev] in buffers_net.c

Hi, Thanks for this bug report and patch. > On 3 Jan 2019, at 13:27, Gisle Vanem wrote: > > Some recent change has added a: > #include > > which fails for MSVC (it doesn't have it). > > Since I fail to find any way to comment on Trac or Gitweb, > I give notice here. Patching into: > > ---

Re: [tor-dev] Daemon

Hi, It looks like you're trying to run some attacks on Tor. Please don't run attacks on the live Tor network: use a test network instead. > On 3 Jan 2019, at 02:56, marziyeh latifi wrote: > > I have some question about daemon: > 1-what is the Tor daemon? A service that runs all the time:

Re: [tor-dev] Regarding projects and a begineer guide.

Hi, Here's the torsocks README: https://gitweb.torproject.org/torsocks.git/tree/README.md You could start by building and installing torsocks: https://gitweb.torproject.org/torsocks.git/tree/INSTALL T -- teor -- > On 16

Re: [tor-dev] Regarding projects and a begineer guide.

Hi, > On 7 Dec 2018, at 02:28, Durgesh Kumar wrote: > > Dear sir/mam > I am durgesh kumar from ABES engineering college,ghaziabad,uttar > pradesh,india. > > I am currently in 2nd year of my graduation(Btech CSE ) > > I want to contribute in some of your prestigious project. So i request you

[tor-dev] Network team meeting Monday at 1800 UTC

Hi all, The next network team meeting is on Monday 10 December at 1800 UTC. Our meetings are held on #tor-meeting on OFTC. We'll also be meeting on Monday at 1800 UTC on 17 December. The Tor office is closed for the holidays from 24 December to 1 January. Many of us will take leave during that

Re: [tor-dev] Throughput of each circuit

Hi, > On 5 Dec 2018, at 16:15, marziyeh latifi wrote: > > I want to count the number of cells that are sent from circuit queue to the > output buffer in each relay. How can I do this? > Any opinion? You already asked this question in tor-relays:

Re: [tor-dev] Merging Tor Bug #27490

Hi, Thanks for your patience. > On 29 Nov 2018, at 10:23, Neel Chauhan wrote: > > I noticed that while you all have accepted bug #27490 (When > ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a > directory or orport connection, prefer IPv4 or IPv6 at random), it has

[tor-dev] Network team meeting Tuesday at 2300 UTC

Hi all, The next network team meeting is on Tuesday 4 December at 2300 UTC. (If this time doesn't work for you, we'll see you the week after.) Our meetings are held on #tor-meeting on OFTC. We'll be meeting on Monday at 1800 UTC for 10 December and 17 December. The Tor office is closed for

Re: [tor-dev] Dealing with frequent suspends on Android

> On 27 Nov 2018, at 07:46, Nick Mathewson wrote: > > On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers > wrote: >> >> On 20/11/2018 19:28, Nick Mathewson wrote: >>> Hi! I don't know if this will be useful or not, but I'm wondering if >>> you've seen this ticket: >>>

[tor-dev] New sbws milestones on trac

to the bandwidth measurement system. No Due Date We can change the due dates depending on how much progress we make. T -- teor -- signature.asc Description: Message signed with OpenPGP

Re: [tor-dev] PrivCount and Prio IRC Meeting

Hi All, The notes for the PrivCount and Prio meeting are at: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-11-20-22.05.html T -- teor -- signature.asc Description: Message signed with OpenPGP

[tor-dev] PrivCount and Prio IRC Meeting

/wiki/org/meetings/2018MexicoCity/Notes/PrivCountTechnical https://github.com/nmathewson/privcount_shamir T -- teor -- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.

Re: [tor-dev] Bandwidth scanner: request for feedback

:11, Mike Perry wrote: > > teor: >> >> What happens when sbws doesn't match torflow? >> >> https://trac.torproject.org/projects/tor/ticket/27339 >> >> We suggest this rule: >> >> If an sbws deployment is within X% of an existing bandwid

Re: [tor-dev] Dealing with frequent suspends on Android

> On 7 Nov 2018, at 04:10, Michael Rogers wrote: > > On 06/11/2018 01:58, Roger Dingledine wrote: >> On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote: >>>> so if we could ask the guard for >>>> regular keepalives, we might be able to promise that the

Re: [tor-dev] Dealing with frequent suspends on Android

> On 6 Nov 2018, at 03:38, Michael Rogers wrote: > > One of the difficulties with this option is that under some conditions, > the controller can only schedule one alarm every 15 minutes. Traffic > from the guard would also wake the CPU, so if we could ask the guard for > regular keepalives, we

Re: [tor-dev] Network team meeting on Tuesday at 2300 UTC

Hi, I got the daylight saving change for next week mixed up. > On 5 Nov 2018, at 10:24, teor wrote: > > This week's network team meeting is on Tuesday at 2300 UTC. > (If this time doesn't work for you, we'll see you the week after.) > > Our meetings are held on #tor-meeti

[tor-dev] Network team meeting on Tuesday at 2300 UTC

. First meeting each month: Tuesday at 2300 UTC. Other meetings each month: Mondays at 1700 UTC. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-dev

Re: [tor-dev] Characterizing Tor flows using DPI

Hi, > On 12 Oct 2018, at 21:40, Piyush Kumar Sharma wrote: > > I have some confusion regarding the characterization of Tor traffic using DPI. > I was following the link > (https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/TLSHistory ) > and understood that Tor did TLS

Re: [tor-dev] Proposal 297: Relaxing the protover-based shutdown rules

Hi, This proposal seems good to me. > On 20 Sep 2018, at 02:20, Nick Mathewson wrote: > > I propose that when deciding whether to shut down because of > subprotocol requirements, a Tor implementation should only shut > down if the consensus is dated to some time after the >

[tor-dev] Tor master exits with a required protocol error

/projects/tor/ticket/27288 T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B -- signature.asc Description: Message signed with OpenPGP

[tor-dev] Network Team Meeting: Tuesday 1700 UTC

Hi, It's a public holiday in the US on Monday. So we moved the network team meeting from Monday to Tuesday 1700 UTC for this week. Sorry for the late notice! T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B

Re: [tor-dev] Archiving old Components in Trac

Thanks everyone, these components have been archived: Applications/Tor Messenger Applications/Tor Mail And this one deleted: Core Tor/Erebus T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B

Re: [tor-dev] Archiving old Components in Trac

> On 29 Aug 2018, at 11:49, Mirimir wrote: > > On 08/28/2018 05:10 PM, teor wrote: >> Hi, >> >> Is anyone still using these trac components? >> >> Applications/Tor Messenger >> Applications/Tor Mail >> Applications/TorBirdy > > Huh? &g

[tor-dev] Archiving old Components in Trac

Hi, Is anyone still using these trac components? Applications/Tor Messenger Applications/Tor Mail Applications/TorBirdy Core Tor/Erebus Obfuscation/FTE If no-one is using them, we can move them to Archived/ T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90

Re: [tor-dev] Tor Volunteer

rics team is doing, and read their responses over the next few days: > On Mon, Aug 27, 2018 at 2:51 AM teor wrote: > > Here is the metrics website: > https://metrics.torproject.org/ > > And here is the list of all the projects in tor: > https://www.torproject.org/getinvolv

[tor-dev] Bandwidth scanner: request for feedback

/tor/ticket/27336 Torflow uses 5%, but I suggest 1%, because the largest relay right now is only 0.5%. T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B

Re: [tor-dev] Tor Volunteer

rope right now, so they probably won’t be at work for another 8–12 hours. If you don’t hear back from them by Wednesday, please email: metrics-t...@lists.torproject.org T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 4

Re: [tor-dev] Relay diversity master thesis

site Web a rencontré une erreur inattendue. Veuillez essayer de nouveau plus tard. Which is a glorious mix of French and English that even I can understand. Any idea when it will be fixed? T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C

Re: [tor-dev] Reviewing Trac #18642 (Teach the OOM handler about the DNS cache)

> On 2 Aug 2018, at 01:41, n...@neelc.org wrote: > > Hi tor-dev@ mailing list, > > I have a patch for Bug #18642 (Teach the OOM handler about the DNS cache) > which I would like reviewed. > > The URL is here: https://trac.torproject.org/projects/tor/ticket/18642 > > Originally, dgoulet chose

Re: [tor-dev] WTF-PAD and the future

work with VPADDING cells: https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n508 At least it did last time I checked: https://github.com/teor2345/endosome/blob/master/client-or-22929.py https://trac.torproject.org/projects/tor/ticket/22929 We should avoid using PADDING cells during the h

Re: [tor-dev] restoring 'cypherpunks' trac account with more anti-automation?

> On 23 Jul 2018, at 17:12, nusenu wrote: > >>> is there any timeline when the cypherpunks trac account will be restored? > > does the tor project plan to restore it or work on this problem? It might help to ask: Is there anyone who wants to work on this issue? Hiro is the services admin,

Re: [tor-dev] restoring 'cypherpunks' trac account with more anti-automation?

> On 21 Jul 2018, at 03:17, nusenu wrote: > > is there any timeline when the cypherpunks trac account will be restored? > > I would suggest to require _every_ single submission (and maybe even the > login itself) > by that account to go through the captcha test (not just in case there are to

Re: [tor-dev] Proposal 295: Using the ATL construction for relay cryptography (solving the crypto-tagging attack)

ed by the previous node, which > they process as per Section 3.2.2. If the previous node also supports > the new protocol, these cells are indeed the nonce. If the previous > node only supports the old protocol, these bytes are either encrypted > NUL bytes or encrypted data. “encr

Re: [tor-dev] Brief state of sbws thoughts

Hi, > On 20 Jul 2018, at 01:16, juga wrote: > > Matt Traudt: >> Teor, Juga >> >> There's a lot of things fighting for my attention right now, so you >> might have noticed I've slowed way down on attending to sbws >> tickets/PRs/etc. I think time will

Re: [tor-dev] Proposal: Expose raw bwauth votes

d make the file available >>> at >>> http:///tor/status-vote/next/bwauth.z >> >> If it's "next", how is it possible to expose it at the same time as its vote >> which is based upon it? Maybe we should change the URL to be "current"? >

Re: [tor-dev] Anonymous local count statistics

Hi, > On 10 Jul 2018, at 09:04, Saurav Malani wrote: > > I am 4th year student at IIIT-H, India. I want to contribute to TOR project > specifically to "Anonymous local count statistics". I am done with building > TOR. I looked at the ticket and had an overview of Tor documentation. But, I >

Re: [tor-dev] Tor port restriction option was removed

> On 5 Jul 2018, at 20:06, nusenu wrote: > > Roger Dingledine: >> It looks like around 844 Guard relays are listening on port 443 right now, >> out of the 1858 available Guard relays. > > guard probability for all guards having ORPort on 80 or 443: > 45.99% > > guard probability per ORPort:

Re: [tor-dev] the consequences of deprecating debian alpha repos with every new major branch

>> On 3 Jul 2018, at 16:54, Peter Palfrader wrote: >> >>> On Tue, 03 Jul 2018, Peter Palfrader wrote: >>> On Sun, 01 Jul 2018, Iain Learmonth wrote: >>> >>> Hi, >>> On 30/06/18 15:42, nusenu wrote: but maybe someone else would be willing to invoke a "ln" commands

Re: [tor-dev] the consequences of deprecating debian alpha repos with every new major branch

> On 2 Jul 2018, at 00:57, Iain Learmonth wrote: > > Signed PGP part > Hi, > > On 30/06/18 15:42, nusenu wrote: >> 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 But then

Re: [tor-dev] documenting reload vs. restart requirements per torrc option

> On 3 Jul 2018, at 05:52, nusenu wrote: > > Hi, > > I like unbound's documentation with this regards, for example they say > in their man page: > >> The interfaces are not changed on a reload (kill -HUP) >> but only on restart. > > Could we add such information to every torrc

Re: [tor-dev] man: "IPv6 addresses should be wrapped in square brackets"

> On 1 Jul 2018, at 07:22, nusenu wrote: > > Hi, > > tor's man page for OutboundBindAddress* options say: > >> IPv6 addresses should be wrapped in square brackets > > since it does not throw an error without square brackets: > does it make any difference? When an option only takes an IP

Re: [tor-dev] Dealing with DNS requests by Tor unaware programs

> On 25 Jun 2018, at 02:41, procmem wrote: > > Hello. We are trying to safely deal with programs that don't support Tor > DNS stream isolation so they don't pollute TransPort. We don't recommend TransPort for this reason. (See below.) > I've read the manual but it's not clear if you enable >

Re: [tor-dev] DNS resolution isolation in Tor Browser

> On 15 Jun 2018, at 09:16, nusenu wrote: > > > Thanks for the replies. > > > Does tor simply assume (try) that the exit policy allows the destination > address (not the port) or does it check the exit policy before selecting > the circuit? > (in that case it would have to know the

Re: [tor-dev] DNS resolution isolation in Tor Browser

> On 15 Jun 2018, at 02:22, nusenu wrote: > > Hi, > > I haven't been able to answer this question by looking into the Tor Browser > design document, > maybe you have an answer: > > imagine you have two tabs in Tor Browser: > > 1: torproject.org (circuit A) > embeds some youtube.com content

Re: [tor-dev] DNS-over-HTTPS (DOH) in Firefox/Torbrowser

Hi, > On 20 May 2018, at 02:39, nusenu wrote: > > since Mozilla did tests [0] on DOH [1] in Firefox I was wondering > if Torbrowser developers have put any thought into that as well? > > Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because > the

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

On 2 May 2018, at 22:39, teor <teor2...@gmail.com> wrote: >> > Tor accepts zero bandwidths, but they trigger bugs in older Tor >> > implementations. Therefore, implementations SHOULD NOT produce zero >> > bandwidths. Instead, they SHOULD u

Re: [tor-dev] connectivity failure for top 100 relays

On 3 May 2018, at 06:41, nusenu wrote: >> What are the guidelines to avoid getting blocked by the tor network? > > stay under the public thresholds? > https://www.torproject.org/docs/tor-manual-dev.html.en#_denial_of_service_mitigation_options Those are the defaults.

Re: [tor-dev] HS v3 client authorization types

> On 3 May 2018, at 02:09, George Kadianakis wrote: > > I think my approach here would be to try to support both auth types by > the time we launch this feature (under the "standard" auth type), and > then in the future as we get more insight on how people use them, we >

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

y is more important than > consistency, and if so, we won't want to take all of my recommendations here. > > > Tor Bandwidth Measurements Document Format > > juga > > teor > > > > 1. Scope and pr

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

On 2 May 2018, at 19:18, Iain Learmonth wrote: >> "Measurements Results" describes how the bandwidths are created by >> some generators. But a generator that believes self-reported results >> doesn't measure, it just aggregates. (As does a peerflow-style generator.) >> >

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

On 2 May 2018, at 18:34, juga wrote: 2. Format details Bandwidth measurements MUST contain the following > sections: - Header (exactly once) - Relays measurements (zero or more times) >>> >>> Grammar suggestion: "Relay measurements". >> >> In this

Re: [tor-dev] onion v2 deprecation plan?

> On 30 Apr 2018, at 23:55, David Goulet <dgou...@torproject.org> wrote: > >> On 28 Apr (09:34:09), teor wrote: >> >> On 28 Apr 2018, at 04:48, Damian Johnson <ata...@torproject.org> wrote: >> >>>> OnionBalance requires STEM support for V

Re: [tor-dev] Closing old Trac Milestones

Hi, Just following up on the old trac milestones. > On 23 Apr 2018, at 14:31, teor <teor2...@gmail.com> wrote: > > Hi, > > Tor's trac has a lot of milestones. > Sometimes users select the wrong one, because there are so many. pde, do you mind if we close these HTT

Re: [tor-dev] onion v2 deprecation plan?

Hi nusenu, I've just finished catching up with this thread, ticket changes, and the IRC discussion overnight. > On 28 Apr 2018, at 09:30, teor <teor2...@gmail.com> wrote: > > On 28 Apr 2018, at 05:56, nusenu <nusenu-li...@riseup.net> wrote: > >>> A

Re: [tor-dev] onion v2 deprecation plan?

On 28 Apr 2018, at 04:48, Damian Johnson wrote: >> OnionBalance requires STEM support for V3 > > Hi Alec, would you mind clarifying what you need from Stem? As far as > I'm aware Stem supports v3 onion service creation... > >

Re: [tor-dev] HS v3 client authorization types

Hi, > On 28 Apr 2018, at 06:59, meejah wrote: > > After reading the spec diff and your mail, I'm still not sure I > understand the distinction -- if the x25519 is used to decrypt the > descriptor then: > >> The spec says that the client must have both keys and use both to >>

Re: [tor-dev] Proposal #291 Properties (was IRC meeting)

> On 25 Apr 2018, at 18:30, Mike Perry wrote: > > 1. Hidden service use can't push you over to an unused guard (at all). > 2. Hidden service use can't influence your choice of guard (at all). > 3. Exits and websites can't push you over to an unused guard (at all) >

Re: [tor-dev] minor website update request: have the tor-relay guide ready for Ubuntu 18.04

Hi Hiro, > On 26 Apr 2018, at 18:31, nusenu wrote: > > For that I submitted an update on trac [1] a few days ago. > From my personal experience, my website update requests (also trivial ones) > take about two months to get committed, it would be great if we could speed

Re: [tor-dev] Standardizing the 'onion service' name

Hi All, There seems to be some confusion in this thread about the current state of the hidden service to onion service name transition. So I'm going to describe the state of things as they are, then try to describe what would need to be done. I'd also appreciate feedback from Steph and others

[tor-dev] Closing old Trac Milestones

on this list belong to you, and you'll never put any more tickets in them, please close them. (Or let me know, and I can close them.) Tickets in closed milestones will still appear in searches. We can always re-open a milestone if we decide we want to put more tickets in it. T -- teor PGP C855 6CED 5D90

Re: [tor-dev] Tor Bandwidth Measurements Document Format

Hi, Thanks for writing this draft spec. Please see my suggested changes below: > On 17 Apr 2018, at 21:23, juga <j...@riseup.net> wrote: > > Hi, > > as commented with teor and pastly, i send in-line a draft specification > for the document format that the bandwidth

Re: [tor-dev] Hogging of second_elapsed_callback()

> On 15 Apr 2018, at 07:38, Linus Nordberg wrote: > > Hi, > > How long time can we spend signing status documents before tor gets sad? > > I ask because I'm planning on putting dirauth signing keys on a > sloow HSM and would like to understand if I'd have to make >

Re: [tor-dev] Scaling bandwidth scanner results

Hi, Matt, Juga, Nick and I discussed an alternative scaling scheme on #tor-dev during the patch party. > On 19 Mar 2018, at 12:22, Matt Traudt wrote: > > 1. Decide on a large total. > > I suggest 50 million to start the conversation (bike shedding) based on > that being

[tor-dev] Tor: unspecified is the default Core Tor milestone

Hi, The network team maintains Core Tor, the network daemon that runs the tor network. We have planned our roadmap for the next 6 months. We only chose essential and sponsored tasks, because we want to finish on time. We moved all the other tickets out of the 0.3.4 and 0.3.5 milestones. If you

Re: [tor-dev] connectivity failure for top 100 relays

> On 13 Mar 2018, at 03:55, dawuud wrote: > > Out of 9900 possible two hop tor circuits among the top 100 tor relays > only 935 circuit builds have succeeded. This is way worse than the last > time I sent a report 6 months ago during the Montreal tor dev meeting. How much

Re: [tor-dev] 3.2.10 compiler warnings

Thanks for the bug report. > On 10 Mar 2018, at 04:54, grarpamp wrote: > > Test from an older system before it was updated, Can you tell us what compiler and version, and what system? Any arguments to configure? And how did you get the Tor source code? > unlikely to be

Re: [tor-dev] Consensus-health single-relay data

> On 9 Mar 2018, at 20:28, Tom Ritter wrote: > > I have tested it on Tor Browser and High Security Slider, seems to > work for me, but I want feedback on the UX and for bugs Wow! It works! And it even works in iOS Safari. Also, there is a feature? where you can keep pasting

Re: [tor-dev] Proposal Waterfilling

> On 7 Mar 2018, at 18:34, Rob Jansen wrote: > > It is far more expensive to obtain *continuous*, i.e., *sustained* bandwidth > usage over time. Generally, it's cheaper to buy in bulk. In the US, the > cheapest bandwidth service we found (that also allows us to run

Re: [tor-dev] Consensus-health single-relay data

> On 7 Mar 2018, at 18:22, Tom Ritter <t...@ritter.vg> wrote: > > teor suggested the other day that it'd be really useful to be able to > see the vote data for a single relay; since the _entire_ detailed page > is huge and unwieldy. > > I've been pondering how I

Re: [tor-dev] Proposal Waterfilling

twork doesn't attempt to converge on a stable set of weights, because the feedback loop is too weak. So I think we can disregard this question. >> On 28/01/18 23:40, teor wrote: >> >> I'm going to re-ask this questions, in light of the extra middle load from >> Tor2web client

Re: [tor-dev] DocTor Check for <3 bw auth votes available

> On 28 Feb 2018, at 05:47, nusenu wrote: > > Hi Damian, > > would be great to have a check in DocTor that sends out an email > for "there are less than 3 bw auth voting auths available" Let's have two different checks: "There are less than 3 bw auth votes in a

Re: [tor-dev] Proposal 290: Continuously update consensus methods

> On 22 Feb 2018, at 04:02, Nick Mathewson wrote: > > Some consensus methods remove a feature that was used up to method > N. Deprecating method M means that the feature is no longer used by > any supported consensus methods. Therefore, we can remove any code > that

Re: [tor-dev] Enhancement for Tor 0.3.4.x

> On 20 Feb 2018, at 04:14, David Goulet wrote: > > The other part would be IPv6 for HSv3. This includes: > > - Unify link specifier API/ABI (#22781) > - Put IPv6 link specifiers in client EXTEND cells (#24451) > - Put IPv6 and unrecognised link specifiers in onion

Re: [tor-dev] [prop-meeting] [prop#267] "Tor Consensus Transparency"

I'm sorry, I didn't get Isis' original email, I think my spam folder ate it. Can you please re-send? > On 18 Feb 2018, at 07:43, Tom Ritter wrote: > > On 17 February 2018 at 00:31, isis agora lovecruft > wrote: >> 1. Tuesdays @ 18:00 UTC (10:00

Re: [tor-dev] Enhancement for Tor 0.3.4.x

feature or enhancement, please do > submit it on this thread and make sure a proper ticket exists with an Owner. There are a lot of other things I'd like to do in 0.3.4, but I think I should focus on PrivCount

Re: [tor-dev] [prop-meeting] [prop#285] "Directory documents should be standardized as UTF-8"

because we don't know if unallocated blocks will be printable or not. I think we could make platform lines printable ASCII without losing much. Unless there are platforms that have non-ASCII names? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C85

Re: [tor-dev] [prop-meeting] [prop#285] "Directory documents should be standardized as UTF-8"

> On 13 Feb 2018, at 21:55, Iain Learmonth wrote: > > Hi, > >> On 12/02/18 23:55, isis agora lovecruft wrote: >> 1. What passes for "canonicalised" "utf-8" in C will be different to >>what passes for "canonicalised" "utf-8" in Rust. In C, the >>following will not

Re: [tor-dev] [prop-meeting] [prop#285] "Directory documents should be standardized as UTF-8"

> On 13 Feb 2018, at 10:55, isis agora lovecruft wrote: > > A couple outcomes of this: > > 1. What passes for "canonicalised" "utf-8" in C will be different to >what passes for "canonicalised" "utf-8" in Rust. In C, the >following will not be allowed (whereas they

<    1   2   3   4   5   6   7   >