[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8014 [Tor]: Reject the reference-implementation of curve25519 from donna in a more comprehensible way.

#8014: Reject the reference-implementation of curve25519 from donna in a more
comprehensible way.
-----------------------+----------------------------------------------------
    Reporter:  mr-4    |       Owner:                    
        Type:  defect  |      Status:  reopened          
    Priority:  normal  |   Milestone:  Tor: 0.2.4.x-final
   Component:  Tor     |     Version:  Tor: 0.2.4.8-alpha
  Resolution:          |    Keywords:  tor-relay         
      Parent:          |      Points:                    
Actualpoints:          |  
-----------------------+----------------------------------------------------

Comment(by mr-4):

 Replying to [comment:3 nickm]:
 > If you want to cross-compile nacl, the recommended solution is to use
 scratchbox.  (Says DJB.)
 Erm,. I don't really know what "scratchbox" is - I use mock (chrooted
 environment with all the necessary packages for the target arch
 installed), so don't know whether that would work (probably not).

 Here is an idea - my guess is that the Nacl build system creates some sort
 of "profile" on the target CPU, among oher things.

 If that is the case, why won't the Nacl devs provide a tool (executable),
 which is executed on the target system, builds and stores a profile (in a
 file, for example), which is then taken and used for the Nacl build on the
 (more powerful/different-arch) build machine?

 I do a similar thing here with autoconf when I do builds using pre-defined
 "guess" files. Could a similar technique, if used, eliminate the need for
 probing the build machine and poke my cpu characteristics (and probably
 build a wrong profile)? Just an idea, but the way I see it, poking the
 build machine and relying on the answers received isn't going to work.

 I know for a fact that Fedora is also using mock as a tool to build their
 vast array of packages, so they are bound to have similar problems when it
 comes to this library.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8014#comment:4>
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