From owner-freebsd-current Sun Feb 20 18: 6:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 758BE37BBD1 for ; Sun, 20 Feb 2000 18:06:34 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA19350; Sun, 20 Feb 2000 18:06:17 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: naddy@mips.rhein-neckar.de (Christian Weisgerber) Cc: freebsd-current@FreeBSD.ORG Subject: Re: openssl in -current In-reply-to: Your message of "21 Feb 2000 00:36:49 +0100." <88ptqh$264i$1@bigeye.rhein-neckar.de> Date: Sun, 20 Feb 2000 18:06:17 -0800 Message-ID: <19347.951098777@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 0. RSA situation > [ a very nice point-for-point analysis of the situation elided ] Christian, Thank you for this summary; it helps a lot to have all the relevant information presented in one place like this. Now we can begin cutting to the heart of this matter, which I'll do in the form of excerps from your own message with my own commentary attached. > - USA, non-commercial: must use RSAREF > - USA, commercial: no RSA > - international: free RSA And how to "get the appropriate RSA" (assuming you're not a U.S. commercial interest) in a what would be a sufficiently user-friendly fashion (that being something FreeBSD's known for) has sort of been point #1 in this little debate. Simply swapping one openssl library for another is, I think we can all agree, the wrong approach if openssl is to have any justification for being bundled with the system. If we're going to go with that level of packaging granularity then openssl belongs as a package and should not be part of the bindist, end of story (the RE draws his line in the sand there :-). That still leaves us with the option of contining to bundle openssl but making rsaref the switchable component so that this is all layered correctly. Looking at the needs of openssl, I see that the following list constitutes the important external references from the RSA glue code: RSAPrivateDecrypt RSAPrivateEncrypt RSAPublicDecrypt RSAPublicEncrypt R_GetRandomBytesNeeded R_RandomFinal R_RandomInit R_RandomUpdate It would obviously not be hard to write a set of stubs for these things, getting those stubs called selectively in the "no real RSA" case also not being very difficult. One way would be to put them in a lower version-numbered shared lib, like OpenBSD did it, so that the application would fall through to link against the stub version if librsaref.so.2 was not found. Another, better way, would be to use weak symbols and a dlopen(), e.g.: #pragma weak RSAPrivateEncrypt=_RSAPrivateEncrypt_stub .. _RSAPrivateEncrypt_stub(...) { if (lib = dlopen("librsaref.so", RTLD_LAZY)) if (sym = dlsym(lib, "RSAPrivateEncrypt")) return (*sym)(...); /* We've fallen through, emit the "go get RSA" message */ } That way it's not an error to link against the openssl library without librsa, though if you do link with -lrsa and -lssl then you can also skip the stubs entirely and not encur the dlopen() overhead, something which makes the -static (or stand-alone) linkers happy. I'm just annoyed enough by this that I may go and implement option #2 right now myself. I wrote up a little test version of this and it worked great, so how hard can 8 little symbols be? :-) Whether openssl is bundled or not, it seems a reasonable thing to try and do. > If we want to have OpenSSL in the base system, we necessarily will > need to use an approach similar to the OpenBSD one. > > I would like to point out that OpenBSD has made it a major advocacy > point that they ship with OpenSSL and OpenSSH out of the box, nicely And now we come to the second major point of this discussion: Just what the hell is openssl good for? In the OpenBSD case, this is a clear and easy question to answer: It's good right now for running openssh under OpenBSD and, as a heck of a lot of people use openssh, that's a clearly justifiable decision. In FreeBSD's case, however, the conservative approach has landed us in "no man's land", where openssl can neither be wholly justified or dismissed, and I think that's a fundamental issue which needs to be addressed. I've seen Kris's arguments about how integrating openssl is a useful first step, but that's not actually as strong an arguing position as it sounds. Just stepping back a bit, in fact, one can easily see a whole pile of incremental things which one could do to FreeBSD as good "first steps" towards some greater good but, in and of themselves, are kinda worthless in the short term. These are projects which you want to by all means encourage but not actually bring into FreeBSD until they've reached a minimal standard of functionality and usefulness to the population at large. To do otherwise quickly leads to a system which can be best characterized as a pile of dangling hacks-in-progress, driven more by engineering than user interests. I'm not totally inflexible about making the engineering vs user argument either, don't get me wrong, but this one is perilously in the middle and bringing something like openssh in as a companion to openssl would certainly raise my estimation of openssl as a 4.0 candidate. Yes, I'd even be willing to delay the release date for something like that. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message