On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote: > Tricky thing here, because then you'd need to rename the libs. E.g. > libssl to liblibressl or something. > But then every program with a build environment to link to libssl would > first have to be patched to link to our specialized libressl variant.
Yah, I dunno. But I don't have a warm fuzzy about them being interchangable any time soon or even longterm. It's not a goal AFAIK. > Is there a way to split libtls off libressl? Because that might be at > least for this case an option: Continue to use openssl, but have libtls > laying around. Not sure if it is possible to have libtls using > libcrypt/libssl functions from openssl. I'm pretty sure libtls won't currently compile against openssl, although I haven't taken a detailed look as to why. It is true that openntpd has no direct dependency on libressl, only the libtls API, so theoretically if libressl's libtls could be patched to work with openssl or if openssl released their own API compatible libtls it would be happy. I asked a similar question on the pkgsrc mailing list: http://mail-index.netbsd.org/tech-pkg/2015/03/30/msg014532.html They're pretty much decided on allowing both openssl and libressl to be installed concurrently and for a given application to use one or the other. The specific method for that packaging system is what they call a prefix; basically instead of /usr/pkg/lib/libssl it would be /usr/pkg/libressl/lib/libssl, and packages that needed it would get the right magic flags for the headers and libraries to be found. All openntpd does is use libtls to make an HTTPS HEAD request. It might be simpler to just have it use libcurl or some other existing https library instead of trying to get libressl/libtls working, although that would decrease the "security" aspect of it only using openbsd audited code.
