[arpitjain099]

config.md:28 is explicit about the format:

A layer DiffID is the digest over the layer's uncompressed tar archive and serialized in the descriptor digest format, e.g., sha256:a9561eb1...

but config-schema.json types the items as a bare string:

"diff_ids": {
  "type": "array",
  "items": {
    "type": "string"
  }
},

It is the one digest-shaped field in the schema set that does not $ref defs-descriptor.json#/definitions/digest. content-descriptor.json:17 and image-index-schema.json:46 both do.

Driving schema.ValidatorMediaTypeImageConfig.Validate on main, with a well formed digest first so the harness is provably discriminating:

valid digest (positive control)    -> err=<nil>
empty                              -> err=<nil>
not a digest                       -> err=<nil>
path traversal                     -> err=<nil>

After pointing the items at the shared definition, the three bad values are rejected and the good one still passes.

Verification

Four cases added to TestConfig, three expecting failure and one expecting success. The success case is there so the other three are shown to fail on the diff_ids value rather than on something else in the document. Three of the four fail on main.

go test ./... passes in both modules, including TestBackwardsCompatibilityConfig, whose corpus is real Docker 1.10.3 and 1.12.1 configs, so the tightened pattern does not reject anything the project already treats as valid. gofmt -l is clean.

[sudo-bmitch]

Do you maintain a project that's using this code? Is there an upstream issue this would resolve?

[arpitjain099]

No on both counts, and I should say that plainly rather than imply otherwise. I do not maintain a project consuming this schema, and there is no upstream issue behind it.

What prompted it was reading the schema files against each other: rootfs.diff_ids is the only digest-shaped field in the set that does not $ref defs-descriptor.json#/definitions/digest, while config.md defines a DiffID as being "serialized in the descriptor digest format". So it looked like an oversight rather than a decision, and the effect is only on how strictly ValidatorMediaTypeImageConfig treats a config, not on any runtime path.

If the looseness there is deliberate, or you would rather this started as an issue and a discussion than a patch, I am happy to close it. No objection either way.

[sudo-bmitch]

My goal was to get an understanding of who is using those files, because they often get out of sync with the spec and I'm not sure there is anyone that depends on them for anything more than a theoretical use case. It sounds like we're still batting a zero there.

[arpitjain099]

Understood. Closing this PR. Thanks for the context.