On Wed, Mar 15, 2017 at 9:51 AM, Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com> wrote:
On 15 March 2017 at 00:05, Jonathan Wakely <jwakely(a)fedoraproject.org>
wrote:
>
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
>
> Being unable to statically link their applications would be a
> showstopper for some, and would cause them to move to a different
> distro.
So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100% sure
that exactly this part is not in RH support small prints. In other words you
may have only impression that this part is already covered in support
conditions.
Again try to answer on question why long time ago other OSes abandoned
providing static libc?
Internally this part is and always will be affected by definition by any
future changes in kernel ABI. glibc it is not only libc library. Glibc
provides couple of other components which are using internal glibc ABI/API.
Shared libc wraps all those changes and allows handle (in long term) even
quite significant changes beneath own glibc public API/ABI and on boundary
between kernel<->user space without hurting user space binaries.
And one more clarification: remove static libraries from glibc distro
packages does not blocks static linking.
It will only removes possibility linking against static glibc libraries.
Yes. This is a blocker for some people, who want *completely* static
binaries to have complete binary control of their active package.
glibc changing from a random update and possibly introducing a
regression problem is anathema to some critical software developers,
and the compilation of completely static binaries has been helpful for
cross-platform compatibility, for building chroot cages, and for
building well managed containers of various sorts.
Been there, done that with sorting out the library dependencies for
rssh chroot cages some time ago.
You can ignore me but you cannot ignore facts behind why something
like libc
exist and why no one should use static version of the libc libraries.
I think you're mixing orthogonal concerns.
Especially static linking with glibc is very dangerous as long if
linked
binary is using NSS libc interface. Some people are thinking that "fully"
statically linked program does not use or will not need any DSOs. In case of
using by such binary NSS libc interface this not true as depends on NSS map
type and NSS settings (described in /etc/nsswitch.conf) will be causing
loading nss_<foo>.so DSOs.
Well, yes. nsswitch.conf has been a mess since it was invented, for
reasons beyond the scope of this discussion.
Number of changes in glibc in internal NSS interface where quite big
in
recent years, and if someone will/is using statically linked binary where
NSS interface is in use such binary will be loading NSS modules (probably)
compiled against not correct glibc.Result: execution of such binaries will
fail or even crash with SIGSEV.
This scenario is covered literally as well in glibc documentation:
https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_nee...
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.
It is already known that within next few years NSS area in glibc it
will be
probably one of the fastest changing area in glibc whole project. Solaris
already coverers in his own libc many NSS security related extensions. Glibc
has a lot to catch up here. All those upcoming changes will definitely even
harder kick back all people linking own executables against glibc static
libraries. This will be probably even bigger problem than all potential
kernel<->user space ABI changes.
You've a point about NSS instability. That's actually quite
frightening. I lack your confidence that it justifies enforcing
dynamic libraries, and it seems *very* unlikely that the API's will
change enough to break older, stable software.
Other static libraries used by distribution are carrying as well real
and
potential security risk.
It's true that it's a trade-off. The potential instability issue of a
glibc regression error is quite noticeable for high reliability
components, and even the "dnf update" process is vulnerable to glibc
update issues under some circumstances, such as running out of disk or
failing power during the update. High churn in the glibc library, such
as you're suggesting is likely for NSS, is a reason to *insist* on
retaining static libraries for glibc.
Example: RH/Fedora is using bash which is linked against own copy of
readline (provided within bash original source tree). It was few CVEs in
readline in recent years and some people been exploiting fact that bash
was/is linked against readline with well known security issue.
So here is surprise: in case finding new 0-day bug(s) in readline it will be
necessary to provide not one readline fixed package but two .. readline and
bash.
Yes. RH/Fedora bash has some very well known security flaw which hanging
above whole distro reputation like a Damocles sword!!!
In last 20 years I've been trying to convince few people to remove exactly
this bash risk but last time when I've been trying this my English was not
good enough to express this enough clear and strong. Maybe this time ..
Good luck with that. Then please, raise it. I don't think you're going
to get anywhere with it. Bash is one of the components that *must* be
stable. A glibc update that introduces a problem could break the very
update processes used to update bash.
Reality is that remove building and providing all of those +190
-static
packages will as well allow save a lot of CPU time on Fedora build systems.
I'm 100% sure that no one is using those static libraries and they are build
and packaged only because some project source trees default settings are
building those static libraries. That is only reason why those .a files are
still flying around!!!
Then go after them one at a time, not as a policy statement to be
imposed without the buy-in of those program owners.
And yet another fact: in last decade number of packages providing
static
copies of some libraries decreased few times (only in RH distribution). This
is because there are more tan few people aware that building packaging those
files is pointless.
Hardly. Many packagers of static environments do it by locking the yum
or dnf repository that they build software from, and use host images
rather than built up software enviroments to work with.
Controlling internal entropy and keeping it on lowest possible level
on
whole distro level should be everyone goal as well :)
And that's why people use static libraries. Because dynamically
udpated libraries which may have never been tested with your
individual, unique software combinations is *generating* entropy.
Summarising. There are at least three reasons why static libraries
should be
completely removed from distribution:
1) Constant ABI changes
2) Security risk
3) Waste of time/resources on building and providing static libraries
And reasons to keep them.
1) Complete software stability
2) Regession failures generated by buggy library updates
3) The difficulty of forcing restarts of all daemons which use the
updated libraries to incorporate the updates, rather than forcing an
update of the package itself with associated, schedulable daemon
restarts.
> kloczek
> --
> Tomasz Kłoczko | :
http://lnkd.in/FXPWxH
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>