Why does `SignatureVerificationAlgorithm` have a `Send + Sync` supertrait bound?

[josh-brown-anchor]

Why does SignatureVerificationAlgorithm have a Send + Sync supertrait bound?

pki-types/src/lib.rs

Line 891 in 1bc73dc

pub trait SignatureVerificationAlgorithm: Send + Sync + fmt::Debug {

[djc]

Because you want to hold them in lots of places that need to be Send or Sync.

What are you trying to do that this is causing trouble?

[josh-brown-anchor]

1. Could you provide an example? I looked at rustls-webpki https://github.com/rustls/webpki and didn't see multi threaded usage of SignatureVerificationAlgorithm. But I might have missed it.
2. Even so, usually you don't add trait bounds until they are actually needed. Nothing about the SignatureVerificationAlgorithm's definition requires these bounds. Instead, the bounds should be added where they are required. For example:

pub fn foo(verifier: impl SignatureVerificationAlgorithm){
   // some single threaded code that doesn't need Send + Sync
}

pub fn foo_multithread(verifier: impl (SignatureVerificationAlgorithm + Send + Sync)){
   // some multi threaded code that actually requires Send + Sync
}

3. As defined today, I am unable to implement SignatureVerificationAlgorithm on types that aren't Send + Sync, even when I am using it with code that does not actually require Send + Sync.

If the concern is convenience, usually you can define a grouper trait and then provide a generic implementation;

trait MultithreadVerifier: SignatureVerificationAlgorithm + Send + Sync {}

impl<T: SignatureVerificationAlgorithm + Send + Sync>  MultithreadVerifier for T

[djc]

That's fair. I don't think we can change it now without doing a semver-incompatible release, and I'm not yet convinced that this is worth breaking compatibility for on its own.

Still curious why the types you want to implement this for aren't Send + Sync. Ultimately this comes out of rustls which eventually stores SignatureVerificationAlgorithms in their config types which we definitely need to be Send + Sync.

[ctz]

Yeah this particular type was "promoted" to here from rustls-webpki, so retains requirements specific to that use in rustls. At least having the the supertraits on the trait reduces an immense amount of repetitive typing elsewhere.

[josh-brown-anchor]

Still curious why the types you want to implement this for aren't Send + Sync

My use case involves a hardware backed crypto accelerator in an embedded environment that I'd like to use with rustls-webpki certificate verification. Mutex's aren't easily available. And I am working in a single threaded environment anyway.

I can try to work around the issue, but if I am not using rustls in multithreaded environment, I shouldn't have to. Unless I misunderstand how webpki works, there is no strict requirement for Send + Sync.

At least having the the supertraits on the trait reduces an immense amount of repetitive typing elsewhere.

I think it would be best to follow the grouper trait pattern above. This accomplishes the same convenience when necessary but allows use of non-Send/Sync versions where they can be used.

If you could point me to the areas where Send/Sync is required, perhaps I'd understand the need better. I didn't look too deeply but not immediately obvious from this quick search https://github.com/search?q=org%3Arustls+SignatureVerificationAlgorithm&type=code

[djc]

rustls::ClientConfig contains a ServerCertVerifier which by default is a WebPkiServerVerifier which holds a WebPkiSupportedAlgorithms which contains a &'static [&'static dyn SignatureVerificationAlgorithm].