Date: Sun, 20 Feb 2000 18:06:17 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: naddy@mips.rhein-neckar.de (Christian Weisgerber) Cc: freebsd-current@FreeBSD.ORG Subject: Re: openssl in -current Message-ID: <19347.951098777@zippy.cdrom.com> In-Reply-To: Your message of "21 Feb 2000 00:36:49 %2B0100." <88ptqh$264i$1@bigeye.rhein-neckar.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19347.951098777>