public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
To: git-commits@fedoraproject.org
Subject: [rpms/redhat-rpm-config] f45: brp-mangle-shebangs: Detect text files by encoding, not MIME type
Date: Thu, 03 Sep 2026 11:50:38 GMT	[thread overview]
Message-ID: <178843623867.1.17509760578128411903.rpms-redhat-rpm-config-9110aec0fba3@fedoraproject.org> (raw)

            A new commit has been pushed.

            Repo   : rpms/redhat-rpm-config
            Branch : f45
            Commit : 9110aec0fba3fb2622df30eebf230821df8fc1f5
            Author : Miro Hrončok <miro@hroncok.cz>
            Date   : 2026-08-26T09:18:51+02:00
            Stats  : +2/-2 in 1 file(s)
            URL    : https://src.fedoraproject.org/rpms/redhat-rpm-config/c/9110aec0fba3fb2622df30eebf230821df8fc1f5?branch=f45

            Log:
            brp-mangle-shebangs: Detect text files by encoding, not MIME type

- Fixes: rhbz#2513837

file 5.47 started classifying some plain text files (e.g. INI-style files)
as application/x-wine-extension-ini,
which was not in our list of "text" MIME types,
so shebangs in such files went unmangled
and their missing-shebang executable bit was not stripped.

This particular change in file is tracked as a regression in rhbz#2513643,
and may as well get fixed upstream.

But we previously worked around a similar issue for JavaScript
by special-casing application/javascript,
and chasing every new text-like MIME type file invents
(whether intentional or not) is not sustainable.

Use `file --mime-encoding` instead of `file --mime-type`
and treat anything whose charset is not "binary" as text.
This charset field is computed by file's own text/binary heuristic
independently of which specific magic pattern (if any) matched,
so it covers any current or future text-like MIME type
without needing an explicit allowlist entry,
making this robust against this class of change in file.

Verified locally on Fedora 43 with file 5.46
and in a fedora:rawhide container with file 5.47
with a synthetic buildroot containing

 - a Shell script,
 - a Python script with an ambiguous #!/usr/bin/env python shebang,
 - an application/x-wine-extension-ini file (triggered with a "[windows]" section),
 - a real ELF binary,
 - and an empty file.

After the change, the Shell script's shebang is still mangled,
the ambiguous Python shebang still errors out as before,
the wine-ini-classified file is correctly detected as text
(no shebang -> executable bit stripped, matching pre-5.47 behavior),
and the ELF binary and empty file are left untouched exactly as before.

Assisted-By: Claude Sonnet 5

---
diff --git a/brp-mangle-shebangs b/brp-mangle-shebangs
index 47ef1ee..5047242 100755
--- a/brp-mangle-shebangs
+++ b/brp-mangle-shebangs
@@ -75,8 +75,8 @@ cd "$RPM_BUILD_ROOT"
 # but run just two of them.
 # (Take care to exclude filenames which would mangle "file" output).
 find -executable -type f ! -path '*:*' ! -path $'*\n*' \
-| file -N --mime-type -f - \
-| grep -P ".+(?=: (text/|application/javascript))" \
+| file -N --mime-encoding -f - \
+| grep -P ".+(?=: (?!binary$))" \
 | {
 fail=0
 while IFS= read -r line; do

                 reply	other threads:[~2026-09-03 11:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178843623867.1.17509760578128411903.rpms-redhat-rpm-config-9110aec0fba3@fedoraproject.org \
    --to=git-commits@fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox