On Sat, Mar 30, 2024 at 8:53 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. > And in CMake's favor, there's a huge ecosystem of helpers and integrations that make it easier for people to understand what CMake is doing as it's being developed, built, and shipped. That makes it much more attractive than Autotools simply because the knowledge and the tooling is there for developers and users to dig into it. > > 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. > I didn't say every single one we package, just the ones shipped in deliverables. I think it's worth making sure those are on the critpath. -- 真実はいつも一つ！/ 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
