ata-validator

A schema that names something "__proto__" could accept documents it rejects. Several places copied a schema, or a map keyed by property names, by assignment, and assigning the key "__proto__" sets the copy's prototype instead of creating the property, so the constraint on it was gone from the copy. It happened for a property named "__proto__" next to a $ref that is resolved at compile time (one relative to a nested $id, for example), for a $ref pointing at such a property, and for draft-07 dependencies on such a property, which affected every engine. For example {"$id": "http://e.x/root", "$defs": {"S": {"$id": "s", "type": "string"}}, "properties": {"__proto__": {"type": "number"}, "r": {"$ref": "s"}}} accepted {"__proto__": "s"}. A schema that lists "__proto__": false to keep that key out of documents was affected the same way. Affected: measured on 1.40.1, 1.41.0 and 1.43.0; earlier versions were not checked. Every copy now writes such a key as an own property. tests/test_proto_name_rename_invariance.js checks that a schema and a document using the name answer exactly as the same pair with the name renamed, on every engine and every read, ahead-of-time modules included: 3328 documents, none different.

validateJSON() with richErrors: false returned the errors of a rejected document in the order generated code found them, where validate() returns them in schema order, so one document could list its errors in two orders. Both now give the same list. Reading those errors costs about 50 ns more per rejection on a small schema.