Proposal: Don't include package fingerprints in consensus documents
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. Thanks, Iain. [0] https://trac.torproject.org/projects/tor/ticket/28465
Hi,
On 22 Feb 2019, at 07:59, Iain Learmonth <irl@torproject.org> 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.
[0] https://trac.torproject.org/projects/tor/ticket/28465
<xxx-dont-vote-on-package-fingerprints.txt>
Proposal:
0. Abstract
I propose modifying the Tor consensus document to remove digests of the latest versions of one or more package files, to prevent software using Tor from determining its up-to-dateness, and to hinder users wanting to verify that they are getting the correct software.
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 the end of the proposal.) Can you mention the positive aspects in the Abstract?
2. Proposal
We deprecate the "package" line in the specification for votes.
If the consensus method is at least XX then "package" lines should not appear in consensuses.
Let's be a bit more precise: We allocate a consensus method when this proposal is implemented. Let's call it consensus method N. If the consensus method is between 19 and (N-1), "package" lines MAY appear in consensuses. If the consensus method is less than 19, or at least N, "package" lines MUST NOT appear in consensuses. I'd like to add another part to the proposal: Directory authorities stop voting for "package" lines in their votes. Changes to votes do not require a new consensus method, so this part of the proposal can be implemented separately. Based on: https://trac.torproject.org/projects/tor/ticket/28465#comment:1 https://trac.torproject.org/projects/tor/ticket/28465#comment:3 T
On Thu, Feb 21, 2019 at 9:29 PM teor <teor@riseup.net> wrote:
Hi,
On 22 Feb 2019, at 07:59, Iain Learmonth <irl@torproject.org> 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.
[0] https://trac.torproject.org/projects/tor/ticket/28465
<xxx-dont-vote-on-package-fingerprints.txt>
Proposal:
0. Abstract
I propose modifying the Tor consensus document to remove digests of the latest versions of one or more package files, to prevent software using Tor from determining its up-to-dateness, and to hinder users wanting to verify that they are getting the correct software.
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 the end of the proposal.)
Can you mention the positive aspects in the Abstract?
2. Proposal
We deprecate the "package" line in the specification for votes.
If the consensus method is at least XX then "package" lines should not appear in consensuses.
Let's be a bit more precise:
We allocate a consensus method when this proposal is implemented. Let's call it consensus method N.
If the consensus method is between 19 and (N-1), "package" lines MAY appear in consensuses. If the consensus method is less than 19, or at least N, "package" lines MUST NOT appear in consensuses.
I'd suggest a slightly different phrasing above: There is no "MAY" in the contents of a consensus, to the extent that the contents of the consensus are supposed to be deterministic given its inputs. Instead I'd go with a phrasing like, "Authorities will continue computing consensus package lines in the consensus if the consensus method is between 19 and (N-1). If the consensus method is N or later, they omit these lines." -- Nick
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 the end of the proposal.)
Can you mention the positive aspects in the Abstract?
Rewritten this.
Instead I'd go with a phrasing like, "Authorities will continue computing consensus package lines in the consensus if the consensus method is between 19 and (N-1). If the consensus method is N or later, they omit these lines."
This sounds good too. Updated draft is attached. Thanks, Iain.
On 23 Feb 2019, at 02:10, Iain Learmonth <irl@torproject.org> 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 the end of the proposal.)
Can you mention the positive aspects in the Abstract?
Rewritten this.
Instead I'd go with a phrasing like, "Authorities will continue computing consensus package lines in the consensus if the consensus method is between 19 and (N-1). If the consensus method is N or later, they omit these lines."
This sounds good too.
Updated draft is attached.
Thanks! Looks good to me, let's merge it as an "accepted" proposal? T
On 27 Feb 2019, at 02:30, Iain Learmonth <irl@torproject.org> 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 commit it?
You can open a trac ticket and link to a GitHub pull request. T
Hi,
On 25/02/2019 23:30, teor wrote:
Looks good to me, let's merge it as an "accepted" proposal?
This is now proposal 301. What is the process by which this becomes "accepted"? Is this just a matter of someone making that commit? Thanks, Iain.
On 14 Mar 2019, at 03:50, Iain Learmonth <irl@torproject.org> wrote:
Signed PGP part Hi,
On 25/02/2019 23:30, teor wrote:
Looks good to me, let's merge it as an "accepted" proposal?
This is now proposal 301.
What is the process by which this becomes "accepted"? Is this just a matter of someone making that commit?
Here's what "Accepted" means: Accepted: The proposal is complete, and we intend to implement it. After this point, substantive changes to the proposal should be avoided, and regarded as a sign of the process having failed somewhere. https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt#n15... I can't imagine us making any substantive changes to the proposal. The reasons and actions are clear, and there are clearly-defined sub-tickets for each of the tasks. We have successfully implemented similar tasks before. Unless anyone objects in the next week, let's make this change: https://trac.torproject.org/projects/tor/ticket/29776 T
participants (3)
-
Iain Learmonth -
Nick Mathewson -
teor