chore: make greetings on PR First-time Contrib

[ddevsr]

Description
Ref codeigniter4/CodeIgniter4#8878.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[paulbalandan]

really need to run on pull_requedt_target not pull_request only?

[kenjis]

TL;DR: Combining pull_request_target workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.

Any automated processing of PRs from an external fork is potentially dangerous and such PRs should be treated like untrusted input.

https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

pull_requedt_target should not be used for security reasons.

[kenjis]

By Claude 3 Sonnet.

Q: We are running an open source project on GitHub and using GitHub Actions for all pull requests. What are the security considerations when using pull_requedt_target in workflows?

When using the pull_request_target event in GitHub Actions workflows, there are some important security considerations to keep in mind:

1. Untrusted Code: The pull_request_target event runs the workflow code from the pull request's head commit, which means it executes code from an untrusted source. This code could potentially be malicious, so it's crucial to ensure that your workflow doesn't perform any sensitive operations or expose any secrets.

2. Code Injection: If your workflow includes steps that allow user input or use external data sources, there's a risk of code injection attacks. Malicious code could be injected into your workflow, leading to unintended actions or data leaks.

3. Permissions: By default, the pull_request_target event runs with read-only permissions to the repository. However, if your workflow requires write access, you'll need to grant the GITHUB_TOKEN permissions explicitly. This introduces a potential risk if the workflow is compromised, as it could then make unauthorized changes to your repository.

4. Secrets Exposure: If your workflow uses secrets (e.g., API keys, passwords), they could potentially be exposed to the untrusted code in the pull request. It's recommended to avoid using secrets in workflows triggered by the pull_request_target event, or at least limit their usage to read-only operations.

5. Resource Exhaustion: Malicious pull requests could attempt to overwhelm your system resources (e.g., CPU, memory, disk space) by running resource-intensive operations in the workflow. It's important to set reasonable limits and monitor resource usage.

To mitigate these risks, consider the following best practices:

1. Validate Inputs: Sanitize and validate all inputs and data sources used in your workflow to prevent code injection attacks.
2. Minimize Permissions: Grant the minimum required permissions to the GITHUB_TOKEN or use a custom token with limited scope.
3. Avoid Secrets: If possible, avoid using secrets in workflows triggered by the pull_request_target event. If you must use secrets, ensure they are only used for read-only operations.
4. Resource Limits: Set appropriate resource limits for your workflows to prevent resource exhaustion attacks.
5. Code Review: Thoroughly review the code in pull requests before merging, especially if the workflow performs sensitive operations.
6. Monitoring and Logging: Implement monitoring and logging mechanisms to detect and respond to potential security incidents or misuse.
7. Security Updates: Keep your GitHub Actions environment and dependencies up-to-date with the latest security patches and updates.

By following these best practices, you can mitigate the risks associated with running untrusted code in your GitHub Actions workflows and maintain a secure environment for your open-source project.