Bug 1541318 - BRP mangle shebangs: fail hard if the shebang is invalid
Summary: BRP mangle shebangs: fail hard if the shebang is invalid
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1610014 1639270 1674073 1674074
Blocks: 1541057
TreeView+ depends on / blocked
 
Reported: 2018-02-02 09:36 UTC by Vít Ondruch
Modified: 2020-01-07 14:26 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-07 14:26:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vít Ondruch 2018-02-02 09:36:27 UTC
Description of problem:
rubygem-rack is broken by mangling shebangs [1]:

~~~
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
*** ERROR: ./usr/share/gems/gems/rack-2.0.3/test/cgi/test.ru has shebang which doesn't start with '/' (../../bin/rackup)
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.wS4P56 (%install)
    Bad exit status from /var/tmp/rpm-tmp.wS4P56 (%install)
~~~

And I think this line [2] makes sense for test suite. The question is, why really all shebangs are mangled? Why only the same set of shebangs as the set picked up by RPM dependency generators is not adjusted?

If that is not possible, how to skip one shebang? I know I can disable the brp script, but that is too big hammer IMO.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
RPM build fails due to "incorrect" shebang.


Expected results:
RPM build is passing and the offending file is ignored somehow.


Additional info:

[1] https://apps.fedoraproject.org/koschei/package/rubygem-rack?collection=f28
[2] https://github.com/rack/rack/blob/2.0.3/test/cgi/test.ru#L1

Comment 1 Igor Gnatenko 2018-02-02 09:40:08 UTC
Interesting idea. The problem is that brp's do not know anything about RPM, they are just shell scripts which know RPM_BUILD_ROOT and nothing else...

Comment 2 Pavel Raiskup 2018-02-02 09:44:23 UTC
> Why only the same set of shebangs as the set picked up by RPM dependency generators is not adjusted?

What's the set you talk about?  %buildroot/%_bindir?  That would make
sense to me.

Comment 3 Miro Hrončok 2018-02-02 09:49:36 UTC
Thanks for the report. For the time being disable the mangling as a workaround.

I'll get to this if nobody else does it, but not sooner than 2018-02-14 (vacation).

Comment 4 Panu Matilainen 2018-02-02 10:01:11 UTC
Yeah in a perfect (or at least better) world build root policies would run according to what's in the buildroot rather than static set of scripts that are always executed, since we already classify the contents anyway. But that's a longer term upstream RFE.

Comment 5 Miro Hrončok 2018-02-06 16:33:07 UTC
IMHO we need a general purpose path based opt-out, not some heuristic "is this going to be picked by the dependency generator", see bug 1542436.

