Bug: `mkiocccentry` does not ignore executable files.

[SirWumpus]

Is there an existing issue for this?

• [x] I have searched for existing issues and did not find anything like this

Describe the bug

mkiocccentry does not ignore executable files (other than prog), it assumes a clean or clobbered directory, when creating the submission tarball.

elf$ file xyzzy
xyzzy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 10.1, with debug_info, not stripped

What you expect

mkiocccentry should ignore executable binary files that could pose security issues.

Care should be taken with any executable scripts (.sh, .py, .pl, .awk, etc.), for security they should probably clear their executable bits (chmod a-x foo.sh).

Environment

• OS:
• Device:
• Compiler:

bug_report.sh output

No response

Anything else?

No response

[lcn2]

The mkiocccentry(1) tool (and related tool "friends" in the tool set) do not ignore executable files.

Shell scripts, are just one example. Who knows what other fun folks might wish to include as executables?

Yes, someone who leaves behind a foo executable binary and packages it might be making a mildly annoying mistake. Nevertheless there is a limit to how much "hand holding" (as the expression goes) that the mkiocccentry(1) tool (and related tool "friends" in the tool set) should do.

The mkiocccentry(1) tool does present the submitted when a list of files that will be included that, by default, they also asked to confirm. Moreover, the directory left under workdir/ is left behind for them to inspect. Finally they can use tar(1) to inspect the compressed tarball prior to submitting. If also all that they leave behind an executable, so be it.

Should the mkiocccentry(1) tool explicitly ignore executable files? Probably not. There may be valid reasons to include them (such as scripts).

Moreover, while IOCCC28 is open we would NOT want to make such a tool change given that there may already be submissions that supplies executables, knowingly or not.

As a result, @SirWumpus, we do not consider this issue a bug 🐞.

[lcn2]

Thanks, @SirWumpus, for raising this potential concern. Nevertheless, as IOCCC Judges, we already take significant precautions in judging that account for executables.

[xexyl]

The mkiocccentry(1) tool (and related tool "friends" in the tool set) do not ignore executable files.

Shell scripts, are just one example. Who knows what other fun folks might wish to include as executables?

Yes, someone who leaves behind a foo executable binary and packages it might be making a mildly annoying mistake. Nevertheless there is a limit to how much "hand holding" (as the expression goes) that the mkiocccentry(1) tool (and related tool "friends" in the tool set) should do.

The mkiocccentry(1) tool does present the submitted when a list of files that will be included that, by default, they also asked to confirm. Moreover, the directory left under workdir/ is left behind for them to inspect. Finally they can use tar(1) to inspect the compressed tarball prior to submitting. If also all that they leave behind an executable, so be it.

Should the mkiocccentry(1) tool explicitly ignore executable files? Probably not. There may be valid reasons to include them (such as scripts).

Moreover, while IOCCC28 is open we would NOT want to make such a tool change given that there may already be submissions that supplies executables, knowingly or not.

As a result, @SirWumpus, we do not consider this issue a bug 🐞.

In addition to this: it explicitly copies them as 0444 UNLESS they are try.sh or try.alt.sh. No other files can be +x or it'll be flagged. So even if it's an executable file as such it doesn't mean it would be executable in the submission.

Additionally what if someone accidentally has +x on their remarks.md or something like that ?