linux-from-scratch/lfs-buildscripts
1
0
Fork 0
mirror of https://github.com/YellowJacketLinux/lfs-buildscripts.git synced 2025-01-23 22:42:28 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc tweaks

Browse Source
This commit is contained in:
YellowJacketLinux 2024-10-10 12:35:13 -07:00
parent b21be9fefe
commit cf2b05fbe3
2 changed files with 50 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
THE_WHY.md
View File

@ -81,8 +81,8 @@ However there are many people now using 5G for home networks who either do not
have adequate IPv6 firewall technology or do not know that they should turn off
IPv6 support and just use IPv4 with NAT for their home network. Such systems
would potentially have __remote__ vulnerability to future (or present secret
zero-day) exploits in Linux-PAM. Such systems would __NOT__ be vulnerable if
they did not use Linux-PAM.
zero-day) exploits in Linux-PAM. Such systems would __NOT__ be vulnerable to
Linux-PAM exploits if they did not use Linux-PAM.
Linux-PAM is absolutely the right solution in some corporate environments but it
should be provided by add-on package repositories rather than forced upon all
@ -93,6 +93,11 @@ Those who need (or want) Linux-PAM in YJL can get it from a third-party package
repository, if it *really* is important enough for a third-party package
repository to provide it.
As far as I know, Slackware was the only mainstream GNU/Linux distribution that
did not force Linux-PAM on its users and I suspect the LSB is why virtually
every distribution did force it on its users instead of making it an optional
component to be installed when actually needed.
### Filesystems
@ -202,9 +207,9 @@ available for YJL.
### Fonts
In my opinion, fonts in GNU/Linux is a mess. The problem is there are far too
many installed, making it difficult from a UI perspective to select a font. Less
is more.
In my opinion, fonts in most GNU/Linux distributions are a mess. The problem is
there are far too many installed, making it difficult from a UI perspective to
select a font. Less is more.
Back when the Apple Macintosh first shipped, there was a small collection of
high quality variable-width bitmap fonts. The ‘Desktop Publishing’ era had
@ -288,13 +293,14 @@ desktop user.
### 32-bit Compatibility
YJL is for 64-bit systems. The base operating system will not provide any 32-bit
libraries.
YJL is for 64-bit `x86_64` systems. The base operating system will not provide
any 32-bit libraries.
It *hopefully* will be possible to cross-compile 32-bit libraries to install
into `/opt/32-bit` so that things like the Second Life ‘Firestorm’ client viewer
can run it, but the operating system is __NOT__ being built with 32-bit
compatibility in mind.
into somewhere like `/opt/32-bit` so that things like the Second Life
‘Firestorm’ client viewer can run on it, but the operating system is __NOT__
being built with 32-bit compatibility in mind. Of course it would be even better
if applications like Firestorm were ported to 64-bit.
### FireFox

55
TLS-README.md
View File

@ -1,8 +1,8 @@
TLS Implementation
==================
LFS and most of the GNU/Linux world primarily uses OpenSSL for TLS. This is
one place where I am deviating, sort of.
LFS and most of the GNU/Linux world primarily use OpenSSL for TLS. This is one
place where I am deviating, sort of.
With Yellow-Jacket GNU/Linux my preference is to use GnuTLS for the TLS stack
wherever possible and use LibreSSL to provide the OpenSSL API for software that
@ -52,6 +52,27 @@ to build against LibreSSL for the critical `_ssl` and `_hashlib` modules will be
maintained but until then, YJL can still use LibreSSL for *most* OpenSSL API
needs and use OpenSSL exclusively for Python3.
Note that `wget` and `curl` as built from the shell scripts in this git repo do
link against LibreSSL. That is temporary because GnuTLS is *not* built from the
shell scripts in this git repo.
The actual RPM spec files for those tools will build them against GnuTLS so they
will not use either implementation of the OpenSSL API.
LibreSSL Build Notes
--------------------
The build of LibreSSL itself is patched to use `libressl.cnf` instead of
`openssl.cnf` for the OpenSSL configuration file, and the binary is
installed as `libressl` instead of as `openssl`.
Doing so will allow those who want the *actual* `openssl` binary to have it
without the binary or configuration file conflicting with the LibreSSL fork.
For those who do not need the *actual* `openssl` binary, symbolic links allow
the traditional configuration file and binary name to still be used.
Important Concept
-----------------
@ -60,8 +81,8 @@ On YJL, `/usr/bin/libressl` is guaranteed to exist. It is a required package and
is always there.
On YJL, `/usr/bin/openssl` *might* exist but may not be present. When it is
present, it *might* be a symbolic link to `/usr/bin/openssl` or it *might* be
the binary built from OpenSSL.
present, it *might* be a symbolic link to `/usr/bin/libressl` or it *might* be
the binary built from the unforked modern OpenSSL source. The user has choice.
Scripts that ordinarily call the `openssl` binary should call the `libressl`
binary instead and should not use features of OpenSSL newer than what was
@ -92,19 +113,10 @@ On the other hand, packages that build just fine against LibreSSL should have:
so that the proper devel package is present on the system when the package
builds.
LibreSSL Build Notes
--------------------
The build of LibreSSL itself is patched to use `libressl.cnf` instead of
`openssl.cnf` for the OpenSSL configuration file, and the binary is
installed as `libressl` instead of as `openssl`.
Doing so will allow those who want the *actual* `openssl` binary to have it
without the binary or configuration file conflicting with the LibreSSL fork.
For those who do not need the *actual* `openssl` binary, symbolic links allow
the traditional configuration file and binary name to still be used.
The `libressl-devel` and `openssl-devel` packages do conflict with each other
but there is never a need to have both installed at the same time. In fact the
only reason either is ever needed is when compiling software that links against
the shared libraries.
Certificate Bundle Notes
@ -131,7 +143,7 @@ certificate was no longer valid.
What I found was that if I instead used `/usr/bin/curl` to retrieve the
`certdata.txt` file when an update was available, it worked, as long as there
already was valid certificate bundle for `curl` to validate the connection
already was a valid certificate bundle for `curl` to validate the connection
against.
So long story short, I patched `make-ca` to use `/usr/bin/libressl` for
@ -139,9 +151,10 @@ everything *except* the retrieval of a new `certdata.txt` file. For that, I
patched it to use `/usr/bin/curl`.
The initial `certdata.txt` file is installed from elsewhere (not retrieved via
the `make-ca` file) and then the certificate bundles are generated from it
using `make-ca -r`. This then results in a valid certificate bundle that `curl`
can use to grab an updated `certdata.txt` file when a new version is published.
the `make-ca` script on first run) and then the initial certificate bundles are
generated from it using `make-ca -r`. This then results in a valid certificate
bundle that `curl` can use to grab an updated `certdata.txt` file when a new
version is published.
In this git repo, the file `CH8Build/certdata-dist.txt` is installed as the
initial `certdata.txt` file and is the same file that unpatched `make-ca` would