Opened 11 months ago

Last modified 3 months ago

#28465 new task

Use or remove "package" lines from votes

Reported by: irl Owned by: metrics-team
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-spec
Cc: gk, gaba Actual Points: 1
Parent ID: Points: 1
Reviewer: Sponsor:

Description

Currently dir-spec permits "package" lines in votes that can be used to vote on what the digest and location for a particular version of a software package is. This is not present in any votes I've seen.

We should either use this, or remove it from the spec (and any code that supports it in tor).

Roughly around here: https://spec.torproject.org/dir-spec#n1722

Child Tickets

TicketStatusOwnerSummaryComponent
#29737closedirlAssign package proposal a number, change its filename, and merge it to torspecCore Tor/Tor
#29738closedirlDeprecate RecommendedPackages torrc option, and remove the code for voting for packagesCore Tor/Tor
#29739newCreate a new consensus method that does not include package linesCore Tor/Tor
#29776closedteorMark proposal 301 as "Accepted", and update the indexCore Tor/Tor

Change History (18)

comment:1 Changed 11 months ago by dgoulet

Keywords: tor-spec added
Milestone: Tor: unspecified

It is not used because no directory authority defines RecommendedPackages but it doesn't mean we can't use it in the future.

We can deprecate it for sure if we do not use it. It would be a simple code removal and render the option OBSOLETE(). I believe that as long as we make sure no dirauth adds a RecommendedPackages then we can avoid a consensus method about "not voting for this anymore" ... Might not be the proper way to do things though ;).

comment:2 Changed 11 months ago by irl

For some context as to why I'm filing this, I'm looking at modernising our network archive (CollecTor). Either we should be archiving these packages, so that if they are referenced we will always have things that were referenced, or we should agree that we'll never use this feature and I don't need to write code for it.

comment:3 in reply to:  1 Changed 11 months ago by teor

Replying to dgoulet:

It is not used because no directory authority defines RecommendedPackages but it doesn't mean we can't use it in the future.

We can deprecate it for sure if we do not use it. It would be a simple code removal and render the option OBSOLETE(). I believe that as long as we make sure no dirauth adds a RecommendedPackages then we can avoid a consensus method about "not voting for this anymore" ... Might not be the proper way to do things though ;).

We can stop voting for the packages lines immediately.

Removing package lines from the consensus requires a proposal and a new consensus method.
It can be a very short proposal:
https://gitweb.torproject.org/torspec.git/tree/proposals/282-remove-named-from-consensus.txt

comment:4 Changed 11 months ago by irl

Owner: set to irl
Status: newaccepted

Ok. I can make a proposal.

comment:6 Changed 8 months ago by cypherpunks

wouldn't it make more sense to start using this feature instead of removing it?

the proposal says:

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.

why would you want to hinder users wanting to verify that they are getting the correct software?!

comment:7 in reply to:  6 Changed 8 months ago by irl

Replying to cypherpunks:

wouldn't it make more sense to start using this feature instead of removing it?

why would you want to hinder users wanting to verify that they are getting the correct software?!

These are excellent questions!

I have rewritten the abstract in my latest update to make the reasoning clearer, but both abstracts are true and correct.

There have been many years now to start using this feature and it's just not happened. Perhaps writing this proposal threatening its removal will bring someone out that has had a plan all along and not yet implemented it. Perhaps the problems it was intended to solve are already solved in other ways and this is some housekeeping that got forgotten.

comment:8 Changed 8 months ago by mikeperry

Cc: gk added

Make sure GeKo and the tbb-team see this proposal. Proposal 227 was created to eliminate single points of failure/coercion points in the Tor Browser build+update system.

comment:10 Changed 8 months ago by gk

I still like the updater hardening idea but I can see how the parts that got implemented create overhead, especially if they have been unused for such a long time. Additionally, we won't have time to work on this this year anymore, I think, and given our likely (funding) prios for the next two years I doubt implementing the missing things will be done by then. Especially, as we still need to iron out the application part of prop 227 (so, it's not just a matter of coding something).

So, all in all and even though it pains me to say this: I think it's not unreasonable to remove those unused parts for now. If we want to get to that kind of hardening at some point we should take a fresh look at proposals that came up meanwhile (cosigning/CHAINIAC etc.) and make sure we get all the relevant bits implemented while working under Sponsor $foo.

comment:11 Changed 8 months ago by teor

We can always extract removed code from the git history.

comment:12 Changed 8 months ago by gaba

Cc: gaba added

comment:13 Changed 7 months ago by asn

Reviewer: ahf

comment:14 Changed 7 months ago by ahf

Status: needs_reviewneeds_information

I'm not totally sure what it is I need to review here. The spec proposals needs to be reviewed on tor-dev@… which irl have already opened up for. From what I can see the proposal itself looks fine and I don't see any objections to it?

The next step would be to land the proposal in torspec.git and get someone to implement the code parts of it?

comment:15 Changed 7 months ago by teor

Actual Points: 1
Points: 1
Reviewer: ahf
Status: needs_informationnew

comment:16 in reply to:  14 Changed 7 months ago by teor

Type: enhancementtask

Replying to ahf:

I'm not totally sure what it is I need to review here. The spec proposals needs to be reviewed on tor-dev@… which irl have already opened up for. From what I can see the proposal itself looks fine and I don't see any objections to it?

Yes. I re-read te pull request to make sure.

The next step would be to land the proposal in torspec.git and get someone to implement the code parts of it?

I split these changes up into 3 child tickets, because they can all be done at different times.

comment:17 Changed 3 months ago by irl

Owner: changed from irl to metrics-team
Status: newassigned

comment:18 Changed 3 months ago by irl

Status: assignednew
Note: See TracTickets for help on using tickets.