Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: brp-mangle-shebangs no longer removes the executable bit from text files without shebangs (e.g. systemd .service/.socket/.timer files). The script uses `file --mime-type` and greps for "text/" to find text files. Since file 5.47, systemd unit files are classified as "application/x-wine-extension-ini" instead of "text/plain", so the grep no longer matches and brp-mangle-shebangs skips them. As a result, ~20 packages in F45 rawhide ship systemd unit files with mode 0755 instead of 0644. The current approach is fragile -- it depends on exact mime type strings from `file`, which change between releases (as noted in BZ#2513643 comment #1). Any future `file` update can silently break brp-mangle-shebangs again. Version-Release number: redhat-rpm-config-344-5.fc45.noarch (brp-mangle-shebangs) file-5.47-3.fc45.x86_64 How reproducible: Always Steps to Reproduce: 1. Build any spec that uses `install -p` (without -m) for a .service file 2. Check resulting RPM permissions with `rpm -qlp --dump` Actual Results: Unit file has 0755 - brp-mangle-shebangs did not remove executable bit. Expected Results: Unit file has 0644 - as it was with file 5.46 on F44. Additional info: Relevant code: brp-mangle-shebangs lines 77-79 https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-mangle-shebangs#_77 See also: - BZ#2513643 (file 5.47 mime type change) - BZ#2512037 comment #4 (Panu Matilainen) - BZ#2513643 comment #1 (Lukas Zaoral) Tested on VM with Fedora-Workstation-Live-Rawhide-20260807.n.0.x86_64.iso
I agree that the current approach is fragile. Do we have a better alternative?
For one, I think it'd be better to have it error out than just strip permissions with a warning that folks aren't going to notice in a noisy build. If you want files to have 644 permissions then install them that way instead of relying some script to maybe take care of it.
Agreed on both points, but that would be a breaking change, and I don't have the capacity to drive that. And either way, we would still need to figure out how to make the detection less fragile (regardless of whether the detection is used to strip permissions or to fail the build).
I'm thinking, are there any non-ELF files that should be executable, unless they have a proper shebang-line? Unlike arbitrary plaintext file types, ELF can be reliably detected, so if the logic is basically turned around to operate on everything non-ELF then it should be quite deterministic. Okay, there's /proc/sys/fs/binfmt_misc, but is such content being packaged, as executables? Even .exe files in Wine don't ship with executable bits, at least nowadays.
> are there any non-ELF files that should be executable, unless they have a proper shebang-line? Not sure. Switching this that way would potentially be a backwards-incompatible change. > Okay, there's /proc/sys/fs/binfmt_misc, but is such content being packaged, as executables. Just the files I have installed on my workstation: Mono: - /usr/lib/mono/4.5/svcutil.exe → mono-web-6.12.0-21.fc43 - /usr/lib64/gnome-subtitles/gnome-subtitles.exe → gnome-subtitles-1.8-13.fc43 - /usr/lib64/gnome-subtitles/gstreamer-sharp.dll → gnome-subtitles-1.8-13.fc43 WebAssembly: - /usr/lib/node_modules/undici/lib/llhttp/llhttp.wasm → nodejs-undici-7.24.0-1.fc43 Python wheels: - /usr/share/python-wheels/pip-25.1.1-py3-none-any.whl → python-pip-wheel-25.1.1-18.fc43 - /usr/share/python-wheels/setuptools-78.1.1-py3-none-any.whl → python-setuptools-wheel-78.1.1-15.fc43 + Dozens of images and other data files that likely have bogus executable permissions. Interestingly, I was surprised to see the Python wheels are installed as 0755. Apparently, it's the default mode for the install command, so this is my own packaging mistake. A change like this will likely uncover dozens of other cases. I do not have the capacity to drive that change and fix all the packages (even though it is arguably a good thing).
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/367 (rawhide) https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/368 (f45) Using file --mime-encoding as a fix.