chore(deps): bump signature to 3.0.0-pre

[baloo]

No description provided.

[baloo]

The upgrade seems to hurt the type inference here:

error[E0282]: type annotations needed
  --> tests/pkcs1v15.rs:16:9
   |
16 |     let signature = signing_key.sign(bytes);
   |         ^^^^^^^^^
...
22 |     assert_eq!(signature.to_string(), expected);
   |                --------- type must be known at this point
   |
help: consider giving `signature` an explicit type
   |
16 |     let signature: /* Type */ = signing_key.sign(bytes);
   |                  ++++++++++++

I'm not sure I understand why quite yet.

[baloo]

This is just that we now need to carry the Digest as type parameter of the signature, I think I'm fine with such a change.

[tarcieri]

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

[tarcieri]

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

[baloo]

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

[tarcieri]

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

[baloo]

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either they don’t have digest in the first place

[baloo]

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

[baloo]

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

[tarcieri]

This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.

This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.

I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.