www/libwww and SSL
Paul Schmehl
pauls at utdallas.edu
Sun Dec 31 12:49:57 PST 2006
--On December 31, 2006 1:22:44 PM -0700 Mike Durian
<durian at shadetreesoftware.com> wrote:>
> We've got the source, so we might be able to come up with an answer
> that is a bit less conjectural. I encourage others to check my analysis.
>
> When --with-ssl is defined the configure script expands some variables,
> WWWSSL, SSLINC, LIBSSL, LWWWSSL, LIBWWWSSL and WWWSSLEX with non-empty
> values. If --with-ssl is not defined, or set to no, these variables
> are left empty. These variables are then set in every Makefile in
> the libwww build. However, the variables are only used in the Makefiles
> found in the SSL and Examples subdirectory (and children). I think
> we can ignore the Examples case, unless someone is using one of the
> examples as more than just an example.
>
> The SSL subdirectory is included in every build, even if --with-ssl is
> not defined. In the case where SSL is not defined, the libwwwssl library
> does not get built, however the SSL related header files are still
> installed.
>
> When --with-ssl is defined, the libwwwssl library gets built and is
> installed. As with the non-SSL case, the SSL header libraries are
> also installed.
>
> From this we see that the --with-ssl option only impacts the libwwwssl
> library itself. It does not impact any of the other libwww libraries
> (otherwise the SSL variables would have been used in other
> Makefiles). In particular, --with-ssl only results in libwwwssl
> libraries getting built and installed. SSL header files are always
> installed.
>
> Defining --with-ssl also impacts the libwww-config script which can
> be used to generate a list of libraries needed when linking programs
> that use libwww. In this case, -lwwwssl will be part of the library
> list and any programs using libwww will also link against -lwwwssl.
> But, if they aren't calling any functions found in -lwwwssl, it is
> hard to see how this will make any impact.
>
> So, adding --with-ssl will only impact other ports if part of their
> configuration looks for the libwwwssl library and uses functions in
> it, if found. That strikes me as a potential benefit to other ports,
> as it might make possible expanded functionality. We know from PR #99863
> that net/xmlrpc-c is one such port. From the PR, we know it will make
> use of libwwwssl if it is configured using --with-www-ssl, which is
> not an option in the BSD port Makefile.
>
> That's just my $0.02.
>
Your two cents makes a great deal of sense. It also makes me wonder if it
would be better to simply build the port with the --with-ssl make arg
rather than creating an option that must be selected before building.
The Makefile already has:
CONFIGURE_ARGS= --enable-shared --enable-static --with-zlib
Why not just expand it to:
CONFIGURE_ARGS= --enable-shared --enable-static --with-zlib --with-ssl
?
Paul Schmehl (pauls at utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
More information about the freebsd-ports
mailing list