Opened 7 years ago

Closed 7 years ago

#9774 closed defect (fixed)

Explain "#ifdef CURVE25519_ENABLED" better

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


I find the CURVE25519_ENABLED ifdefs really confusing. It would seem to mean "can we do ntor handshakes", but if it does, why is there a bunch of ntor code not covered by ifdefs? When should I check ifdef when doing something ntor-related, and when shouldn't I? Are there things that aren't ntor-related where it matters?

I was about to send Nick mail asking, but then I realized that other / future Tor developers should want to know the answer too.


Child Tickets

Change History (3)

comment:1 Changed 7 years ago by arma

Keywords: tor-relay added

(Giving it a subcomponent keyword since Nick wants all Tor tickets to have one)

comment:2 in reply to:  1 Changed 7 years ago by nickm

CURVE25519_ENABLED doesn't mean "Can we do ntor handshakes" -- it literally means "Is curve25519 enabled; did we compile with curve25519 support?" It is a matter of fact that we build the code for the ntor handshake iff we have curve25519 enabled, but that's another matter.

I'm not sure what non-#ifdef'd code in specific you're talking about. The ntor code that isn't covered by #ifdefs is supposed to be related to moving ntor keys around, storing them, and so forth. The onion_ntor.c file itself is conditionally compiled -- see src/or/

Replying to arma:

(Giving it a subcomponent keyword since Nick wants all Tor tickets to have one)

I thought you were the one who wanted subcomponents?

comment:3 Changed 7 years ago by nickm

Resolution: fixed
Status: newclosed

Explained in a comment in fdf68479b077c2b53fcdffd54e307f1258c81a4b. If you'd like that explanation to appear somewhere else, please reopen and write a patch. :)

Note: See TracTickets for help on using tickets.