security/tor package currently does not depend on openssl from ports but uses openssl provided by base. openssl in base comes without enable-ec_nistp_64_gcc_128 support, tor will show the following line in the logs (if tor has been installed via 'pkg install tor') [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Installing openssl from packages/ports + recompiling tor solves this. What do you think about making tor depend on the openssl package (not the one in base) and ship the tor package which is linked against the openssl package to solve this also in the package out of the box? I saw it was actually you (the security/tor maintainer) who enabled enable-ec_nistp_64_gcc_128 in the first place: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175663 (Is there a particular reason why this feature is off in base by default?) thanks!
Maintainer reset.
New maintainer, request feedback.
It is still the case that tor builds with the base OpenSSL when the port isn't present. USES=ssl has this logic of choosing which OpenSSL to use based on file presence. I would rather have this dependency explicit. tor should probably have special option USE_PORT_OPENSSL. There is also a somewhat related torproject ticket asking to support various other OpenSSL interface implementations: https://trac.torproject.org/projects/tor/ticket/13977
ping!
nusenu, The variable DEFAULT_VERSIONS in /etc/make controls which ssl version is used globally. As far as I understand, you need to rebuild all ports once you change this selection, since it is a global option. See here: https://wiki.freebsd.org/DEFAULT_VERSIONS#SSL_Library_Selection Please raise this on ports@ mailing list if this is a concern. Please close this bug if this answers your concern. Regards, Yuri