identity/deserializer: unsynchronized map access in the signer multiplex can crash the process

[Effi-S]

Fixes #2079

Summary

The signer deserializer multiplex keeps its per-type deserializer lists in a plain Go map that is
written under one mutex and read without any lock, so a concurrent registration and lookup can race
and trigger Go's "concurrent map read and map write" fatal error.

Where

token/services/identity/deserializer/signer.go:23 declares
deserializers map[IdentityType][]TypedSignerDeserializer. Writes happen via
AddTypedSignerDeserializer (signer.go:30-38), called from membership/lm.go:818 while holding
localIdentitiesMutex. Reads happen unlocked at signer.go:45, from
Provider.getSignerAndCache (provider.go:325). These are two different mutexes, so the lock held
during registration provides no protection for the concurrent read path. Registration can happen at
runtime via refreshAndGet (lm.go:889), so a live GetSigner call can genuinely race a new
registration. verifier.go:26 has the same shape, and eidrh.go:26's AddDeserializer has no
mutex at all.

Impact

A registration happening concurrently with a lookup on the same multiplex can trigger Go's runtime
map-race detector, which terminates the process — this is a stability concern under concurrent
identity-registration workloads, independent of any race detector build (the runtime check is always
active for maps, not just under -race).

Suggested fix

Guard map access consistently — either take the same mutex used for writes on the read path (a small
read-lock around the lookup), or switch to a concurrency-safe map type if lock contention on the read
path is a concern given how frequently getSignerAndCache is called. Apply the same fix to
verifier.go and add a mutex to eidrh.go's AddDeserializer, since all three share the same
pattern.

Severity

HIGH — a data-race that can crash the process, though it requires registration and lookup to overlap
in time to manifest.

[AkramBitar]

The read lock is released before the slice is iterated in three places (signer.go, verifier.go, eidrh.go). A concurrent writer calling append may allocate a new backing array at that moment; the reader holds a copy of the old slice header and misses the new entry. This is safe (no crash) but creates a stale-read window.

Consider either holding the lock through the iteration, or copying the slice under the lock before releasing:

v.mutex.RLock()
dess := make([]TypedSignerDeserializer, len(v.deserializers[si.Type]))
copy(dess, v.deserializers[si.Type])
v.mutex.RUnlock()

[Effi-S]

The read lock is released before the slice is iterated in three places (signer.go, verifier.go, eidrh.go).

eidrh.go is not a slice but a single object so it is already copied:

deserializers map[identity.Type]driver2.AuditInfoDeserializer

[AkramBitar]

LGTM