It’s hard to believe it, but after all these years I still sometimes come across an OVAL object that surprises me! At the moment, I’m talking about oval:org.mitre.oval:obj:23331, which is currently defined as: <registry_object xmlns="https://protect-us.mimecast.com/s/u_NkCn5mLntZNpPi9a7T0?domain=oval.mitre.org" xmlns:xsi="https://protect-us.mimecast.com/s/N3TACo2nMptV3pgszomUX?domain=w3.org" comment="Immediate child keys of HKEY_USERS" id="oval:org.mitre.oval:obj:23331" version="4"> <behaviors max_depth="1" recurse_direction="down"/> <hive>HKEY_USERS</hive> <key/> <name xsi:nil="true"/> </registry_object> The idea is innocent enough: get the sub-keys of HKEY_USERS. For the moment, let’s not worry about the fact that there is really no reason to ever use this object, because it will never contain all the information that OVAL content writers suppose that it will have (this is, after all, why we created the ntuser_object!). As an exercise in achieving the goal of getting child keys for a hive, it’s terrible! HKEY_USERS is a hive, not a registry key (never mind the fact that to Windows, a hive is a registry key — in OVAL we treat them differently)! So it should have key[@xsi:nil=“true”]. But, if it did, that would mean that the object could never concern itself with keys as it would be confined to dealing only with hives — meaning, it’s not legal in OVAL to use behaviors to crawl down a hive, at least, not according to the specification document. And along these lines… well, can it really even be said that there’s such a thing as a key there with no name? Not really! Nevertheless, I assume that because this object has been around for a really long time, other OVAL interpreters are treating this as if it were a key corresponding to the HKEY_USERS hive. Joval has been doing this. Internally, we treat this like a registry key with a “key" value of null, but without the xsi:nil=“true” setting, in order to trick the interpreter into crawling down according to the behaviors. I think I vaguely recall having a discussion about this with some other OVAL interpreter developer in years past, probably about this very object, probably on the path to the creation of the ntuser_object… But in the meantime this is just bad OVAL! The result for this object, properly executed, would have to be a set of items that include the hive specified by the object (that couldn’t really be specifing a hive). This would create an error for any variable referencing the key field. Better yet, the result should have to be “does not exist”, because there is actually no such thing as a registry subkey with a zero-length pathname, so that non-existing subkey would have no children to crawl down (this would also create an error for any variable referencing the key field). Anyway, I conclude that this object should really have been written like this: <registry_object xmlns="https://protect-us.mimecast.com/s/u_NkCn5mLntZNpPi9a7T0?domain=oval.mitre.org" xmlns:xsi="https://protect-us.mimecast.com/s/N3TACo2nMptV3pgszomUX?domain=w3.org" comment="Immediate child keys of HKEY_USERS" id="oval:org.mitre.oval:obj:23331" version=“5"> <hive>HKEY_USERS</hive> <key operation="pattern match">.*<key/> <name xsi:nil="true"/> </registry_object> THIS object will get all the sub-keys of HKEY_USERS, and nothing else! And, it is unambiguously going to return a set of registry keys. If anyone needed to crawl down more than one level beneath the hive, they could simply add behaviors to this sort of object. So… is there anyone who would strenuously object to my making this change? (For example, interpreters that are using this malformed object as a trigger for ntuser_object-like logic?) Best regards, —David Solin