Skip to content

[stable35] refactor(jsignpdf): move the hash algorithm resolution to a dedicated class - #8282

Merged
vitormattos merged 2 commits into
stable35from
backport/8275/stable35
Sep 6, 2026
Merged

[stable35] refactor(jsignpdf): move the hash algorithm resolution to a dedicated class#8282
vitormattos merged 2 commits into
stable35from
backport/8275/stable35

Conversation

@backportbot-libresign

Copy link
Copy Markdown

Backport of PR #8275

… class

The hash algorithm that signs a document depends on the PDF version, so it
is not a valid answer for the other hashes JSignPdf takes: reusing it would
send SHA1 to a timestamp authority whenever the document is older than PDF
1.6. Issue #8145 asks for each hash to be resolved on its own, which is hard
to guarantee while the rules live inside the handler as private methods.

Move getHashAlgorithm(), getHashAlgorithmForPdfVersion(),
validateHashAlgorithm() and requiresPdfVersionUpgradeForSha256() to
HashAlgorithmResolver, where each hash gets its own entry point and can be
tested in isolation. The handler keeps reading the PDF version, the only
part that is about the document and not about the policy.

No behavior change: the same version thresholds, the same fallback to
SHA256 and the same supported algorithms.

Signed-off-by: André Maia <andrefnkmm@gmail.com>
Assisted-by: Claude Code:claude-opus-5
Both the handler and the resolver carry rules that only make sense for
JSignPdf — the PDF version thresholds come from its own HashAlgorithm enum —
so they move to SignEngine/JSignPdf/ and the resolver keeps a name that does
not need to repeat the engine.

Pkcs12Handler used to build the handler class name at runtime from the
configured engine ('...\SignEngine\' . ucfirst($property)), a string no
static analysis, IDE rename or grep could follow: moving the class would
only fail when a document was signed. It now resolves through an explicit
map, so a name that is not an engine answers the same friendly error instead
of reaching the container.

Signed-off-by: André Maia <andrefnkmm@gmail.com>
Assisted-by: Claude Code:claude-opus-5
@github-project-automation github-project-automation Bot moved this to 0. Backlog in Roadmap Sep 6, 2026
@backportbot-libresign backportbot-libresign Bot added this to the Next Major (35) milestone Sep 6, 2026
@vitormattos
vitormattos merged commit ef399a9 into stable35 Sep 6, 2026
65 checks passed
@vitormattos
vitormattos deleted the backport/8275/stable35 branch September 6, 2026 17:12
@github-project-automation github-project-automation Bot moved this from 0. Backlog to 4. to release in Roadmap Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: 4. to release

Development

Successfully merging this pull request may close these issues.

2 participants