Hook configuration through filenames

[jozseffenyes]

Allow hooks to run under different filenames set in app.ini

Resolves #30985

[wxiaoguang]

TBH I am not sure whether this change is necessary or safe enough.

By design, the git hooks must be managed by Gitea, otherwise there might be "access bypass" if the hooks are wrong.

And, the current "hook" script looks like this, it already has the ability to run anything in hooks directory like {my-script}.{ext}.

[jozseffenyes]

TBH I am not sure whether this change is necessary or safe enough.

By design, the git hooks must be managed by Gitea, otherwise there might be "access bypass" if the hooks are wrong.

And, the current "hook" script looks like this, it already has the ability to run anything in hooks directory like {my-script}.{ext}.

Thank you for your input. This capability remains necessary for our organization, as we need to modify our scripts directly from the frontend. Changing the file extension from the bash script does not make it available through the UI. We understand the risks involved but have determined that this approach is safe enough.

[wxiaoguang]

Since the script is executed by git bash, so I would suppose you could use shebang line directly for your PowerShell scripts without extension?

https://stackoverflow.com/questions/48216173/how-can-i-use-a-shebang-in-a-powershell-script

[jozseffenyes]

Since the script is executed by git bash, so I would suppose you could use shebang line directly for your PowerShell scripts without extension?

https://stackoverflow.com/questions/48216173/how-can-i-use-a-shebang-in-a-powershell-script

Sadly this approach doesn't work anymore on windows since Powershell's 7.2 release.
PowerShell/PowerShell#16480

[wxiaoguang]

Hmm, it seems to be a bad design from PowerShell side.

I think we should still do the best to follow the posix-standard / shebangline, instead of introducing too many options or workarounds, since it isn't a widely-requested feature -- until there are many end users need such "customized hook extension name".

---

For your case, I think it could be resolved by some of these approaches:

1. use the -Command argument, like this:

#!/usr/bin/env bash
PWCODE=$(cat <<'CODEBLOCK'

Write-Host "the powershell script"

CODEBLOCK
)
# or, use EncodedCommand (base64)
exec powershell -Command "$PWCODE"

2. use a pwsh-wrapper.sh, like this:

#!/usr/bin/env bash
fn="$1"
shift
# it could be fine-tuned by "flock" or writing to a tmp directory
cp "$fn" ".$fn.ps1"
exec powershell -File ".$fn.ps1" "$@"

Then use it as your hook script's shebang line:

#!/usr/bin/env pwsh-wrapper.sh
Write-Host "the powershell script"

[silverwind]

There is already a very similar function in routers/api/packages/generic/generic.go:65, move it to modules/util and share from there.

[silverwind]

Suggested change

[silverwind]

Suggested change

[silverwind]

Suggested change

[wxiaoguang]

Thanks to the author's work and thanks to reviewers' suggestions.

However, I think this change is not good enough and I do not think it could be merged.

1. The root problem is the bad design from PowerShell side (it strictly requires "ps1" ext name and no way to bypass)
2. There could be some workarounds without introducing the "customized file name" (Hook configuration through filenames #31058 (comment))
3. The "customized file name" feature is not a widely-requested feature, and it makes the system unnecessarily complex and brings some maintainability problems:
   • For example, if an end user had some content in the default hook file, and then changed the hook file name, then the old hook file is left there forever and unmanageable, it would cause more problems.

So I will put a "blocked" label, and leave the final decision to the @go-gitea/technical-oversight-committee

[wxiaoguang]

#31058 (comment)