Use or remove "package" lines from votes

changed milestone to %Tor: unspecified

added actualpoints::1 component::core tor/tor milestone::Tor: unspecified owner::metrics-team points::1 priority::medium severity::normal status::new tor-spec type::task labels

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 ;).

Trac:
Milestone: N/A to Tor: unspecified
Keywords: N/A deleted, tor-spec added

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.

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

Ok. I can make a proposal.

Trac:
Status: new to accepted
Owner: N/A to irl

Proposal submitted to tor-dev:

https://lists.torproject.org/pipermail/tor-dev/2019-February/013703.html

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?!

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.

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.

Trac:
Cc: N/A to gk

Pull request opened: https://github.com/torproject/torspec/pull/60

Discussion: https://lists.torproject.org/pipermail/tor-dev/2019-February/013703.html

Trac:
Status: accepted to needs_review

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.

We can always extract removed code from the git history.

Trac:
Cc: gk to gk, gaba

Trac:
Reviewer: N/A 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@lists.torproject.org 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?

Trac:
Status: needs_review to needs_information

Trac:
Actualpoints: N/A to 1
Status: needs_information to new
Reviewer: ahf to N/A
Points: N/A to 1

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@lists.torproject.org 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.

Trac:
Type: enhancement to task

Trac:
Status: new to assigned
Owner: irl to metrics-team

Trac:
Status: assigned to new

Use or remove "package" lines from votes

Child items 0

Activity