In opencontainers/image-spec#826 some concerns were raised about the new field being used as a vector for DoS attacks, if registries and clients don't enforce some maximum size on the data they accept.
This concern isn't unique to the data field. I can think of a few places where this could crop up in the existing specs:
- annotations
- digests (
sha123:...10GB of garbage...)
- blob uploads/fetches in general
In all cases servers need to be resilient to malicious or badly configured clients, and vice versa.
It might be enough to just recommend that implementers enforce some maximum size when receiving manifests or blobs, and not bother recommending specific validations for every field that could contain arbitrary data.
(Correct me if I'm wrong, this sounds like a concern for distribution-spec, and not the image-spec)
In opencontainers/image-spec#826 some concerns were raised about the new field being used as a vector for DoS attacks, if registries and clients don't enforce some maximum size on the data they accept.
This concern isn't unique to the
datafield. I can think of a few places where this could crop up in the existing specs:sha123:...10GB of garbage...)In all cases servers need to be resilient to malicious or badly configured clients, and vice versa.
It might be enough to just recommend that implementers enforce some maximum size when receiving manifests or blobs, and not bother recommending specific validations for every field that could contain arbitrary data.
(Correct me if I'm wrong, this sounds like a concern for distribution-spec, and not the image-spec)