Neal Gompa wrote: > This is not helpful in the slightest and the tone is not appreciated at > all.
Well, I have been arguing against this exception (exempting prebuilt autotools output) from the "no prebuilt blobs" rule for years, and it saddens me that something like this had to happen for Fedora to finally realize that that exception has always been a bad idea. > That said, this is being tracked by the Packaging Committee: > https://pagure.io/packaging-committee/issue/1350 Finally, thanks! (But you filed that only now after this incident, see above. Still, thanks that you are bringing this up now!) > 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. I definitely agree there, build scripts are indeed an attractive target for backdoor authors, and autotools is indeed a big part of the problem. The whole architecture of autotools was designed for a situation that is mostly obsolete these days: people running some proprietary Unix with some buggy implementation of a Bourne-like shell and no centralized build tools who want to just untar a tarball and build it with only what they already have installed (the buggy shell). Hence all this concept of shipping prebuilt obfuscated shell blobs full of workarounds for bugs in ancient shell implementations. Nowadays, people are either running GNU/Linux, where centralized build tools such as CMake or Meson are readily installable from the repository (and where most builds are done by distributions, for whom it is just a matter of adding, e.g., "BuildRequires: cmake"), or Microsoft Windows, where an environment that can run autotools scripts (e.g., MSYS2) is NOT part of the system and actually as hard or harder to install than something like CMake. So, nowadays, pregenerating shell scripts is a completely outdated and unhelpful way of working. > That said, I agree that pretty much every display manager and > compositor for every Fedora variant should be critpath'd. Well, where we disagree is that I actually want to see LESS stuff in critpath, not more. It cannot be scrutinized well enough because there is just too much stuff in it. E.g., at times, we had MySQL/MariaDB in critpath because Akonadi required it. (Nowadays, Akonadi actually recommends using SQLite instead.) That just does not make sense. Kevin Kofler -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
