Harden GitHub workflows and SMTP STARTTLS trust

[vharseko]

Summary

Closes 30 of the 31 open medium CodeQL alerts: the 29 GitHub Actions findings and java/insecure-smtp-ssl #22. The remaining one (#4, ResourceServlet redirect) touches a file that #202 is already changing and will follow once that PR lands.

GitHub Actions

actions/missing-workflow-permissions (#711–#716, #920, #921) — every workflow now starts from permissions: contents: read; only the jobs that actually use the token get more, each with an inline comment saying why:

Job	Permissions	Reason
build.yml (all jobs)	contents: read	artifacts and the local registry:2 service need nothing else
deploy.yml / deploy-maven	contents: write	pushes the generated docs to the repository wiki with github.token (the doc-site push uses a PAT)
release.yml / release-maven	contents: write	release:prepare pushes the release tag, action-gh-release creates the release, docs go to the wiki
release.yml / release-docker*	contents: read, packages: write	GHCR login with GITHUB_TOKEN

actions/unpinned-tag (#718–#738) — the six third-party actions are pinned to commit SHAs, with the resolved version kept as a comment:

docker/metadata-action v6.2.0 · docker/setup-qemu-action v4.4.0 · docker/setup-buildx-action v4.4.1 · docker/build-push-action v7.4.0 · docker/login-action v4.6.0 · softprops/action-gh-release v3.0.3

actions/* and github/* are not covered by the rule and stay on major tags.

Second commit adds .github/dependabot.yml (ported from OpenIdentityPlatform/OpenIG#170) with the github-actions ecosystem, grouped into one weekly PR, so the pinned SHAs stay current. All six pins above were verified against the actions' latest releases at the time of writing and are already up to date.

#22 — EmailClient trusted every SMTP certificate over STARTTLS

The "temporary hack to avoid cert check" installed a MailSSLSocketFactory with setTrustAllHosts(true) whenever starttls.enable was set, so the TLS upgrade gave no protection against an on-path attacker. Certificate validation against the JVM trust store is now the default. Two optional settings relax it (documented in the integrator's guide):

"starttls" : {
    "enable" : true,
    "trustedHosts" : [ "smtp.internal.example.com" ],   // accepted without validation
    "trustAll" : false                                   // dev only; logs a warning when true
}

Behaviour change: deployments that use STARTTLS against an SMTP server with a self-signed or otherwise untrusted certificate will fail to send mail until they either add the certificate to the JVM trust store or set trustedHosts / trustAll.

Test plan

• New EmailClientTest (4): default → no custom socket factory; trustAll → trust-all factory; trustedHosts → limited factory; no STARTTLS → nothing configured. Two cases failed before the change.
• openidm-external-email suite green (9/9)
• Workflow YAML parses; permission layout verified per job
• CodeQL on this PR closes #711–#716, #718–#738, #920, #921, [#10 #14] FIX openidm (object) is not defined (rhino export global context) #22
• Next release run confirms contents: write / packages: write are sufficient (the token had full default permissions before)