(I'm attempting to reset the conversation and move forward from what went on in the pkginfo discussion.)

One of the typical uses for OVAL (http://oval.mitre.org) is to determine whether a particular version of a particular software package is installed. E.g. Is Firefox version 22.0 installed? These tests are typically used to determine if a machine is susceptible to particular CVEs. See http://oval.mitre.org/repository/data/ViewDefinition?id=oval%3aorg.mitre.oval%3adef%3a16427. On Windows systems, the registry is typically consulted to see if an application is installed and what version it is. On Red Hat Linux systems, the Red Hat Package Manager (RPM) is checked (see http://oval.mitre.org/repository/data/ViewItem?id=oval:org.mitre.oval:tst:38379).

If you check the similar inventory definitions in the OVAL Repository for OS X you will notice a few things (http://oval.mitre.org/repository/data/SearchDefinitionAdv?class=2&family=2) :
  1. There are very few items compared to Windows or Linux.
  2. They all check for the existence of a particular file, whether it be in the package receipt directory (/private/var/db/receipts) or the /Applications directory.
Based on the discussion concerning the pkginfo test, the above approach of checking for the existence of certain files is at best not a best practice, and at worst dangerously wrong.

During the pkginfo test discussion, it was mentioned that "system_profiler SPApplicationsDataType" could be used from the command line, and Josh shared some Objective-C code that does a metadata query.

I want to be careful when developing the OVAL constructs not to dictate the implementation. E.g. Issuing "system_profiler SPApplicationDataType" and then using Xpath to examine the XML might work, but an "application_test" that you hand an application name and get back metadata similar to what system_profiler provides may make more sense. On Windows, there is not a "regedit_test", there's a "registry_test". Under the covers, "application_test" could use system_profiler or API calls to return the desired stuff. And how the information is retrieved could depend on many things – is the evaluation being done directly on the box? Is a central scanner being used that connects remotely to a box? Is MDM being used?

If we go down the path of "systemprofiler_test" that limits our options quite heavily. OTOH, system_profiler seems to be very flexible and gives access to many types of information in an "Apple approved" way. Perhaps implementing a general system_profiler based test quickly will be a good starting point and from there we can move on to better, more specialized tests. (Similar to how there is a textfilecontent test, but there is now a proposal for an INI test as working with INI files as raw text files is extremely cumbersome.)

- Jasen.