httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Philip Baker <darryl.ba...@northwestern.edu>
Subject Re: [users@httpd] Compiling Apache with Non-System OpenSSL
Date Wed, 31 Jul 2019 14:14:12 GMT
On 7/31/19, 4:29 AM, "Rainer Canavan" <rainer.canavan@sevenval.com> wrote:

    On Wed, Jul 31, 2019 at 1:39 AM Nigel B. Peck <nigelbpeck@gmail.com> wrote:
    >>
    >> Thanks for the answers, great to have more insight on this.
    >>
    >> Is this a bug? Shouldn't it set up the linking correctly itself when
    >> the library has been specified using `--with-ssl`, as it does for
    >> `--with-pcre`? I'm considering submitting a bug report, but only want
    >> to do so if it really is.
    
    
    > In my opinion, this is not a bug. autoconf has been handling this the
    > way it currently does for decades. Adding an RUN_PATH has the potentially
    > unwanted side effect that the binary will preferentially use libraries from
    > that directory instead of the system search paths. Additionally, the library
    > locations during build time are frequently different from those used at
    > run time. If you want your library locations fixed at build time, try cmake.
  
Sorry to jump in in the middle of this conversation but if you really want to fix the libraries
at build time just create a static executable. 
I want to mention this approach even though I'm not a fan of it in most cases, especially
for complex applications with network connectivity. 
Pros:
	On every machine it has exactly the libraries it was built with, no matter what or where
anything is installed on that system.
	(Before the advent of shared libraries, all executables were built this way.)
Cons:
	On every machine it has exactly the libraries it was built with, no matter what or where
anything is installed on that system.
	System patching has no effect. The bugs in the libraries it was built with stay until it
is rebuilt with patched static libraries.
	The executable itself is bigger both on disk and in memory because it shares no code with
any other program on the system.

Building static executables is more useful for diagnostic and security scanning applications
where you cannot trust the integrity of the execution environment. As an example, a statically
built ps program may show rogue processes where a ps using the in place shared libraries can
be blinded to those processes by installing a hacked version of the shared libraries. Though
it will not be effective against a kernel level hack.

Darryl Baker  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL  60201-3715
darryl.baker@northwestern.edu
(847) 467-6674
 

    

Mime
View raw message