On Jan 19, 2004, at 2:01 AM, David Fort wrote:
The RFC says that the checksum should be used for anything else than
RSA/MD5. RSA/SHA1 is clearly matching that
case. The patch i sent you changes the RSA/SHA1 behaviour to being the
default one for all algorithm(which is what the RFC
specifies), so the compute_key_id always returns a valid key id.
Checked in.
Talking about that i was thinking of giving more informations about
the key(nb of bits, modulus, etc..). But for achieving this i'd like
to use openSSL to decode the cryptographic material. Is openSSL
detected and linked with ethereal ?
You can build with "-lcrypto" by configuring with "--with-ssl". It's
not detected automatically.
If so which symbol is defined when openSSL is present ?
Currently, none - the "--with-ssl" flag is there to handle versions of
UCD SNMP/Net-SNMP that require "-lcrypto" (that *should* be done
automatically, if possible, as is done with "-ldes425" and "-lkstat",
which UCD SNMP/Net-SNMP require on some platforms, rather than
requiring the user to do "--with-ssl" - but I digress); there's no code
in Ethereal itself that uses -lcrypto, so the configure script doesn't
check for its presence and set a HAVE_LIBCRYPTO flag or anything such
as that.
There are also allegedly licensing issues that get in the way of
linking GPLed applications with openSSL:
http://www.openssl.org/support/faq.html#LEGAL2
I don't know how painful it'd be to allow Ethereal to be linked with
openSSL. If it's truly an issue only for "the copyright holder(s)",
then presumably Gerald, and anybody else who explicitly copyrighted
their contribution to Ethereal, would have to give permission. If it's
an issue for everybody who contributed code and didn't *explicitly*
assign copyrights to Gerald (assuming that putting in the default
copyright notice doesn't count as explicitly assigning copyright), then
a large number of people would have to give permission.
On the other hand, if it's just an issue of linking GPLed code with
GPL-incompatible libraries:
http://www.fsf.org/licenses/gpl-faq.html#GPLIncompatibleLibs
then I think that, for example, anybody distributing binaries of
Ethereal statically linked with libpcap on, for example, Solaris or
Windows is technically violating the GPL, unless they build a version
that can't capture packets, as the original BSD license that is the
license for libpcap is GPL-incompatible just as the OpenSSL license is:
http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses
and libpcap is not "normally distributed ... with the major components
... of the operating system on which the executable runs" in Solaris
and Windows (and some other OSes), so it doesn't fall under the special
exception in the GPL for libraries that are so distributed.
The problem with the original BSD license is that it imposes an
additional restriction on redistribution, namely that you have to give
credit to UCB, and distributing an Ethereal binary statically linked
with libpcap probably counts as redistributing libpcap. I don't think
there's a problem with redistributing *dynamically*-linked versions
unless distributing code that uses #defines, or something such as that,
counts as "redistributing".
The OpenSSL licenses have similar problems, although the SSLeay license
doesn't just talk about redistributing:
http://www.sdisw.com/openssl.htm
"Copyright remains Eric Young's, and as such any Copyright notices in
the code are not to be removed. If this package is used in a product,
Eric Young should be given attribution as the author of the parts of
the library used. This can be in the form of a textual message at
program startup or in documentation (online or textual) provided with
the package."
so it might be that something built using that SSLeay code, as
something built with OpenSSL might be, has to give credit, even if it's
dynamically linked with that code.
