Re: [tor-bugs] #20572 [Core Tor/Tor]: hs: Remove the private key material from hs_descriptor.h

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20572: hs: Remove the private key material from hs_descriptor.h
------------------------------------------------+--------------------------
 Reporter:  dgoulet                             |          Owner:  jryans
     Type:  defect                              |         Status:
                                                |  merge_ready
 Priority:  High                                |      Milestone:  Tor:
                                                |  0.3.0.x-final
Component:  Core Tor/Tor                        |        Version:
 Severity:  Normal                              |     Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201612  |  Actual Points:
Parent ID:                                      |         Points:  0.5
 Reviewer:  dgoulet                             |        Sponsor:
                                                |  SponsorR-must
------------------------------------------------+--------------------------
Changes (by dgoulet):

 * status:  needs_information => merge_ready


Comment:

 Replying to [comment:12 jryans]:
 > Okay, I am happy to take a look at this as well!  I have a few
 questions:
 >
 > 1. Since `curve25519` is part of `hs_desc_intro_point_t` and the
 descriptor can have a variable number of intro points, should
 `hs_desc_encode_descriptor()` be passed a list of keypairs, one for each
 intro point?  (Would it be better to create the higher level structure for
 key material here instead of waiting for #20657?)
 >
 > 2. It seems like the legacy path (using `crypto_pk_t *legacy;`) also
 contains a private key.  Should that also be cleaned up as well?

 Ok indeed, that is another problem. I've just spoke with jryans on IRC and
 basically we'll delay this change for the IPs in the service
 implementation (#20657). HSDir do not care about that section as it's
 encrypted. I've opened #21008 about this.

 >
 > As a meta-question, I think I would normally add a separate regular
 commit to the branch (not a fixup) for this additional work, since it
 feels like an independent task and less like correcting an error noticed
 during review.  Is that okay?  (Still trying to get a feel for the desired
 Tor patch workflow, sorry for the mechanical questions.)

 Yes that's perfectly fine!

 I've reviewed and autosquash jryans branch in with minor addition to the
 commit message: `bug20572_030_01`

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20572#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs