fastmail / mail-dkim

Mail::DKIM Perl module, forked from svn://svn.code.sf.net/p/dkimproxy/code/Mail-DKIM/trunk
8 stars 6 forks source link

Signer: Fix loading of per-signature private keys with different types #36

Open dev-aaront-org opened 4 days ago

dev-aaront-org commented 4 days ago

If a Signature object's Key or KeyFile property is set to a non-ref, Signer assumes it is a file path and attempts to load the private key from it, but it may use the wrong key type, which will cause the signature to fail. Currently Signer looks at $self->{Algorithm} to determine the key type, and this changes it to look at the Signature's algorithm instead.

I'm not entirely sure this fix is right or necessary because it doesn't really look like a supported use case. The docs for Signature say that Key should be an object, and KeyFile is not used at all within Signature. So I was also considering just removing the key loading from Signer and making it the user's responsibility to load their own keys if they're creating their own Signatures. But that would be a backward-incompatible change.

Anyway, I'm certainly open to suggestions if you prefer a different fix.

dev-aaront-org commented 1 day ago

I was thinking about this some more and I realized that my fix enabled some nonsense scenarios where the key file could come from Signer but the key type from Signature, so I've tweaked it a bit. Now, if the key file comes from $signature, then the key type comes from $signature->algorithm. And likewise, if the key file comes from $self, the key type comes from $self->{Algorithm}.