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