Re: OpenSSL and RPATH's

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf
> Of PGNet Dev
> Sent: Wednesday, May 31, 2017 11:12
> 
> And, IMO, that's just bad advice.  RPATH is perfectly fine, and this^ is exactly
> what it exists for.  Feel free to use it or not, but don't FUD perfectly
> legitimate functionality as a 'bad idea'.

I, on the other hand, agree with Wouter. Binding filesystem information into a binary is an inherently bad idea. It violates the principle of least surprise and goes against conventions of UNIX filesystem use that have existed for more than four decades. It's not adequately visible to users or applications.

The fact that it solves certain problems doesn't change that. Sometimes it may even be the best of a set of poor solutions (though frankly I'm not convinced your example is such a case). That, too, does not mean it's not a bad idea.

Obviously "bad idea" is a largely subjective assessment. Characterizing it as FUD, however, is unjustified.
 
Of course, the real problem is excessive coupling between dynamically-bound code in the first place, caused by inadequate naming and versioning conventions, and even more so by poor backward and forward compatibility. OpenSSL is not a particular offender in this area, relatively speaking; the problem is widespread (and many attempts to resolve it are misguided aggravations, like Microsoft's SxS mess).

Regardless: Clearly there is no consensus that it's a *good* idea, and therefore having the OpenSSL build set RPATH by default (as has been suggested by some people in this thread) would be undesirable.

Michael Wojcik 
Distinguished Engineer, Micro Focus 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux