On Thu, 1 Jul 1999, Holger Reif wrote:
> This issue seems to be the same as with Apache and SSL support. The
> conclusion was to leave out all crypto related stuff and require some
> patching. This way is sometimes not completely easy for the average
> user that wants to include other modules as well (which might
> conflicting patches).
>
> You intenetions seems to be different. You want to distribute
> a part of OpenSSL for your purposes.
Yes.
> > - US Export control issues. We only need DSA, SHA1, MD5, and randomness
> > (and possibly RSA when the patent expires). Since BIND must be
> > exportable, it would be nice to be able to strip out the code for unneeded
> > algorithms before running config, so that we can distribute a subset in the
> > BIND distribution.
>
> Isn't there a problem for you with export control even if the
> RSA patent expired?
There shouldn't be. If the software does only authentication and no
encryption, it can usually be self classified. A subset of OpenSSL that
did only DSA, MD5, SHA1, and HMAC cannot be used for encryption.
> > - Other disables. Options such as no-asn1, no-pkcs7, no-pkcs12, no-x509
> > would be useful, as these would significantly shrink the size of libcrypto.a
> > as well as the source. Disabling SSL would be nice also, but isn't as
> > important, since it's not linked into libcrypto.
>
> So you would want to produce a "private"libcrypto.a? (Why don't you
> just build the whole thing?)
>
> I think it could lead to confusion if someone notices that with BIND
> openssl was installed but it doesn'T seem to work with other programs
> (like Apache).
It would probably be linked into one of the BIND libraries rather than
installed as a separate library. since otherwise libcrypto would become a
dependency for any program linked against libdns.
> Instead I would suggest that either you distribute the whole openssl
> package (or refere to it as required since you can't distribute it as
> is beacuse of export control) or you pick out the required algorithms
> and create a separate package that has not openssl in it's name.
> you don't need to step up with every release of OpenSSL since the
> parts you need are very stable and less likely to change.
The plan was to distribute a highly stripped down version of the OpenSSL
tree, with a slightly modified Makefile/Configure to link the object files
into a pre-existing library. If the specific parts of OpenSSL didn't
change, then there'd be no reason to upgrade.
Distributing OpenSSL separately would work, but the BIND developers are
mostly against requiring additional software to be present. If DNSSEC is
ever going to be used, BIND needs to support DSA (the mandatory algorithm)
out of the box, and with no additional packages that must be retrieved.
> > I'd be willing to contribute patches for the disable options (not written
> > yet, but they shouldn't be too hard). As for the config stuff, I could
> > probably do that too, but it might make more sense if someone familiar
> > with the scripts could look at it.
>
> Regarding scripts... I'm note even shure wether it makes sense
> to automate the extraction of the required algorithms...
The documentation says it works. If that's an unnecessary feature, that's
fine, and I can modify the Makefile/Configure for our purposes, but the
docs should reflect that. I think it could be useful, as long as it was
clear that libcrypto with algs removed will not be compatible with other
software.
Thanks,
Brian
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
