On 15 March 2017 at 00:05, Jonathan Wakely <jwak...@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.
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 <http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
