Many of the functions in the `conditions` package accept a format string and
(optional) arguments, just like `fmt.Printf` and friends.
In many places, the code passed an error message as the format string, causing
it to be interpreted by the `fmt` package. This leads to issues when the
message contains percent signs, e.g. URL-encoded values.
Consider the following code:
```go
// internal/controller/ocirepository_controller.go
revision, err := r.getRevision(ref, opts)
if err != nil {
e := serror.NewGeneric(
fmt.Errorf("failed to determine artifact digest: %w", err),
ociv1.OCIPullFailedReason,
)
conditions.MarkTrue(obj, sourcev1.FetchFailedCondition, e.Reason, e.Err.Error())
return sreconcile.ResultEmpty, e
}
```
Since `getRevision()` includes the URL in the error message and the error
message is used as a format string, the resulting condition reads:
```
failed to determine artifact digest: GET https://gitlab.com/jwt/auth?scope=repository%!A(MISSING)fforster%!F(MISSING)<REDACTED>%!F(MISSING)k8s-resource-manifests%!A(MISSING)pull&service=container_registry: DENIED: access forbidden
```
This adds an explicit format string and shortens `e.Error()` and
`e.Err.Error()` to `e`, which yields the same output.
To the best of my knowledge, Go is safe from format string attacks. I **don't**
think this is a security vulnerability, but I'm also not a security expert.
Signed-off-by: Florian Forster <fforster@gitlab.com>
Replace the patch Helper with SerialPatcher which is used for
progressive status patching.
Update the tests to use progressive status reasons in tests.
Add ProgressingWithRetry Reconciling reason for failed
reconciliation result to indicate a finished failure operation.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
This introduces the consideration of bipolarity conditions in the status
condition summary for Ready condition. The summarize.HelperOptions can
now be configured with a list of bipolarity conditions which are used in
SummarizeAndPatch() to set the Ready condition to failing bipolarity
condition with the highest priority.
Bipolarity condition is not a typical status property. It is a mix of
positive and negative polarities. It's "normal-true" and
"abnormal-false". Failing bipolarity conditions are prioritized over
other conditions to show the actual reason of failure on the Ready
status.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
SummarizeAndPatch() should also consider the object's status conditions
when computing and returning the runtime results to avoid any
inconsistency in the runtime result and status condition of the object.
When an object's Ready condition is False, the reconciler should retry
unless it's in stalled condition.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
- Update summarize helper to have patch field owner.
- Updated the controllers to set the patch field owner.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
summarizeAndPatch() was used by all the reconcilers with their own
object type. This creates a generic SummarizeAndPatch helper that takes
a conditions.Setter object and performs the same operations. All the
reconcilers are updated to use SummarizeAndPatch(). The process of
summarize and patch can be configured using the HelperOptions.
Introduce ResultProcessor to allow injecting middlewares in the
SummarizeAndPatch process.
Introduce RuntimeResultBuilder to allow defining how the reconciliation
result is computed for specific reconciler. This enabled different
reconcilers to have different meanings of the reconciliation results.
Introduce Conditions in summary package to store all the status
conditions related information of a reconciler. This is passed to
SummarizeAndPatch() to be used for summary and patch calculation.
Remove all the redundant summarizeAndPatch() tests per reconciler.
Add package internal/object containing helpers for interacting with
runtime.Object needed by the generic SummarizeAndPatch().
Add tests for ComputeReconcileResult().
Signed-off-by: Sunny <darkowlzz@protonmail.com>
Florian Forster
Sunny