On 1/8/2013 7:59 PM, Jeffrey Walton wrote:
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.
Please don't blame make for the failures of other programs (such as
the autoconf abomination or the cc library linking flags).
The two big failures are:
- Autoconf fundamentally assumes that you will compile the source on
every machine that runs it, that there is no cross compiling and that
any arbitrary aspect of the build machine (such as CPU model, kernel
version or installed software) will be equally true at runtime. Much
effort has since been wasted trying to add back cross-machine and
cross-platform abilities.
- The cc/gcc library linking flags on POSIX-like systems don't
facilitate explicitly specifying which libraries should be linked
statically and which ones dynamically, whichever comes first on
the search path wins.
- The linker semantics for shared libraries on POSIX-like platforms
take the list of names exported from a shared object on the build
machine as the definition of which names should be exported from
any compatible shared object, which again makes it harder to build
for use on other machines. To further complicate matters, most
systems generate executable binaries that are susceptible to
accidentally calling a similarly named function in a completely
different shared object which happens to be around at run time.
As for the last two points, it is worth noting that the DOS family
of later operating systems (OS/2, Windows) operates differently:
For each shared object there is a static-like "import library"
specifying which names to import from which shared object, and this
is passed to the linker like a regular static library, such that if
you have both a static and shared version of a library available,
their link-time libraries will have different names, such as
libc-static.a versus libc-dynamic.a (an import library).
On these platforms, the typical build tools do not include an
Autoconf like mechanism, since it is always assumed you are compiling
for other machines, which may have less (or more) software than the
build machine.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
