linux-from-scratch/lfs-buildscripts
1
0
Fork 0
mirror of https://github.com/YellowJacketLinux/lfs-buildscripts.git synced 2025-01-23 14:32:20 +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 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 IPv6 support and just use IPv4 with NAT for their home network. Such systems
would potentially have __remote__ vulnerability to future (or present secret would potentially have __remote__ vulnerability to future (or present secret
zero-day) exploits in Linux-PAM. Such systems would __NOT__ be vulnerable if zero-day) exploits in Linux-PAM. Such systems would __NOT__ be vulnerable to
they did not use Linux-PAM. Linux-PAM exploits if they did not use Linux-PAM.
Linux-PAM is absolutely the right solution in some corporate environments but it 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 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, if it *really* is important enough for a third-party package
repository to provide it. 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 ### Filesystems
@ -202,9 +207,9 @@ available for YJL.
### Fonts ### Fonts
In my opinion, fonts in GNU/Linux is a mess. The problem is there are far too In my opinion, fonts in most GNU/Linux distributions are a mess. The problem is
many installed, making it difficult from a UI perspective to select a font. Less there are far too many installed, making it difficult from a UI perspective to
is more. select a font. Less is more.
Back when the Apple Macintosh first shipped, there was a small collection of Back when the Apple Macintosh first shipped, there was a small collection of
high quality variable-width bitmap fonts. The ‘Desktop Publishing’ era had high quality variable-width bitmap fonts. The ‘Desktop Publishing’ era had
@ -288,13 +293,14 @@ desktop user.
### 32-bit Compatibility ### 32-bit Compatibility
YJL is for 64-bit systems. The base operating system will not provide any 32-bit YJL is for 64-bit `x86_64` systems. The base operating system will not provide
libraries. any 32-bit libraries.
It *hopefully* will be possible to cross-compile 32-bit libraries to install 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 into somewhere like `/opt/32-bit` so that things like the Second Life
can run it, but the operating system is __NOT__ being built with 32-bit ‘Firestorm’ client viewer can run on it, but the operating system is __NOT__
compatibility in mind. 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 ### FireFox

55
TLS-README.md
View File

@ -1,8 +1,8 @@
TLS Implementation TLS Implementation
================== ==================
LFS and most of the GNU/Linux world primarily uses OpenSSL for TLS. This is LFS and most of the GNU/Linux world primarily use OpenSSL for TLS. This is one
one place where I am deviating, sort of. place where I am deviating, sort of.
With Yellow-Jacket GNU/Linux my preference is to use GnuTLS for the TLS stack 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 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 maintained but until then, YJL can still use LibreSSL for *most* OpenSSL API
needs and use OpenSSL exclusively for Python3. 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 Important Concept
----------------- -----------------
@ -60,8 +81,8 @@ On YJL, `/usr/bin/libressl` is guaranteed to exist. It is a required package and
is always there. is always there.
On YJL, `/usr/bin/openssl` *might* exist but may not be present. When it is 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 present, it *might* be a symbolic link to `/usr/bin/libressl` or it *might* be
the binary built from OpenSSL. the binary built from the unforked modern OpenSSL source. The user has choice.
Scripts that ordinarily call the `openssl` binary should call the `libressl` Scripts that ordinarily call the `openssl` binary should call the `libressl`
binary instead and should not use features of OpenSSL newer than what was 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 so that the proper devel package is present on the system when the package
builds. builds.
The `libressl-devel` and `openssl-devel` packages do conflict with each other
LibreSSL Build Notes 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.
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.
Certificate Bundle Notes 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 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 `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. against.
So long story short, I patched `make-ca` to use `/usr/bin/libressl` for 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`. patched it to use `/usr/bin/curl`.
The initial `certdata.txt` file is installed from elsewhere (not retrieved via 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 the `make-ca` script on first run) and then the initial certificate bundles are
using `make-ca -r`. This then results in a valid certificate bundle that `curl` generated from it using `make-ca -r`. This then results in a valid certificate
can use to grab an updated `certdata.txt` file when a new version is published. 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 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 initial `certdata.txt` file and is the same file that unpatched `make-ca` would