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.
Brian Wellington schrieb:
>
> Hi. I'm on the BIND 9 development team, and we're hoping to use OpenSSL
> to perform the cryptography necessary for DNSSEC. The OpenSSL code is
> portable and fast, which is exactly what we're looking for. There are a
> few problems, though, and I'm not sure how much work is required to get
> around them, and whether these changes would be desired for the main
> distribution.
>
> - 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?
> - 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).
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.
> 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...
--
Holger Reif Tel.: +49 361 74707-0
SmartRing GmbH Fax.: +49 361 7470720
Europaplatz 5 [EMAIL PROTECTED]
D-99091 Erfurt WWW.SmartRing.de
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
