For Override packages: https://sourceware.org/glibc/wiki/FAQ

For Multi-Arch System packages: https://wiki.debian.org/Multiarch/HOWTO

Overriding:

The reason for overriding the current glibc is for testing. This will allow the compiler to run on a different directory from the system and not interfere or brake other users or files on that system. The system can only have one version of glibc installed.

Mutli-Arch System Packages:

Multi-arch allow libraries to be installed on a machine/system with the ability to code or communicate with multiple architectures like arch64, x86_64, etc.

The libraries are the same for the architectures but the machine will have to rely on dependencies to run correctly. This will force each architecture to provide an up-to-date list of dependencies for the multi-arch configuration to work.

Apparently the word ‘architecture’ means ‘ABI'(Application Binary Interface’ and not an ‘ISA’ (Instruction Set).
An example the source provides: ‘armel’ architecture and ‘armhf’ architecture are similar with the same instruction set but have different Application Binary Interface.
A basic example is an Internet Browser: Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, etc. All of these browsers have the basic function of accessing webpages and websites but are coded differently.

Multi-arch packages are separated into three categories:
-Multi-Arch:foreign
This label will allow the package to be installed on a different architecture.
-Multi-Arch:same
This label will allow the package to be installed with multiple versions of the same package
-Multi-Arch:allowed
This label will act as either Multi-Arch:foreign or Multi-Arch:same depending on dependency required. This is kinda of like a combination or ‘full’ package of that dependency compared to the other two types of Multi-Arch packaging.

For Debian: apt version 0.9 and earlier causes the installation of dependencies to fail unless Multi-Arch was turned off. The gcc library can have multiple packages installed on the machine and relies on the Multi-Arch packages to be installed to run all the different libraries of the glibc library.

For Debian: in some case the compiler will require cross-dependencies packages to run. This will require the use of another architectures set of instructions to be used in that architecture’s native code/program and then imported to be used by the compiler to run the program/ application on your specific architecture. For example: arm64 importing packages from arch64 architecture.
-This example will force the compiler to get the packages from the arch64 and then import it to the arm64 architecture maybe because the arm64 architecture does not have the processing capabilities of the arch64 architecture. It is also maybe because of the better performance or lower bug risk when using the different package than the machine’s own architecture.

Comment:

Override vs Multi-Arch system
Multi-arch system seems more flexible in error handing compared to override. Override can brake the entire system if not configured correctly.

The process used to be submitted through the developer’s mailing list and a bug database.
The process is now automated through the bug database Bugzilla:
(http://bz.apache.org/bugzilla/)

The basic requirements for Bugzilla:
(Process is from: https://httpd.apache.org/dev/patches.html)
-Must have a Bugzilla account; Process found here:

https://bz.apache.org/bugzilla/createaccount.cgi
-Fill in a bug report
-Must specify APR(if the patch is for srclib/apr or srclib/apr-util)
-Carefully explain the process of reproducing the bug and how the patch has been tested
-Edit the bug report to have a “PatchAvailable” keyword with a patch attached as the final step

If the patch is ignored:
-Be persist but polite
-Get other Apache users to review the patch
-Make the patch easy to read and apply
-Research if there are any current or similar patches already being discussed in the community
-Help with other bugs to gain recognition in the community

This is a small community as stated by Apache.

An example is from (https://httpd.apache.org/security/vulnerabilities_24.html)

mod_md, DoS via Coredumps on specially crafted requests (CVE-2018-8011)
-Reported on 29 Jun 2018
-Update Released on 15 Jul 2018

Additional Detail:
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8011)
(https://www.securitytracker.com/id/1041401)

Basically the exploit can cause the child process to crash from the remote user.

The process seems relatively fast (About half a month). First the process has to be found by a community user and reported (In this case it was through: https://www.securitytracker.com/id/1041401). The patch is tested through Bugzilla and sent to be released.

The process to patching seems straightforward but will not be fast if I were to start as a newcomer of the community.

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton