[OpenIndiana-discuss] 32-bit and/or 64-bit programs (Was: Bash bug issue)

[Bruce Lilly]

A while back, there was a suggestion made to build bash from updated
sources (patched for variations of the "shellshock" vulnerabilities),
simply mv /usr/bin/bash to another name and install a link to the newly
built program.

I pointed out that this might not be a good idea without first carefully
checking to make sure that /usr/bin/bash wasn't simply a copy of or link to
/usr/lib/isaexec as described in
https://docs.oracle.com/cd/E18752_01/html/816-5138/docinfo.html (Solaris
64-bit Developer's Guide).

Other UNIX-like systems that support both 32-bit and 64-bit versions
typically default to building 64-bit executables on 64-bit systems and do
not provide the isaexec mechanism to select executables.  Regardless of the
merits or lack thereof of either approach, the Solaris default of always
building 32-bit executables *only* is a deep dank pit in a poorly lit
corner of Solaris and Solaris-like systems that is likely to trap many
folks, particularly those coming from other backgrounds, and even
experienced developers porting source packages.  It isn't mentioned in any
of the places that promote building from sources (So Jim, how about
updating
http://wiki.illumos.org/display/illumos/Building+illumos+and+OpenIndiana
?), nor in Red Hat Enterprise Linux to Oracle Solaris Porting Guide
<http://www.oracle.com/technetwork/server-storage/solaris11/documentation/o12-026-linux2solaris-guide-1686620.pdf>
.

I mentioned that the 64-bit Developer's Guide is a bit dated: I say that
because the sole example of time_t-related issues mentioned there is
mortgages.  I suspect that few mortgage calculations are done using integer
arithmetic using time_t...  There are more ubiquitous uses of time_t, such
as:
1. ntp
2. expiration dates for certificates
3. any programs reliant on time synchronization (all version control
systems, rsync, etc.)
4. as a trivial example, lowly 'ls' needs to be able to deal with time_t to
display file modification times.

And there is not yet any good solution to the problem (see e.g. the
Wikipedia page for "Year 2038 problem").

Some of the above issues are intersecting: see
https://bugs.ntp.org/show_bug.cgi?id=2651