Allow custom JCE provider in PKFileBasedSigningUtil for HSM / remote signing support

[axos88]

trafficstars

Currently, PKFileBasedSigningUtil is marked as final and hardcodes the use of the BouncyCastle (BC) provider. This design restricts the ability to use alternative JCE providers, which is a significant limitation in environments that require Hardware Security Module (HSM) integration or remote signing.

Use case: We're integrating pass signing into a system where private keys are managed by an HSM through a custom JCE provider. Due to the hardcoded "BC" provider in PKFileBasedSigningUtil, we cannot use our setup as-is. Additionally, because the class is marked final, we cannot extend it to override this behavior.

Current workaround (not ideal): As a workaround, we’ve been forced to copy-paste the entire PKFileBasedSigningUtil implementation and override the signManifestUsingContent method in the abstract superclass. This involves duplicating code just to remove the hardcoded provider, which is brittle and difficult to maintain across library upgrades.

Suggestions (any of the following would help):

Allow a custom java.security.Provider to be supplied (e.g., via constructor or setter), defaulting to BC if none is provided.

Use the default provider if none is explicitly specified (e.g., via Signature.getInstance(algorithm) instead of Signature.getInstance(algorithm, "BC")).

Remove the final modifier from PKFileBasedSigningUtil to allow power users to extend the class and override behavior as needed.

This small change would enable much broader compatibility with enterprise-grade security setups, while preserving full backward compatibility for existing users.

Happy to provide a PR for any of the above if it would help.