Re: [tor-bugs] #15157 [Core Tor/Tor]: Spec issues with consensus' new 'package' field

[Tor Bug Tracker & Wiki]

#15157: Spec issues with consensus' new 'package' field
--+
 Reporter:  atagar|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted
 * points:   => .1
 * severity:   => Normal
 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #15157 [Core Tor/Tor]: Spec issues with consensus' new 'package' field

[Tor Bug Tracker & Wiki]

#15157: Spec issues with consensus' new 'package' field
--+
 Reporter:  atagar|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 I've cleaned up the incorrectness wrt the specification of DIGESTVAL and
 DIGESTTYPE in 5b7a7d6264f24c

 It's not a mistake that DIGEST is mandatory; it is indeed required.

 The future-proofing can be handled by adding new k=v entries that don't
 have to be digests.

 A digesttype needs to be unique -- it is something like "sha1" or
 "sha256".  We can't have more than one of each type for a given object.

 I've also sent an email to tor-dev asking if we intend to use these at
 all.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs