On Tue, Jan 8, 2013 at 1:14 PM, Carson Gaspar <car...@taltos.org> wrote:
> On 1/8/13 9:52 AM, Jeffrey Walton wrote:
>>
>> That seems like a really odd requirement. Is there any reading on the
>> topic?
>
> man nsswitch.conf
>
>> Generally, I prefer static linking in high integrity software. And I
>> oppose "plug-in" like functionality.
For completeness, I was talking about high integrity software in both
cases. I don't consider a $50 Amazon transaction worthy of high
integrity software since the value of the data is low (or perhaps
approaches medium).
> Then you need to not run on Linux or Solaris, or roll your own name service
> lookup code (or use an alternate libc). I believe some of the *BSDs share
> your opinion.
Are those the only two options? Forgive my ignorance - I've never
studied the problem.
> Name Service Switch is what underlies all the getfoobybar and getfooent
> calls. They indirect vi the nss library, which reads /etc/nsswitch.conf, and
> then dispatches the lookup to the configured backend(s) (files, NIS, LDAP,
> DNS, ...)
So I'm clear, NSS library is "Name Service Switch", and not the
Mozilla security library of the same name. I really don't want Mozilla
code polluting my code if it can avoided.
Before the Mozilla folks get their panties in a wad: Trustwave, and
the non-public negotiations that occurred between Trustwave and
Mozilla before the blog. What is the motivation for Mozilla's penchant
to performing fellacio on the CA industry? As a google whore, it makes
money hand over fist and does not need the CA industry. That sort of
crap does not serve the end users well (and that's all I care about).
> Dynamic linking is here to stay - embrace your shared object overlords ;-)
OT: Do you think the tools will ever catch up?
Autoconf and friends (including Make) never evolved with the addition
of shared objects. So there's no way to specify a consistent set of
LDFLAGS tuned both compiled programs and shared objects (which is
common with library code that supplies utility programs and test
programs to exercise the library). For example, a shared object needs
-fPIC and -shared; while a compiled program needs -fPIE and -pie. So
how do we pidgin hole this common idiom:
./configure CFLAGS="-Wall -Wextra \
-Wconversion -Wstrict-overflow \
<other options> <ASLR>"
where <ASLR> is either -fPIC and -shared; or -fPIE and -pie. I think
we need two LDFLAGS like variables, or use LDFLAGS as a base and
ability to specify addition personalities for shared objects and
compiled programs.
And don't get me started on Debug vs Release builds, Autoconf's lack
of support, and Make's ignorance to changing flags (-g3 -ggdb -O0 vs
-g -O2). Its too bad we are stuck with using tools form the 1970s
while the platform and art has evolved.
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
