Dapr 1.8.4

Fixes an issue that could have caused Azure Service Bus components to stop receiving messages

Problem

Starting with Dapr 1.8.0, a bug in the Azure Service Bus components–bindings.azure.servicebusqueues and pubsub.azure.servicebus–could cause Dapr to stop receiving messages after a failure, requiring the runtime to be restarted.

Impact

The issue impact users of Dapr 1.8.0-1.8.3 who use the a component of type bindings.azure.servicebusqueues or pubsub.azure.servicebus. After recovering from a failure, for example a temporary network loss, Dapr could stop receiving messages from the queue or topic, requiring a restart of the runtime.

Root cause

In case of errors, Go channels used to limit concurrency (in particular, used to enable maxActiveMessages and maxConcurrentHandlers) were not drained as expected. As such, the runtime would end up stuck in a waiting state and would not retrieve more messages from Azure Service Bus.

Solution

We have identified the places where Go channels were not drained correctly and fixed the bug in Dapr 1.8.4.

Updated the bluemonday transitive dependency to fix CVE-2021-42576

Problem

Dapr versions < 1.8.4 have a transitive dependency on github.com/microcosm-cc/bluemonday 1.0.7 or earlier. Versions of bluemonday before 1.0.16 are impacted by CVE-2021-42576.

Impact

Despite the vulnerability considered "critical", we believe the impact on Dapr users is limited. The affected code is a transitive dependency imported by the middleware.http.oauth2 component and not used in active code paths in Dapr.

Root cause

github.com/microcosm-cc/bluemonday, a transitive dependency of middleware.http.oauth2 component, needed to be updated to versions greater than 1.0.16.

Solution

We have upgraded the github.com/microcosm-cc/bluemonday transitive dependency to a version not affected by CVE-2021-42576 in Dapr 1.8.4.