Hello all,
Is there an existing Tor proposal you'd like to discuss? Please use the following pad to nominate and vote for proposals for discussion.
https://pad.riseup.net/p/Pxo2fQiiaSWo
We'll be reviving our proposal discussion meetings soon, likely at the beginning of January once people have returned from their winter holidays.
After the nominations/votes are taken, I'll start arranging meeting times. If you nominate and/or vote for a proposal, I may reach out to you at some point for your opinions on discussion items, open questions/concerns, etc. to include for the meeting preparation.
Thanks!
Best regards,
isis agora lovecruft transcribed 2.9K bytes:
Hello all,
Is there an existing Tor proposal you'd like to discuss? Please use the following pad to nominate and vote for proposals for discussion.
https://pad.riseup.net/p/Pxo2fQiiaSWo
We'll be reviving our proposal discussion meetings soon, likely at the beginning of January once people have returned from their winter holidays.
After the nominations/votes are taken, I'll start arranging meeting times. If you nominate and/or vote for a proposal, I may reach out to you at some point for your opinions on discussion items, open questions/concerns, etc. to include for the meeting preparation.
Thanks!
Hello!
Last chance (for this round) to get your nominations/votes in! This week I will be creating subthreads (of this thread) for each proposal meeting, which will have doodles/polls for dates and times.
Unless someone requests otherwise, I'm not going to group proposals into batches for meetings: hopefully this way the meetings will be shorter and people only have to pay attention to the things they are interested in.
Best regards,
Hello,
Let's schedule a proposal discussion for prop#239 "Consensus Hash Chaining" [0] sometime next week (between 7 - 9 Feb). If you're CCed, it's because you put your name down on the pad as being interested in this discussion. If anyone has requests or concerns, or if I forgot to take your timezone into account, please let me know.
https://doodle.com/poll/iahmzu95hpvxciex
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-...
This is happening in #tor-meeting on Thursday, 8 February, 21:00-22:00 UTC. In various local times:
* Thursday, 8 February, 13:00-14:00 PST * Thursday, 8 February, 16:00-17:00 EST * Thursday, 8 February, 22:00-23:00 CET * Friday, 9 February, 08:00-09:00 AEST
isis agora lovecruft transcribed 2.2K bytes:
Hello,
Let's schedule a proposal discussion for prop#239 "Consensus Hash Chaining" [0] sometime next week (between 7 - 9 Feb). If you're CCed, it's because you put your name down on the pad as being interested in this discussion. If anyone has requests or concerns, or if I forgot to take your timezone into account, please let me know.
Best regards,
Hi!
The notes from this meeting are online. [0] Thanks to everyone who attended!
We've decided to have the prop#267 [1] meeting next, then (potentially, depending on the takeaway from the prop#267 meeting) revise prop#239 [2] according to these notes. Finally, we'll (potentially) have a third meeting to compare and contrast the two proposals, and choose one to go with.
[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-08-20.59.html [1]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-t... [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-...
Best regards,
isis agora lovecruft isis@torproject.org wrote Fri, 9 Feb 2018 00:08:19 +0000:
Hi!
The notes from this meeting are online. [0] Thanks to everyone who attended!
We've decided to have the prop#267 [1] meeting next, then (potentially, depending on the takeaway from the prop#267 meeting) revise prop#239 [2] according to these notes. Finally, we'll (potentially) have a third meeting to compare and contrast the two proposals, and choose one to go with.
[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-08-20.59.html...]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-t...]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-...
Thanks for arranging this meeting and apologies for not showing up as planned.
For convenience, here are the highlighted items from the meeting. They didn't make it to the meeting minutes page. (Seems like #info, #action and #idea are what meetbot cares about.)
--8<---------------cut here---------------start------------->8--- <nickm> #item proposal should clarify how many older consensuses to hold <teor> #item why not just keep the hash(es) of each consensus <nickm> #item maybe use sha3-256 instead. <nickm> #item maybe store only the hash and the signatures. Have the chaining <tjr> #item Instead of keeping full documents, can we keep a chain of diffs? <teor> #item expand "some categories of attacks" to explain what the attacks <tjr> #item Provide an export of a suspicious consensus that would prove <tjr> #item It would be good to look at prop267 again in relation to this --8<---------------cut here---------------end--------------->8---
Hello,
Let's schedule a proposal discussion for prop#285 "Directory documents should be standardized as UTF-8" [0] sometime between 12 - 13 Feb. If you're CCed, it's because you put your name down on the pad as being interested in this discussion. If anyone has requests or concerns, or if I forgot to take your timezone into account, please let me know.
https://doodle.com/poll/cnc6scybbfpky5f8
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt
Best regards,
Reminder to please vote for a time for this if you'd still like to attend!
isis agora lovecruft transcribed 2.2K bytes:
Hello,
Let's schedule a proposal discussion for prop#285 "Directory documents should be standardized as UTF-8" [0] sometime between 12 - 13 Feb. If you're CCed, it's because you put your name down on the pad as being interested in this discussion. If anyone has requests or concerns, or if I forgot to take your timezone into account, please let me know.
Best regards,
This one is in #tor-meeting, next Monday, 12 February from 21:00-22:00 UTC. In local times:
* Monday, 12 February 13:00-14:00 PST * Monday, 12 February 16:00-17:00 EST * Monday, 12 February 22:00-23:00 CET * Tuesday, 13 February 08:00-09:00 AEST
isis agora lovecruft transcribed 2.3K bytes:
Reminder to please vote for a time for this if you'd still like to attend!
isis agora lovecruft transcribed 2.2K bytes:
Hello,
Let's schedule a proposal discussion for prop#285 "Directory documents should be standardized as UTF-8" [0] sometime between 12 - 13 Feb. If you're CCed, it's because you put your name down on the pad as being interested in this discussion. If anyone has requests or concerns, or if I forgot to take your timezone into account, please let me know.
Hi!
The notes from this meeting are online. [0] Thanks to everyone who attended! Extra thanks to teor for conducting the meeting since I was stupidly 8 minutes late due to impatiently watching a kettle boil after eating very spicy cioppino and then *extremely* needing a glass of iced tea immediately.
We found some issues w.r.t. the specifics of the proposal, but overall we've agreed that it should be accepted in (roughly, after some minor revision) in its current state. As such, it is looking for someone interested in implementing it! (THIS COULD BE YOU)
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 are allowed in Rust): - NUL (0x00) - Byte Order Mark (0xFEFF)
2. Directory document keywords MUST be printable ASCII.
3. This change may break some descriptor/consensus/document parsers. If you are the maintainer of a parser, you may want to start thinking about this now.
[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-12-21.04.html
Best regards,
On 13 Feb 2018, at 10:55, isis agora lovecruft isis@torproject.org wrote:
A couple outcomes of this:
- 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 are allowed in Rust): - NUL (0x00) - Byte Order Mark (0xFEFF)
I want to clarify this point:
The Byte Order Mark is Unicode Scalar 0xFEFF, encoded in UTF-8 as the bytes 0xEF 0xBB 0xBF.
Tor's C and Rust implementations of UTF-8 must be identical.
When we write the C implementation, we must reject NUL for compatibility with C string functions.
When we write the Rust implementation, we must reject NUL for compatibility with the C implementation. (Rust already implements UTF-8 strings that accept NUL, so this will require custom code).
When we write the C and Rust implementations, we must reject BOM because it's unnecessary. Rejecting BOM is recommended by the relevant standard. (Rust already implements UTF-8 strings that accept BOM, so this will require custom code).
T
Hi,
On 12/02/18 23:55, isis agora lovecruft wrote:
- 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 are allowed in Rust): - NUL (0x00) - Byte Order Mark (0xFEFF)
Much of the metrics software is written in Java. Java strings allow for NUL to appear, but assume that there is no BOM. If a BOM appears, then this would be interpreted as data and, I assume, parsing would probably fail. Should the whole document be rejected if it contains a NUL or BOM, or should these values be stripped and then carry on parsing as if it never happened?
- Directory document keywords MUST be printable ASCII.
This can be validated. Should a single document keyword containing printable non-ASCII be enough to reject the document, or should a parser try to recover?
I'd really like to see a section in the proposal about how parsers should react when they find something unexpected, otherwise all the parsers may end up doing different things.
- This change may break some descriptor/consensus/document parsers. If you are the maintainer of a parser, you may want to start thinking about this now.
For the metrics tools there are some guidelines on this we can follow: https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other language would be Python (for stem), but Python developers have probably got a good understanding of unicode/str/bytes by now. (In Python 3: when using UTF-8, BOM will not be stripped and will be interpreted as data, and you can have a NUL in a str).
Thanks, Iain.
On 13 Feb 2018, at 21:55, Iain Learmonth irl@torproject.org wrote:
Hi,
On 12/02/18 23:55, isis agora lovecruft wrote:
- 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 are allowed in Rust): - NUL (0x00) - Byte Order Mark (0xFEFF)
Much of the metrics software is written in Java. Java strings allow for NUL to appear, but assume that there is no BOM. If a BOM appears, then this would be interpreted as data and, I assume, parsing would probably fail. Should the whole document be rejected if it contains a NUL or BOM, or should these values be stripped and then carry on parsing as if it never happened?
Directory authorities and bridge clients already reject descriptors that contain NUL. (This is an artefact of the C implementation: the descriptor is seen as truncated, so it won't parse.)
We should specify rejection for BOM as well.
- Directory document keywords MUST be printable ASCII.
This can be validated. Should a single document keyword containing printable non-ASCII be enough to reject the document, or should a parser try to recover?
If parsers want to be consistent with the Tor implementation, they should reject.
I'd really like to see a section in the proposal about how parsers should react when they find something unexpected, otherwise all the parsers may end up doing different things.
+1
- This change may break some descriptor/consensus/document parsers. If you are the maintainer of a parser, you may want to start thinking about this now.
For the metrics tools there are some guidelines on this we can follow: https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other language would be Python (for stem), but Python developers have probably got a good understanding of unicode/str/bytes by now. (In Python 3: when using UTF-8, BOM will not be stripped and will be interpreted as data, and you can have a NUL in a str).
Python for txtorcon Rust for Tor's experimental protover implementation
And perhaps others: https://stem.torproject.org/faq.html#are-there-any-other-controller-librarie... https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations
T
For the metrics tools there are some guidelines on this we can follow: https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other language would be Python (for stem), but Python developers have probably got a good understanding of unicode/str/bytes by now. (In Python 3: when using UTF-8, BOM will not be stripped and will be interpreted as data, and you can have a NUL in a str).
Hi Iain. Actually, for Stem I'm really looking forward to this too. Stem has special handling for the contact and platform fields (iirc the only spot non-ascii content can presently appear). Stem's parsers and API will be simplified once everything is uniformly utf-8. :P
Possibly a stupid question but any reason not to require the whole descriptor document to be printable characters?
On 14 Feb 2018, at 11:03, Damian Johnson atagar@torproject.org wrote:
For the metrics tools there are some guidelines on this we can follow: https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other language would be Python (for stem), but Python developers have probably got a good understanding of unicode/str/bytes by now. (In Python 3: when using UTF-8, BOM will not be stripped and will be interpreted as data, and you can have a NUL in a str).
Hi Iain. Actually, for Stem I'm really looking forward to this too. Stem has special handling for the contact and platform fields (iirc the only spot non-ascii content can presently appear). Stem's parsers and API will be simplified once everything is uniformly utf-8. :P
Possibly a stupid question but any reason not to require the whole descriptor document to be printable characters?
Requiring printable ASCII throughout the document means that people can't spell their names and email addresses correctly in contact lines.
Requiring printable unicode introduces a dependency on a particular unicode version, 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 C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
Hello,
Let's schedule a proposal discussion for prop#267 "Tor Consensus Transparency" [0] sometime between 14 - 16 Feb. If you're CCed, it's because you put your name down on the pad as being interested in this discussion. If anyone has requests or concerns, or if I forgot to take your timezone into account, please let me know.
https://doodle.com/poll/a6ih5a4dqr9bdsie
Note that this meeting will likely run longer than an hour. I'll try to keep it as short as possible… but in the past this discussion has been long.
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-t...
Best regards,
Hello,
I know I said I wouldn't group meetings in bulk… but there's a few meetings which have the following in common:
* Everyone who said they wished to attend is: me, teor, and nickm.¹ * The discussion should be fairly fast. * We're all (I suspect) already in agreement. * Every topic has to do with removing old/deprecated code.
So. Let's schedule, sometime between 19 - 23 Feb, a proposal discussion for:
* prop#245 "Deprecating and removing the TAP circuit extension protocol" [0] * prop#282 "Remove 'Named' and 'Unnamed' handling from consensus voting" [1]
https://doodle.com/poll/6m9xztyy4ufmeiwy
As always, please let me know if you'd really like to attend but I've not taken your timezone into account.
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/245-tap-out.txt [1]: https://gitweb.torproject.org/torspec.git/tree/proposals/282-remove-named-fr...
¹ Please note that even if your name is not {isis,teor,nickm} that you are warmly welcome to attend and participate.
Best regards,
On Fri, Feb 9, 2018 at 11:14 PM, isis agora lovecruft isis@torproject.org wrote:
Hello,
I know I said I wouldn't group meetings in bulk… but there's a few meetings which have the following in common:
Hi! I'm afraid I don't know my schedule for that week yet, since my kid is off school. Please schedule this one without me: I'll try to make it to the meeting at whatever time everybody else chooses. If I can't, I'll send notes and read notes.
cheers,
Hello,
Meeting notes are available here. [0] Takeaways include:
* Some minor clarifications to prop#245, but it will be put in "Status: Accepted" with a ticket to implement and deploy step#1 (§3). We'll need to actually implement all the other steps too, with parameters to en-/dis- able them, so that we can properly test them before deployment (in ~2020).
* prop#282 is accepted, and can be implemented immediately.
* A new proposal summarising our newly created policy for consensus method deprecation will be written.
Thanks everyone!
[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-20-23.11.html
Best regards,
-
Damian Johnson -
Iain Learmonth -
isis agora lovecruft -
Linus Nordberg -
Nick Mathewson -
teor