See also: #1470

notice that the partial support of format is a pain , because when using in conjonction with oneOf the current implementation make the validation failing in all case when adding a sample as it patches always both item of the oneOf

    maturity:
      description: Maturity date or tenor 
      type: string
      oneOf:
        - format: date
        - pattern: ^\d+[YyMmWwDd]|\d+[YyMmWwDd]\d+[YyMmWwDd]

A similar issue.

Same issue exists with schema examples.

Maybe we should support format validation one-by-one? Starting with the most obvious formats like date, date-time, pattern?

Maybe we should support format validation one-by-one? Starting with the most obvious formats like date, date-time, pattern?

Redocly CLI relies on AJV for validating examples, and AJV is supposed to be used together with the ajv-formats plugin to validate formats. It should be comparatively easy to start adding some formats.

However, there is a potential security issue of ReDoS attack:

It is recommended NOT to use "format" keyword implementations with untrusted data, as they may use potentially unsafe regular expressions

So the main issue here, I believe, is to assess the potential security impact.

redocli CLI looks not an appropriate target for a redos Attack, given redocly is used as a linter tooling (meaning validation a file that you are in control) . The worst case i can establish would be some one introducing a poisonned spec with nasty sample in a CICD that could lock the production chain . Usually this kind of attack is used in a runtime mode like an API gateway or a backend code and so not a redocly use case

One remediation can be to applies validation on sample only for the format part and not for the pattern part
This would be already a great step , especially considering the format date for instance , here as the pattern is controled internaly by redocly it should not be something really subject to attacks

then given the the attack vector being to intput a bad pattern , and then a bad sample that make infinite loop, an other remediation ( to check if it is possible) is to apply a time out for exemple validation that would significantly reduce the impact of the attack.

@LasneF I think you're right in your assumptions. It's mostly a matter of priorities 😅.

Since the formats are more like advice than strict types, let's add the ability to not check formats as a configuration setting on the rule.

i would not qualify format or pattern as an advice , but munch more as a constrains , as same as minLength or pattern.
To me format act as a kind of "predefined" pattern to avoid setting the date time complex regular expression .
till the registry is open , it is fair to be open and fluid for unknown format , but for known format that would be nice to have strict validation

i am not 100% sure about what mean Format Assertion , but the feature that would be nice is the implementation of
https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-validation-00#rfc.section.7.2.2

meaning "When the Format-Assertion vocabulary is declared with a value of true, implementations MUST provide full validation support for all of the formats defined by this specificaion."