On Wed, Mar 15, 2017 at 9:51 AM, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote: > > On 15 March 2017 at 00:05, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> > 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_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
