* Richard W. M. Jones: > I'm not pretending these will solve everything, but they should make > attacks a little harder in future. > > > (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. Not shipping the m4 files and other artifacts required for regenerating autoconf scripts is not exactly rare, unfortunately. I have filed a bunch of bugs because it's my understanding that this incomplete source code is against Fedora policies, but in the end, there isn't much we can do about it. But I sympathize with this approach, we should build from sources as much as we can. Maybe not regenerate everything in %prep though, this really belongs into %build. It's invoking a compiler, after all. > 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. I would expect that's what the serial number is for? But that's just a guess. > (2) We should discourage gnulib as much as possible. Or use Git sources without bundled gnulib, and re-bundled at build time using gnulib-devel. It would make gnulib updates easier. Such updates are sometimes required because gnulib overrides glibc internals without much coordination, and gnulib-using software may fail to build (or run) until gnulib is updated to reflect the internal glibc changes. However, while I don't particularly like autoconf and gnulib (they are mainly there to support systems other than GNU/Linux, most of them proprietary), I don't expect any steps we take there to stop anyone who targets Fedora specifically. Being different from other distributions doesn't help at all if Fedora is the target. > (3) We should have a "security path", like "critical path". I think there is a strong overlap with a bootstrap package set that is occasionally discussed. And this leads to the main point I want to make: Stopping an attack that has already happened does not make much sense. Given that we work in the open, preventing future attacks that target Fedora specifically is likely impossible. Therefore, the focus should be on builder and buildroot integrity, and generic strategies for restoring buildroot integrity after an incident. In this particular case, so far we considered it sufficient to merely downgrade one package. But the package in question was part of the default buildroot. That means that in theory, it could have persisted itself outside the confines of its own package. > 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. The bootstrap set depends on SWIG, and SWIG pulls in language implementations which are not bootstrapped from source using the previous version. Thanks, Florian -- _______________________________________________ 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
