ci(actions): adjust workflow triggers

[beiertu-mms]

Add the pull_request_target trigger, so that pull requests from a
fork will also start a build. Otherwise they can't be verified.

A downside to this is that changes to the CI workflow can't be directly
verified on a pull request anymore without some workarounds, because
the CI will now run in the context of the base of the pull request.

Closes #378.

See also:

• https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target

[technolinator-sbom-as-a-service]

⚠ Vulnerability Report

Please consider this as a tentative appraisal, consult Dependency-Track for reliable results.

Artifact	Vulnerability	Severity (CVSS v3)	Recommendation
pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70?type=jar	CVE-2023-33201 # Bouncy Castle For Java LDAP injection vulnerability Bouncy Castle provides the X509LDAPCertStoreSpi.java class which can be used in conjunction with the CertPath API for validating certificate paths. Pre-1.73 the implementation did not check the X.500 name of any certificate, subject, or issuer being passed in for LDAP wild cards, meaning the presence of a wild car may lead to Information Disclosure. A potential attack would be to generate a self-signed certificate with a subject name that contains special characters, e.g: CN=Subject*)(objectclass=. This will be included into the filter and provides the attacker ability to specify additional attributes in the search query. This can be exploited as a blind LDAP injection: an attacker can enumerate valid attribute values using the boolean blind injection technique. The exploitation depends on the structure of the target LDAP directory, as well as what kind of errors are exposed to the user. Changes to the X509LDAPCertStoreSpi.java class add the additional checking of any X.500 name used to correctly escape wild card characters.	🟡 Medium (5.3)
pkg:maven/net.minidev/json-smart@2.4.7?type=jar	CVE-2023-1370 # json-smart Uncontrolled Recursion vulnerabilty ### Impact Affected versions of net.minidev:json-smart are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. ### Patches This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. ### Workarounds N/A ### References - https://www.cve.org/CVERecord?id=CVE-2023-1370 - https://nvd.nist.gov/vuln/detail/CVE-2023-1370 - https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748	🟠 High (7.5)	Update to 2.4.9 or later

[beiertu-mms]

@heubeck or maybe it's better to have a separate workflow, which will "just" do maven test and docker build/verify for PRs from forks?

[emil-wire]

@heubeck or maybe it's better to have a separate workflow, which will "just" do maven test and docker build/verify for PRs from forks?

could also make sense to split the workflow into pieces and pick and choose which ones should run where

[heubeck]

Which parts of the workflow would you skip for fork-based runs?
Don't see a reason for not executing the full workflow.