Comment 6 Vít Ondruch 2018-02-07 09:03:37 UTC
(In reply to Miro Hrončok from comment #5)
> IMHO we need a general purpose path based opt-out, not some heuristic "is
> this going to be picked by the dependency generator", see bug 1542436.

Opt out is just remediation of the issue, but it should not mangle shebangs, which looks suspicious. Better to fail then provide incorrect result.

IOW, only the shebangs which match this pattern should be mangled /#![a-zA-Z\/]*env [a-zA-Z-]*/ (eventually, it can be even stricter) and for the rest of the cases, the script should just fail.

Comment 7 Vít Ondruch 2018-02-07 09:08:34 UTC
(In reply to Vít Ondruch from comment #6)
> /#![a-zA-Z\/]*env [a-zA-Z-]*/

Actually numbers should be accepted ...

Comment 8 Vít Ondruch 2018-02-08 08:42:14 UTC
Yet another reincarnation of similar issue:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RYN7K7EP6UFZNBE7ZUQ4EPVQU6GHRLJ6/

This should be resolved prior everybody disables the mangling.

Comment 9 Igor Gnatenko 2018-02-08 08:50:43 UTC
(In reply to Vít Ondruch from comment #8)
> Yet another reincarnation of similar issue:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> message/RYN7K7EP6UFZNBE7ZUQ4EPVQU6GHRLJ6/
> 
> This should be resolved prior everybody disables the mangling.

note that I've fixed that case

Comment 10 Igor Gnatenko 2018-02-08 08:58:17 UTC
So looking more into rubygem's failure...

#!./foo/bar depends on current directory, so we should really avoid packaging such files. Either there should be absolute path or executable bit should not be set.

`.` means current directory and not directory of the executable file.

Comment 11 Vít Ondruch 2018-02-08 09:13:35 UTC
(In reply to Igor Gnatenko from comment #9)
> note that I've fixed that case

Thx.

Anyway there is still this unmerged PR:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/16

If the PR gets merged (it should be merged, since it fixes bug), then there is going to be another cases of shebangs which should not be touched.

I think that the script should mange only shebangs it understands. It should not mangle the rest. Providing wrong shebangs is unacceptable. At the minimum, the script should not touch shebangs which does not match following RegExp:

~~~
^#![[:alnum:][:space:]./-]*$
~~~

Comment 12 Jan Horak 2018-02-14 10:38:59 UTC
How to disable or exclude .rs files from this exactly?
We're having problem with Firefox and rust source files, like this: 
https://searchfox.org/mozilla-central/source/third_party/rust/itertools/src/lib.rs

Rust use #![var] as C for #ifndef var:
https://doc.rust-lang.org/book/first-edition/documentation.html#doc-attributes

Comment 13 Igor Gnatenko 2018-02-14 11:09:03 UTC
(In reply to Jan Horak from comment #12)
> How to disable or exclude .rs files from this exactly?

chmod -x! And submit patch to upstream.

> We're having problem with Firefox and rust source files, like this: 
> https://searchfox.org/mozilla-central/source/third_party/rust/itertools/src/
> lib.rs
> 
> Rust use #![var] as C for #ifndef var:
> https://doc.rust-lang.org/book/first-edition/documentation.html#doc-
> attributes

Whatever it uses is not valid shebang and file must not be execurable.

Comment 14 Igor Gnatenko 2018-02-14 11:16:20 UTC
Also see https://github.com/bluss/rust-itertools/commit/c7ea0d52b75c459db8094d98737f631c020b004d for your particular case.

Comment 15 Jan Horak 2018-02-14 13:44:42 UTC
Hm, cool, but when your pull request will be merged:
1 - it will take some time before the third party lib gets updated in mozilla code base
2 - it will be pulled only to nightly branch
3 - it will take 12 weeks to get into stable

I'm I suppose to manually change perms or what?

Comment 16 Igor Gnatenko 2018-02-14 13:54:15 UTC
(In reply to Jan Horak from comment #15)
> Hm, cool, but when your pull request will be merged:

It's merged 3 months ago.

> I'm I suppose to manually change perms or what?

Yes.

Comment 17 Miro Hrončok 2018-02-15 10:34:24 UTC
JFYI: A packager can now exclude certain files and/or certain shebangs from the mangling: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/19

Jan Horak: Note that excluding the .rs file (or all of them) via the new macro is not a proper fix, proper fix is to chmod -x it.

As for the bug as it was reported: It's the "shebangs (not) picked up by dependency generators" documented somewhere, or should I just read the source? I always thought it picks them all, but apparently not.

If it only picks absolute paths, than I guess the proper fix is not to have relative shebangs at all, in my eyes a relative shebang is bogus.

As said in comment #10:
> #!./foo/bar depends on current directory, so we should really avoid
> packaging such files. Either there should be absolute path or executable bit
> should not be set.

Comment 18 Vít Ondruch 2018-02-15 10:59:48 UTC
Originally, I proposed to not mangle shebangs not picked up by RPM, but now I am worried about mangling shebangs like this [1] (@ignatenko and that is why I changed the subject):

~~~
#!/usr/bin/env <%= Bundler.settings[:shebang] || RbConfig::CONFIG["ruby_install_name"] %>
~~~

no matter where they are, the mangling should fail with such shebang, because it is apparently special case. I caught this specific issue just because there was bug in shebang mangling script [2].


[1] https://github.com/bundler/bundler/blob/master/lib/bundler/templates/Executable#L1
[2] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/16

Comment 19 Miro Hrončok 2018-02-15 11:39:21 UTC
What do you think by "should fail"? Don't mangle the shebang because it looks weird (has weird symbols in it, etc.), or fail hard because it looks weird?


My opinion:

That file is a template. I think templates with shebangs are "special enough" for the packager to take care of them. Either don't have it executable and the mangling script (and the dep generator) will ignore it or (if that's not possible) exclude it manually from the shebang mangling and the dep generator.


Technically this shebang **is** picked up by the generator (if executable), it's just that only the part before the first space is used as a dependency.


I see a benefit in failing hard if the the shebang is illegal. It would make the packager care.

Comment 20 Igor Gnatenko 2018-02-15 11:48:15 UTC
> I see a benefit in failing hard if the the shebang is illegal. It would make the packager care.

This makes a lot of sense for me. So packager would need to decide what to do with that.

Comment 21 Vít Ondruch 2018-02-16 09:54:13 UTC
(In reply to Miro Hrončok from comment #19)
> What do you think by "should fail"? Don't mangle the shebang because it
> looks weird (has weird symbols in it, etc.), or fail hard because it looks
> weird?

Fail hard and let packager to decide.

Comment 22 Fedora End Of Life 2018-02-20 15:39:41 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 23 Jason Tibbitts 2018-03-05 21:21:25 UTC
I just wanted to note this _somewhere_: It is valid for an executable to have no shebang line; the kernel just passes it to /bin/sh.  So removing the executable bits in that case can actually be problematic.  I found some instances of that breakage in a package review and it turns out that the following does disable the "empty shebang" check:

%global __brp_mangle_shebangs_exclude ^$

But that may be purely by accident.

For background, I found that "implicit /bin/sh" bit used in the texlive sources, where this absolutely hideous construct is used to make a shell script which is both valid sh and perl:

eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' && eval 'exec perl -S $0 $argv:q'
  if 0;

(the "if 0;" is on a separate line).  I imagine there are other uses of that in old code floating around which could be broken by our current shebang mangling.  Whether we would actively try to get rid of terrible crap like that in the distribution is a separate discussion.  It appears to be as bad as env for both security and reliability.

Comment 24 Miro Hrončok 2018-03-05 21:48:50 UTC
I don't want to live on this planet anymore.

Comment 25 Miro Hrončok 2018-03-05 21:57:17 UTC
This also works with empty shebang:

$ ./test
disgusting

$ cat test
#!
echo disgusting

Comment 26 Florian Weimer 2018-03-06 06:54:07 UTC
(In reply to Jason Tibbitts from comment #23)
> I just wanted to note this _somewhere_: It is valid for an executable to
> have no shebang line; the kernel just passes it to /bin/sh.

That's not actually true:

strace /bin/mptopdf 
execve("/bin/mptopdf", ["/bin/mptopdf"], 0x7fff555ea3f0 /* 71 vars */) = -1 ENOEXEC (Exec format error)

The shell does it, and older versions of posix_spawn.  It's also what makes the empty shebang case work.

Comment 27 Miro Hrončok 2018-04-19 14:24:01 UTC
I need a "valid shebeng" definition. Until then, I cannot implement this. Is there a POSIX spec or something like that?

Comment 28 Vít Ondruch 2018-04-19 15:02:24 UTC
(In reply to Miro Hrončok from comment #27)
Looking for "valid shebang" definition is wrong. You should look at the problem in a way of "If I mangle the shebang, I know the result is correct". And if you don't recognize the format, the mangling should fail. This way would avoid broken shebangs.

Comment 29 Miro Hrončok 2018-04-19 16:52:57 UTC
I still don't know how to "know the result is correct".

Comment 30 Jason Tibbitts 2018-04-19 17:23:46 UTC
All we have is syntax, existing policy and good sense.  What you can't know in the context of a brp_* script running at the end of the %install is something like whether the path is actually valid.

Comment 31 Vít Ondruch 2018-04-20 07:42:56 UTC
You know that if there is "#!/usr/bin/env python" shebang and you change it to "#!/usr/bin/python" that the result is correct. So change just this shebang and fail for others. If I later come and complain that you are failing, because there is "#!/usr/bin/env ruby" shebang, then add it to list of known shebangs to mangle.

Or in comment 11, I proposed the RedExp which should match shebangs we know, understand and believe they are correct. If there is some shebang which does not match this RegExp and the mangling script fails with it, then you can special case it, because I am pretty sure people will let you know.

Honestly if you claim that you don't know what is the "valid shebang", then mangling everything is quite bold IMO. It just means that the script corrupts shebangs and we have no chance to know that.

Comment 32 Vít Ondruch 2018-04-20 07:44:25 UTC
May be I should change the subject once more to "fail hard if the shebang format is not recognized".

Comment 33 Miro Hrončok 2018-04-20 09:44:29 UTC
^#![[:alnum:][:space:]./-]*$

What I also believe is totally ok in shebang:

Totally:
_
+
,


Theoretically:

€
💩
…

Comment 34 Vít Ondruch 2018-04-20 10:01:52 UTC
Do you have any examples in hand?

Comment 35 Miro Hrončok 2018-04-20 10:50:33 UTC
Real world examples? No. But I can make it work:

[shebangs]$ cat > 💩 << EOF
> #!/usr/bin/sh
> echo 💩💩💩
> EOF
[shebangs]$ cat > script << EOF
> #! /home/churchyard/tmp/shebangs/💩
> watch this
> EOF
[shebangs]$ chmod +x 💩
[shebangs]$ chmod +x  script 
[shebangs]$ ./script 
💩💩💩


Valid shebang.

Comment 36 Miro Hrončok 2018-04-20 10:52:11 UTC
note that I'm not so concerned about emoji in shebangs, but there are more normal characters (like _) that were not in the regex. Such regex is too strict.

maybe blacklist (instead of whitelisting) special characters for shell?

Comment 37 Petr Viktorin (pviktori) 2018-10-01 12:43:14 UTC
We can't fix this unless we have an exact definition of a valid shebang.
Please re-open if you know of one.

Comment 38 Vít Ondruch 2018-10-10 15:24:20 UTC
Sorry, but your resolution is contradicting IMO. Although you admit you don't know what the definition of valid shebang is, you don't mind changing all shebangs.

What I am saying is that if we don't know what the shebang definition is, we should be careful and mangle just shebangs we know we can safely mangle and error out for the rest, collecting more knowledge about shebangs and slowly relax the rules.

Honestly, I am fine if shebang like "#! /home/churchyard/tmp/shebangs/💩" is not handled ATM. The mangling can be disabled for this case or the algorithm might be gradually extended if this is proved to be widely used practice.

Comment 39 Miro Hrončok 2018-10-10 16:00:43 UTC
So the request in fact is: Don't mangle shebangs you don't understand?

Comment 40 Vít Ondruch 2018-10-11 05:23:43 UTC
(In reply to Miro Hrončok from comment #39)
> So the request in fact is: Don't mangle shebangs you don't understand?

Yes (or better "Mangle only shebangs you are sure you understand") and it has been since comment 11 or comment 16, when the original subject was updated when it was clear that the mangling script corrupts some shebangs.

Comment 41 Miro Hrončok 2018-10-11 07:02:14 UTC
In comment 21 you say:

> Fail hard and let packager to decide.

Is that still valid? So In fact you ask to:

"Mangle only shebangs you are sure you understand, fail hard on others"

Based on this we are sure rendering all packages with shebangs we don't understand FTBFS just because we don't understand something. Is that desired?

Comment 42 Vít Ondruch 2018-10-11 08:41:08 UTC
What is not desired is to ship packages with broken shebangs to our users. It is reasonable OK to fail a build if the output of mangling is uncertain.

Actually, if you did some review/analysis of shebangs after the last mass rebuild, e.g. how many shebangs were mangled and if the results are as expected, you might convince me that the mangling is reasonably ok. But I am afraid you don't have such numbers.

Comment 43 Miro Hrončok 2018-10-11 10:12:58 UTC
Working on it. Will get some numbers.

Comment 44 Miro Hrončok 2018-10-15 11:27:25 UTC
Here are some rough stats:  https://gist.github.com/hroncok/d153305d1386648b8ae5921953c7d0ec

Most interesting/weird things I see:

shebnags/nodejs-yarn-1.9.2-1.fc29.src.rpm.log:mangling shebang in /usr/lib/node_modules/yarn/node_modules/performance-now/test/scripts/difference.coffee from /usr/bin/env ./node_modules/.bin/coffee to #!/usr/bin/./node_modules/.bin/coffee
...


shebnags/contextkit-0.5.41-18.fc29.src.rpm.log:mangling shebang in /usr/bin/context-rlwrap from /usr/bin/env python2.5 to #!/usr/bin/python2.5

Comment 45 Vít Ondruch 2018-10-15 11:51:53 UTC
(In reply to Miro Hrončok from comment #44)
> Here are some rough stats: 
> https://gist.github.com/hroncok/d153305d1386648b8ae5921953c7d0ec

Not sure I understand how you get the output nor that I understand its content, but the two cases are indeed interesting. And also others such as:

~~~
" (('/usr/bin/env gpaw-python', '/usr/bin/gpaw-python'), 2),\n",
~~~

Because package with shebang like this has now broken dependency and is not installable because gpaw-python is not available on Fedora. That is presumably similar to the "python2.5" case.

Comment 46 Miro Hrončok 2018-10-15 12:35:49 UTC
The output is from all build logs of all packages in rawhide (latest successful build).

The broken dependency on gpaw-python thing just uncovers a bug in the package.
The file does not work without gpaw-python.

shebnags/gpaw-1.4.0-6.fc29.src.rpm.log:mangling shebang in /usr/bin/gpaw-runscript3 from /usr/bin/env gpaw-python to #!/usr/bin/gpaw-python
shebnags/gpaw-1.4.0-6.fc29.src.rpm.log:mangling shebang in /usr/bin/gpaw-runscript from /usr/bin/env gpaw-python to #!/usr/bin/gpaw-python

$ dnf repoquery --repo=rawhide --whatrequires /usr/bin/gpaw-python
python2-gpaw-0:1.4.0-6.fc29.x86_64
python3-gpaw-0:1.4.0-6.fc29.x86_64

$ dnf repoquery --repo=rawhide -f /usr/bin/gpaw-python
(nope)

I'll report that.

Comment 47 Miro Hrončok 2018-10-15 12:41:57 UTC
bz1639270

Comment 48 Miro Hrončok 2018-10-15 12:47:34 UTC
I'll go trough all the mangled shebnags and make sure we have those files in Fedora, file bugz otherwise.

Comment 49 Miro Hrončok 2019-02-08 23:57:36 UTC
From the list, the following shebangs are not listed/provided by any package:

/usr/bin/gpaw-python bz1639270
/usr/bin/./node_modules/.bin/coffee bz1674073
/usr/bin/perl6-j bz1674074
/bin/python (the script was fixed since not to do this) vdsm and fmtools will be fixed once rebuilt (they FTBFS)
/usr/bin/python2.5 bz1610014
/bin/ruby (the script was fixed since not to do this) no packages require this

Comment 50 Petr Viktorin (pviktori) 2019-03-05 14:41:08 UTC
We should fail hard in the case of relative path after /usr/bin/env (which gets mangled to /usr/bin/./…).
The other instances in Fedora are actual errors, uncovered by the mangling.

Comment 51 Japheth Cleaver 2019-03-21 21:14:14 UTC
I have a delta here between F28 and F29 in regards to the dash shell. In F28, #!/bin/dash was left untouched, but in F29 it's mangled:
> mangling shebang in /usr/bin/testdash.sh from /bin/dash to #!/usr/bin/dash

[root@f29 rpmbuild]# dnf localinstall /home/rpmbuild/rpm/RPMS/x86_64/testdash-1-1.fc29.x86_64.rpm
Error: 
 Problem: conflicting requests
  - nothing provides /usr/bin/dash needed by testdash-1-1.fc29.x86_64
(try to add '--skip-broken' to skip uninstallable packages)


The dash package is identical between F28 and F29, but since DNF doesn't know how to translate /bin/dash to /usr/bin/dash, it fails on F29.

I feel like this belongs here, but I can make a new BZ as well.


[rpmbuild@f28 SPECS]$ rpm -q --requires /home/rpmbuild/rpm/RPMS/x86_64/testdash-1-1.fc28.x86_64.rpm
/bin/dash
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

[rpmbuild@f29 SPECS]$ rpm -q --requires /home/rpmbuild/rpm/RPMS/x86_64/testdash-1-1.fc29.x86_64.rpm
/usr/bin/dash
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1



[root@f28 x86_64]# rpm -q --provides dash
dash = 0.5.10.2-1.fc28
dash(x86-64) = 0.5.10.2-1.fc28
[root@f28 x86_64]# rpm -ql dash
/bin/dash
/usr/lib/.build-id
/usr/lib/.build-id/04
/usr/lib/.build-id/04/d1cfdf53fbe4ac4f8c24fc6cdda3f4be92332b
/usr/share/doc/dash
/usr/share/doc/dash/COPYING
/usr/share/doc/dash/ChangeLog
/usr/share/man/man1/dash.1.gz

[root@f29 rpmbuild]# rpm -q --provides dash
dash = 0.5.10.2-1.fc29
dash(x86-64) = 0.5.10.2-1.fc29
[root@f29 rpmbuild]# rpm -ql dash
/bin/dash
/usr/lib/.build-id
/usr/lib/.build-id/98
/usr/lib/.build-id/98/3fd81a08dcd44aba92345e39957bc711257995
/usr/share/doc/dash
/usr/share/doc/dash/COPYING
/usr/share/doc/dash/ChangeLog
/usr/share/man/man1/dash.1.gz

Comment 52 Miro Hrončok 2019-03-22 13:26:34 UTC
Please file a bugzilla for dash. They manually install to /bin instead of /usr/bin - they should not do that:

   %configure --bindir=/bin

Thanks.

Comment 53 Japheth Cleaver 2019-03-22 15:31:37 UTC
(In reply to Miro Hrončok from comment #52)
> Please file a bugzilla for dash. They manually install to /bin instead of
> /usr/bin - they should not do that:
> 
>    %configure --bindir=/bin
> 
> Thanks.

Thanks. BZ #1691825

Comment 54 Ben Cotton 2019-05-02 19:21:12 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 55 Ben Cotton 2019-05-02 19:43:43 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 56 Ben Cotton 2019-10-31 19:02:47 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 57 Vít Ondruch 2019-11-01 11:48:03 UTC
I don't think this was resolved.

Comment 58 Miro Hrončok 2019-11-01 12:00:09 UTC
It wasn't however I am not sure what would be the best way to handle this.

Comment 59 Petr Viktorin (pviktori) 2020-01-07 14:26:50 UTC
Since we know no good definition of "invalid shebang", we can't fail hard for invalid shebangs.

This means the bug is not resolved, but also that at this point we can't do anything more to help fix it.
Please re-open if you disagree.


Note You need to log in before you can comment on or make changes to this bug.