Any way to retrieve a Patch Version's Release Date via the API?

[straffin]

Before I create a Feature Request, I figured I'd ask here to make sure I'm not missing anything (like a super secret "verbose" flag or something). :-)

Looking at the Patch Management --> Definition tab for (just for example) Google Chrome, I see Version, Release Date, Incremental Update, Reboot Required, etc.

Looking at the API, it seems that the closest I can get to this information is:

GET /patchsoftwaretitles/id/{id}

which returns only the Version information:

<patch_software_title>
  <id>9</id>
  <name>Google Chrome</name>
  <name_id>GoogleChrome</name_id>
  <source_id>1</source_id>
  <notifications>
    <email_notification>true</email_notification>
    <web_notification>true</web_notification>
  </notifications>
  <category>
    <id>103</id>
    <name>Browsers</name>
  </category>
  <site>
    <id>-1</id>
    <name>None</name>
  </site>
  <versions>
    <version>
      <software_version>74.0.3729.169</software_version>
      <package/>
    </version>
    <version>
      <software_version>74.0.3729.157</software_version>
      <package/>
    </version>
...
  </versions>
</patch_software_title>

I really need the other information form this table (particularly the Release Date) and really don't want to start hitting the MySQL tables directly (as cloud is always an option and directly addressing the tables i n the cloud is not). Is there any way (or any hope) to get information like this from the API? For example

GET /patchsoftwaretitles/id/{id}/full

could return

...
    <version>
      <software_version>74.0.3729.169</software_version>
      <release_date>05/21/2019 12:30 AM EDT</release_date>
      <release_date_epoch>1558413000</release_date_epoch>
      <incremental_update>none</incremental_update>
      <reboot_required>false</reboot_required>
      <dependencies/>
      <minimum_os>10.10</minimum_os>
      <apps_that_must_quit>
        <app>Google Chrome</app>
      </apps_that_must_quit>
      <package/>
    </version>
...

Is there a way to get what I need from the API, or am I off to make a feature request? :-)

-- John

[straffin]

So, I've discovered that we can get this information directly from Jamf in the same way that Jamf Prop does:
(from the bottom of https://www.jamf.com/jamf-nation/articles/424/jamf-process-for-updating-patch-management-software-titles)
https://jamf-patch.jamfcloud.com/v1/software
https://jamf-patch.jamfcloud.com/v1/software/{id}
https://jamf-patch.jamfcloud.com/v1/patch/{id}

Don't yet know what to make of the weird binary at the beginning of the /patch/ response (at least, for id "GoogleChrome"), but it's a start.

Would still like to get it directly from our on-prem server.

-- John

[tlarkin]

Is this the actual vendor's release date or is this jamf's release date?

[brandonpeek]

If this is the vendor's release date that would be fantastic! We've been trying to do something similar as we need the release dates for updates from Apple but they aren't included anywhere that we can scrape them in an automated way, so restored to submitting a feature request last year asking Apple to include this data.

[tlarkin]

We use Tenable Vuln scan data to get the actual release date of patches from vendors to calculate days old for our SLAs. If this was indeed the Vendor's release date, I would see it as valuable, if not it is not as valuable.

[straffin]

Is this the actual vendor's release date or is this jamf's release date?

Looking at the "Jamf Process for Updating Patch Management Software Titles" page, these dates appear to be the vendor's release date.

[mm2270]

Someone I know (another Jamf admin) had pointed me to those URLs a while back. In looking at it, I came up with a basic way to extract things like version, date and so on. As it's in JSON format, I had to look up a way to format it so I could pass it back to bash and read values from it. Turns out there is an extension in python called json.tool that does the trick. Example using GoogleChrome, you get:

curl -s https://jamf-patch.jamfcloud.com/v1/software/GoogleChrome | python -m json.tool
[
    {
        "currentVersion": "74.0.3729.169",
        "id": "GoogleChrome",
        "lastModified": "2019-05-21T21:29:32Z",
        "name": "Google Chrome",
        "publisher": "Google"
    }
]

Using that, I came up with the following to extract some of the useful values from the output:

#!/bin/bash

BASE_URL="https://jamf-patch.jamfcloud.com/v1/software"
PRODUCT_ID="GoogleChrome"

PRODUCT_DATA=$(curl -s "${BASE_URL}/${PRODUCT_ID}" | python -m json.tool )

CURRENT_VERSION=$(awk -F" '/currentVersion/{print $4}' <<< "$PRODUCT_DATA")
LAST_MOD_DATE=$(awk -F" '/lastModified/{print $4}' <<< "$PRODUCT_DATA")

echo "${PRODUCT_ID} current version: $CURRENT_VERSION"
echo "${PRODUCT_ID} last modification date: $LAST_MOD_DATE"

Of course, if you're a python coder, I'm guessing this is all easier to do directly in python than in bash.

Also, I'm not clear if the date it's stored in is in GMT time or not. (anyone know for sure?) It may be, but that can of course be adjusted to your respective time using the date command if needed.

Lastly, if you need a clean list of all the product IDs that Jamf tracks, this command will print them out for you:

curl -s https://jamf-patch.jamfcloud.com/v1/software | python -m json.tool | awk -F" '/id/{print $4}'

[straffin]

Thanks! I'm actually more interested in the historical information held in the /patch/ api versus the /software/ api, but this could prove useful.

(I am, however, a PowerShell programmer, so there is that... :-D )

-- John

[straffin]

Also, I'm not clear if the date it's stored in is in GMT time or not. (anyone know for sure?)

The "Z" at the end of the "lastModified" value indicates that the value is in "Zulu time" or UTC (which is also GMT, kinda).
Understanding Zulu Time and Coordinated Universal Time

-- John

[tlarkin]

@straffin are you looking for data on dates when patch/release/fix/update is released and how long it took to apply? then percentage of patches in the interim?

[straffin]

@tlarkin - Just looking for the release dates. Another system we use can report on when a given computer first needed a patch... we're looking to use the patch release date from Jamf Pro to try to approximate something similar.