[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12498 [Tor]: Implement ed25519 identity keys (prop 220)
#12498: Implement ed25519 identity keys (prop 220)
-------------------------+-------------------------------------------------
Reporter: asn | Owner: nickm
Type: task | Status: needs_review
Priority: major | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version: Tor: 0.2.7
Resolution: | Keywords: 026-triaged-1, 027-triaged-1-in,
Actual Points: | SponsorU
Points: large | Parent ID: #15054
-------------------------+-------------------------------------------------
Comment (by nickm):
Replying to [comment:20 andrea]:
> Partial code review!
>
>
> cf9d780b570fa3ebf02e555c45f62d8b1bc38bcf:
>
> - tor_cert_sign_impl() leaks memory (encoded is never freed), but
otherwise
> appears correct
Fixed in 52c4106305d87a9be5e9437c1b529a70b4b82c46
> 1e3a98f88d5e19239d00356d50f6b598a681d70c:
>
> - As a question of sysadminning the dirauths, one probably wants a way
> to keep backups of the keypin journal, and copying it out from under
> a running Tor process might lead to a corrupt copy with partially
> written lines. Should we consider making any provision for backups
> of the keypin journal without stopping the dirauth's Tor process?
I thought about this, and the best solution I could come up with was to
treat unreadable lines as bogus, and to prepend a newline on startup.
Perhaps we should open a ticket to find a better way?
> 41cbaf0f267b0d1831aa3cf42e9d279cb171bc6a:
>
> - We're switching microdescriptors in votes over to containing ed25519
lines
> instead of rsa1024 lines if we have a recent enough consensus method;
are
> we sure instead of rather than in addition to is the right choice
here?
Pretty sure. The RSA1024 lines are redundant with the RSA identities in
the consensus; they are only there now to make sure that two different
descriptors from different routers will always produce different
microdescriptors. (See bug #11743 and commit
4a621a50f53ebeac62d30f427c2db0c627f80a31 for background.)
> 72d0d2c9c44cb6df47b35c07f94898f952a52fbc:
>
> - Are we sure checking generated files into the repository like this is
> the right thing vs. generating them at build time?
No, but I think it will be easier to switch post-facto.
I've gone for the current approach since I want to freeze us to the code
generated by a particular version of Trunnel with a particular version of
Tor by default, and because I don't expect every developer to have to
install trunnel. But see #16199 and #16202 for an alternative.
I think that covers all the questions and suggestions from your review so
far, but please let me know if I missed some?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12498#comment:22>
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