Richard W.M. Jones wrote:
(1) We should routinely delete autoconf-generated cruft from
upstream
projects and regenerate it in %prep. It is easier to study the real
source rather than dig through the convoluted, generated shell script
in an upstream './configure' looking for back doors.
For most projects, just running "autoreconf -fiv" is enough.
Yes, there are some projects that depend on a specific or old version
of autoconf. We should fix those. But that doesn't need to delay us
from using autoreconf on many projects today.
I have always said that. We do not allow other prebuilt binary blobs and
require rebuilding everything from source. I do not see how the obfuscated
autogenerated shell scripts from the autotools are any different. Sadly, I
was ignored. Now you folks (Fedora) see where this leads. Told You So.
In the xz case this wouldn't have been enough, it turns out we
would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates. I don't fully understand why that is.
Looks like autoreconf does not work as advertised. With -f, it is supposed
to regenerate all files that it knows how to regenerate. It clearly does not
do what it is supposed to and ought to be fixed.
(2) We should discourage gnulib as much as possible.
In libvirt we took the decision a few years ago to remove gnulib.
It's extremely convoluted and almost no one understands how it really
works. It's written in obscure m4 macros and shell script.
It's also not necessary for Linux since gnulib is mainly about
porting to non-Linux platforms. There are better ways to do this.
In the xz case it was a gnulib-derived script which was modified to do
the initial injection (original:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-ho...).
There too, I agree completely. Also because gnulib is a "copylib", which is
a very broken concept. A true library would not be subject to this kind of
"take the file from the copylib and inject bad code into it" attack.
(3) We should have a "security path", like "critical
path".
sshd is linked to a lot of libraries:
/lib64/libaudit.so.1 audit-libs
/lib64/libc.so.6 glibc
/lib64/libcap-ng.so.0 libcap-ng
/lib64/libcap.so.2 libcap
/lib64/libcom_err.so.2 libcom_err
/lib64/libcrypt.so.2 libxcrypt
/lib64/libcrypto.so.3 openssl-libs
/lib64/libeconf.so.0 libeconf
/lib64/libgcc_s.so.1 libgcc
/lib64/libgssapi_krb5.so.2 krb5-libs
/lib64/libk5crypto.so.3 krb5-libs
/lib64/libkeyutils.so.1 keyutils-libs
/lib64/libkrb5.so.3 krb5-libs
/lib64/libkrb5support.so.0 krb5-libs
/lib64/liblz4.so.1 lz4-libs
/lib64/liblzma.so.5 xz-libs
/lib64/libm.so.6 glibc
/lib64/libpam.so.0 pam-libs
/lib64/libpcre2-8.so.0 pcre2
/lib64/libresolv.so.2 glibc
/lib64/libselinux.so.1 libselinux
/lib64/libsystemd.so.0 systemd-libs
/lib64/libz.so.1 zlib / zlib-ng
/lib64/libzstd.so.1 zstd
Should we have a higher level of attention to these packages? We
already have "critical path", but that's a broad category now. These
seem like they are "security path" packages, an intentionally small
subset associated with very secure services which are enabled by
default.
I think the issue is that there is just too much stuff in critpath these
days. Whole desktop environments and all their transitive dependencies
probably ought to not be in there. If at all, I would put the display
manager in there, maybe the window manager, and no further.
Kevin Kofler