> So here is kind contradiction because my past experience that such binaries
> are used so long (+6 years) that it causes silent issues with conflicts on
> kernel<->user space and sooner or later initial intention turns into
> disaster as no one remembers who and how initially such binary was made.
That is also a problem. It's also not really solved by dynamic
libraries. if the ABI for the libraries is changing that much, it's
likely necessary to recompile the base software *anyway*.
> 2) some bootstrapping scenarios like for example static linking grub
> binaries
>
> In such cases binaries are will be regenerated with every small change in
> non-public ABI/API changes will be followed by immediate recompilation of
> such binaries so ris here is effective null and such limited number binaries
> should be accepted and carefully maintained.
And... we're to build them without glibc-static.... how?
> Scenario when such special binaries been crafted for initrd already are
> nullified because today even smallest systems have enough memory to use
> regular shared libraries. Simple one one needs today to fit such initrds on
> 3.5' floppy disk with 1.44MB available storage.
Boot media are one of those cases where binary stability are *most* critical.
> 3) some people are thinking that static linking make sense from performance
> or resource consumption perspective.
Straw man argument, 5 yard penalty.
The relocation of binaries to different places in the same operating
system is not the problem. Moving it from one operating sytem or
container to another, *that* is the problem. And running exactly the
version you expect, even if it's inside a heavily modified container
or distinct operating system of some sort is a powerful goal. I don't
run into it as much as I used to, but I certainly used to have to
compile components statically in various environments for use
elsewhere.
>> You seem to pointing out that NSS is a stability problem. You're quite
>> right. Saying that "NSS is unstable, therefore glibc should be forced
>> to dynamic libraries only" does not follow. The underlying API for
>> nsswitch.conf and NSS does not change that quickly, it's the feature
>> churn for add-ons that are being tied into NSS. For high stability
>> software, *who cared*? You won't use the most recent NSS changes, and
>> if you do, they're quite likely to be available the the glibc static
>> library at the time you compile them. Statically.
>
>
> You are wrong that this is abut messiness/stability of the NSS interface.
> We are talking about internal glibc ABI/API on which none of the
> system/distribution binaries should rely on such internal interfaces which
> any project maintainer has freedom to change without even noticing this in
> changelogs.
If they're dinking with it that much, it's likely to lead to changes
in the ABI as well and force recompilation. That level of change is
not normally permitted within a single Fedora release, and packages
for Fedora are rebuilt for new releases.
Again, straw man argument, and another 5 yeard penalty.
> Using statically linked binaries creates RISK here if those binaries will be
> not refreshed.
Now, *that* is real. However, see above, to wit:
* Packages for Fedora are rebuilt for new releases.
> Risk of not to be exposed on internal NSS ABI changes can be very easy
> nullified by using in such rare cases static linking with libc like uClibc
> which has no NSS interface.
And if I walk on only my right foot, I can save wear and tear on my
left shoe. Doesn't seem worth the effort. uClibc is a cool idea, but
unlikely to work well for a broad variety of complex software which
has ever been compiled or tested with it.
> In last decade bash already created enough number CVEs to start thinking
> about moving away from bash as /bin/sh provider.
> Sun/Oracle already done careful ksh security review which bash never had
> done. Because ksh is very small and his main goal is provide /bin/sh number
> of any future changes will be very well known and limited to cleanups and
> bug fixes.
And we can get C++ programmers to going back to C, to avoid the
function overloading problem.
I'm afraid it's not gonna happen
> Changing /bin/sh to real SH interpreter IMO should be kind of long term
> Fedora target. It will be not easy and maybe even painful but minimize
> /bin/sh dependencies and minimize security risk is IMO worth to start
> thinking about some preparations to be opened on such change in the future.
> Other issue is that bash is not the fastest /bin/sh interpreter :)
It's a lot of work with a profound loss of shell functionality and
features, with a nebulous security benefit. Sorry, but I don't see it
happening anytime in the foreseeable future.
> In other words all those goals which you mention are not strictly related to
> static linking and it is possible to do a lot (or much more) to minimize
> such risks without even thinking about provide glibc-static. Static linking
Umm. No. You're mistaking "reduction of library dependencies" with
"discaarding static library compilation".
*Cool*. And you've my sympathies, those kinds of subtle undetected
dependencies can be tricky to resolve.