fabtoken: audit path never applies configured resource limits, always falls back to defaults

[Effi-S]

Fixes #2028

Summary

The main fabtoken validator applies deployment-configured resource limits (MaxInputs, MaxOutputs, metadata size caps, etc.) to deserialized actions via SetLimits(...) before calling Deserialize(). The audit-path deserializer does not — it always falls back to driver.DefaultResourceLimits() regardless of what limits the deployment actually configured. This is an inconsistency between the validate and audit code paths: an action that the validator would reject for exceeding configured limits could still be processed by the audit path using looser defaults.

Where

Main validator wires limits through before deserializing (token/core/fabtoken/v1/validator/validator.go:32,43):

ia.SetLimits(a.Limits)
...
ta.SetLimits(a.Limits)

The audit path's ActionDeserializer never does this (token/core/fabtoken/v1/audit/auditor.go:34-56):

func (a *ActionDeserializer) DeserializeActions(tr *driver.TokenRequest) ([]*actions.IssueAction, []*actions.TransferAction, error) {
	issues := tr.GetIssues()
	issueActions := make([]*actions.IssueAction, len(issues))
	for i := range issues {
		ia := &actions.IssueAction{}
		if err := ia.Deserialize(issues[i]); err != nil {   // no ia.SetLimits(...) call before this
			return nil, nil, err
		}
		issueActions[i] = ia
	}

	transfers := tr.GetTransfers()
	transferActions := make([]*actions.TransferAction, len(transfers))
	for i := range transfers {
		ta := &actions.TransferAction{}
		if err := ta.Deserialize(transfers[i]); err != nil {  // no ta.SetLimits(...) call before this
			return nil, nil, err
		}
		transferActions[i] = ta
	}

	return issueActions, transferActions, nil
}

Since TransferAction.effectiveLimits()/IssueAction.effectiveLimits() fall back to driver.DefaultResourceLimits() whenever SetLimits was never called, the audit path always enforces the hardcoded defaults, never the deployment's actual configured limits.

Impact

Wherever the audit path is expected to reject the same class of oversized/abusive actions the validator rejects (excess inputs/outputs, oversized metadata), it currently enforces a different (and potentially looser or stricter) policy than the one operators actually configured — a DoS-protection inconsistency between validation and audit.

Suggested fix

Thread the configured driver.ResourceLimits into audit.NewAuditor/ActionDeserializer (the same way validator.go receives and applies a.Limits), and call ia.SetLimits(...)/ta.SetLimits(...) before Deserialize() in DeserializeActions.

Severity

MEDIUM — inconsistent enforcement between validate and audit paths, not itself an authentication/validity bypass.

[AkramBitar]

LGTM