Remove hardcoded list of supported Fedora CI tests

[betulependule]

Fixes #3038

[centosinfra-prod-github-app]

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/fdce0683b13640faa14b8c4097528b13

✔️ pre-commit SUCCESS in 1m 50s
✔️ packit-service-tests SUCCESS in 3m 33s

[gemini-code-assist]

Code Review

This pull request refactors the parsing of PR comments to dynamically fetch the list of supported Fedora CI tests, moving the parse_comment function into the SteveJobs class for better access to instance-specific data. While the refactoring improves flexibility, a critical security vulnerability exists: the modified is_packit_config_present function continues to use flawed logic that trusts issue descriptions for configuration, which could lead to malicious configuration injection and potential RCE. Additionally, a minor code quality issue was noted due to a missing docstring, violating the repository's style guide.

[gemini-code-assist]

The is_packit_config_present method (modified in this PR) relies on search_distgit_config_in_issue to extract a dist-git URL and package configuration from the description of the issue associated with the event. Since issue descriptions are user-controlled, an attacker can craft a malicious issue description that points to a repository they control. If a maintainer or an allowlisted user is tricked into commenting on this issue, Packit will load and use the attacker's malicious packit.yaml configuration. This can lead to Remote Code Execution (RCE) on the Packit worker if the malicious configuration defines arbitrary actions (e.g., post-upstream-clone).

Remediation:
Verify that the issue was created by a trusted account (e.g., the Packit bot itself) before trusting its description. Alternatively, avoid loading configuration from issue descriptions and instead use a more secure way to store and retrieve failure context.

[gemini-code-assist]

According to the repository's style guide (lines 412-414), all non-trivial functions should have a docstring. Please add a docstring to get_pr_comment_parser_fedora_ci explaining its purpose, arguments, and what it returns.

    """Create a parser for the Fedora CI PR comment.

    Args:
        prog: The name of the program.
        description: The program description.
        epilog: Text to display after the argument help.
        supported_test_types: A list of supported test types.

    Returns:
        An argument parser for Fedora CI PR comments.
    """
    parser = _create_base_parser(prog, description, epilog)

References

1. With exception of trivial cases, all code must contain accurate and sufficiently detailed docstrings, formatted with accordance with the PEP 257 standard and in Google-style. ^(link)

[nforro]

Wouldn't some feedback be nice? Implementing a response comment should be simple, we already provide feedback for accepted retrigger tasks:

packit-service/packit_service/worker/jobs.py

Line 1339 in 1d3ed53

self.event.pull_request_object.comment(message)

We could either forward the error from the SystemExit exception or use parser.parse_known_args() and report unknown arguments.

[betulependule]

Yes, it would definitely be ideal to respond in a comment when this kind of error occurs. Should I open a new PR regarding this?

[nforro]

Yes please 🙏

[nforro]

Nice! It would be great if this also considered the filters (in the tests namespace there is only the custom check available; or no check if there is no fmf metadata in the project):

packit-service/packit_service/worker/handlers/testing_farm.py

Lines 558 to 560 in 1d3ed53

	@classmethod
	def filter_ci_tests(cls, tests: list[str]) -> list[str]:
	return [t for t in tests if t == "custom"]

However I'm not sure how to elegantly implement this. It would probably require implementing the filtering in a different way.

[betulependule]

Nice! It would be great if this also considered the filters (in the tests namespace there is only the custom check available; or no check if there is no fmf metadata in the project):

I will take a look and see if I can think of a good way to implement this. Thanks. 🙏