Date: Fri, 15 May 2015 17:28:03 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 200223] security/tor: ship tor package linked against openssl from ports (faster ECDH support) Message-ID: <bug-200223-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200223 Bug ID: 200223 Summary: security/tor: ship tor package linked against openssl from ports (faster ECDH support) Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: bf@FreeBSD.org Reporter: nusenu@openmailbox.org Flags: maintainer-feedback?(bf@FreeBSD.org) Assignee: bf@FreeBSD.org 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! -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200223-13>