On Sat, Mar 30, 2024 at 7:54 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. > This is not helpful in the slightest and the tone is not appreciated at all. That said, this is being tracked by the Packaging Committee: https://pagure.io/packaging-committee/issue/1350 > > 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-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). > > 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. > Yes, we should scrutinize things like this. Though I will note that we didn't actually suffer an attack through this venue with library code, just the build scripts. Generally, people do not pay attention to build scripts, and that was how this slipped by for so long. But even so, Autotools is particularly difficult to understand and I don't think we would have ordinarily caught it anyway. > > (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. > I don't know if the security path package list would help any, since we still have no one to do security work. That said, I agree that pretty much every display manager and compositor for every Fedora variant should be critpath'd. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
