You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of cachedKeyService in signer/keydbstore/cachedcryptoservice.go uses a sync.Mutex{} to synchronize write access to the cache map. However, reading from the map in GetPrivateKey in this line: cachedKeyEntry, ok := s.cachedKeys[keyID] is not protected using a read lock. So, there can be a race condition when the map is being updated at the same time when it is being read.
I would suggest using sync.RWMutex instead of sync.Mutex and using a read lock around access:
s.lock.RLock() cachedKeyEntry, ok := s.cachedKeys[keyID] s.lock.RUnlock()
I can submit a pull request if you are okay with this.
May also be worth considering sync.map: golang/go#18177 when Notary is on the golang version that supports it.
The text was updated successfully, but these errors were encountered:
The implementation of
cachedKeyService
in signer/keydbstore/cachedcryptoservice.go uses a sync.Mutex{} to synchronize write access to the cache map. However, reading from the map inGetPrivateKey
in this line:cachedKeyEntry, ok := s.cachedKeys[keyID]
is not protected using a read lock. So, there can be a race condition when the map is being updated at the same time when it is being read.I would suggest using
sync.RWMutex
instead ofsync.Mutex
and using a read lock around access:s.lock.RLock()
cachedKeyEntry, ok := s.cachedKeys[keyID]
s.lock.RUnlock()
I can submit a pull request if you are okay with this.
May also be worth considering sync.map: golang/go#18177 when Notary is on the golang version that supports it.
The text was updated successfully, but these errors were encountered: