Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
This patch release contains bug fixes:
The mTLS configuration was always enabled for Dapr sidecards in Kubernetes, regardless of the daprsystem
configuration.
Users on Dapr 1.12.1 could not disable mTLS for Dapr sidecars in Kubernetes.
The daprsystem
configuration was not being read correctly by the sidecar injector.
The daprsystem
configuration is now read correctly by the sidecar injector and the mTLS option is correctly set for Dapr sidecars in Kubernetes.
This patch release contains bug fixes:
The mTLS configuration was always enabled for Dapr sidecards in Kubernetes, regardless of the daprsystem
configuration.
Users on Dapr 1.11.5 could not disable mTLS for Dapr sidecars in Kubernetes.
The daprsystem
configuration was not being read correctly by the sidecar injector.
The daprsystem
configuration is now read correctly by the sidecar injector and the mTLS option is correctly set for Dapr sidecars in Kubernetes.
This update contains the following security fixes:
Additionally, this patch release contains bug fixes:
daprsystem
Configuration from the control plane namespaceSentry and Injector will apply the daprsystem
configuration from a non-control plane namespace if the namespace name is alphabetically higher than the control plane namespace name.
Accidentally or maliciously, a Kubernetes user can write a Configuration in a non-control plane namespace that will be applied by Sentry and Injector. This can re-write the Sentry CA, disable mTLS, or otherwise bring down the entire Dapr cluster.
Sentry and Injector currently list Configurations, before matching on the list for the daprsystem
Configuration, without filtering for namespaces.
Update Sentry and Injector to only get the daprsystem
Configuration from the namespace where the Dapr control plane is installed, instead of listing all Configurations.
With Resiliency enabled, in case of HTTP service invocation, if one application sends error status codes (HTTP codes <200 or >=400), Dapr returns a response with a generic 500 error, instead of the actual response error code.
Applications will receive the wrong status code in case of HTTP service invocation returning a failure error code with Resiliency enabled.
A bug was discovered in how errors were handled when Resiliency was enabled, causing all errors from the application to be "swallowed" by Dapr.
Resiliency code now returns the correct status code to the application.
The Dapr's .Net SDK returns actor exceptions via a special response with the exception serialized in the response body and adding the X-Daprerrorresponseheader
HTTP header. This exception was not handled correctly starting at version 1.10, resulting in a generic error message at the calle's side.
See https://github.com/dapr/dapr/issues/6339
Actor exception details are lost and a generic message is returned instead.
Retry logic in sidecar was dropping the error details returned by the actor method.
Fixed the retry logic to save the error's payload and return it in the end of the actor invocation logic.
This is the release candidate 1.12.2-rc.2
This is the release candidate 1.11.6-rc.1
This is the release candidate 1.10.10-rc.3
This is the release candidate 1.12.2-rc.1
This is the release candidate 1.10.10-rc.2
This update contains the following security fixes:
Additionally, this patch release contains bug fixes:
daprsystem
Configuration from the control plane namespaceSentry and Injector will apply the daprsystem
configuration from a non-control plane namespace if the namespace name is alphabetically higher than the control plane namespace name.
Accidentally or maliciously, a Kubernetes user can write a Configuration in a non-control plane namespace that will be applied by Sentry and Injector. This can re-write the Sentry CA, disable mTLS, or otherwise bring down the entire Dapr cluster.
Sentry and Injector currently list Configurations, before matching on the list for the daprsystem
Configuration, without filtering for namespaces.
Update Sentry and Injector to only get the daprsystem
Configuration from the namespace where the Dapr control plane is installed, instead of listing all Configurations.
Dapr would fail to request an identity certificate from Sentry when residing in a Namespace or using a Service Account with a sufficiently long name.
Users on Dapr 1.12.0 can observe Dapr sidecars failing to start.
Sentry validates that clients cannot request for an app ID which is over 64 characters in length.
Sentry also still accepts requests which use the legacy identifier of <namespace>:<service account>
which was not taken account for when doing the 64 character evaluation.
Sentry now evaluates the actual app ID being requested, whether or not the client is using the legacy or app ID as the identifier.
A RabitMQ component may be considered healthy, when in fact it failed to initialise.
Dapr or downstream consumers of Dapr would consider RabitMQ components to be healthy when in fact they were not, causing improper reporting of status.
RabbitMQ was not returning an error when initialising a component, causing Dapr to consider the component healthy.
Failure to connect to RabbitMQ during initialization now causes an error to be returned, allowing Dapr to consider the component as unhealthy.
With Resiliency enabled, in case of HTTP service invocation, if one application sends error status codes (HTTP codes <200 or >=400), Dapr returns a response with a generic 500 error, instead of the actual response error code.
Applications will receive the wrong status code in case of HTTP service invocation returning a failure error code with Resiliency enabled.
A bug was discovered in how errors were handled when Resiliency was enabled, causing all errors from the application to be "swallowed" by Dapr.
Resiliency code now returns the correct status code to the application.
Invoking certain Workflow APIs using HTTP with malformed URLs can cause Dapr to panic.
Impacts users on Dapr 1.12.0.
The Daprd metrics handler for workflows did not correctly handle malformed or unexpected URLs, and would panic if the URL was not in the expected format.
The Daprd metrics handler for workflows now correctly handles malformed or unexpected URLs.
The Azure Blob Storage component cannot be used with Azure Blob Reader permission alone.
Users on Dapr 1.12.0 cannot use the Azure Blob Storage component with Azure Blob Reader permission alone.
The component attempts to create a storage account (even when it exists already) but is not authorized to do so due to a lack of permission.
Added a boolean metadata option disableEntityManagement which now can be used to skip the attempt to create the storage container.
Azure EventHub component returns a warning message saying the storageAccountKey will be used but StorageAccountName is actually used in that condition.
Users on Dapr 1.12.0 may be confused by the warning message.
The component was using the StorageAccountName instead of the StorageAccountKey.
The component now emits the correct warning message.
Dapr 1.12.0 was unable to add and resolve hostnames using the Consul nameresolution component.
Users on Dapr 1.12.0 were unable to resolve hostnames using the Consul nameresolution component.
A previous community contribution to improve IPv6 support inadvertently removed support for host names by returning an error for any string that does not parse as an IPv4 or IPv6 address.
Support for hostnames was added once again.
The Redis PubSub component could experience a rare situation where PubSub subscriptions would seize to function, causing the Dapr sidecar to print Redis error logs containing the word NOGROUP
indefinitely.
The NOGROUP
message is indicative of the consumer group no longer existing. This could be because the group or stream was manually deleted outside of Dapr or because the external Redis server was restarted/reconfigured.
To avoid the excessive NOGROUP
logs in this rare situation Dapr will now attempt to recreate the consumer group for the given topic/stream when this error is encountered.
path/filepath
This is the release candidate 1.12.1-rc.2