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.
Remove static libc it is not new idea. It is +20 years around and none of the Solaris users moved away from this OS by this reason.
No .. it is completely opposite situation. Because OS like Solaris does not provides libc.a still even on latest Solaris is possible execute and use more than decade old binaries.
Linux kernel ABI is changing constantly and flexibility on boundary between kernel and userspace is covered in Linux kernel documentation literally. From Documentation/ABI/README:
stable/
This directory documents the interfaces that the developer has
defined to be stable. Userspace programs are free to use these
interfaces with no restrictions, and backward compatibility for
them will be guaranteed for at least 2 years. Most interfaces
(like syscalls) are expected to never change and always be
available.Possibility of future changes between kernel and user space was even one of the fundamental reasons why libc was developed looog time ago before Linus started thinking about porting Minix to i386.
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.
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.
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
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.
Other static libraries used by distribution are carrying as well real and potential security risk.
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 ..
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!!!
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.
Controlling internal entropy and keeping it on lowest possible level on whole distro level should be everyone goal as well :)
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
kloczek
-- Tomasz Kłoczko | : http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
