Hey mgoralski,

I had this issue with my own personal computer, and the following fixed it:

Navigate to: ~/Library/Preferences
Create a new document, or edit if already exists: com.apple.DownloadAssessment.plist

Put this stuff in there:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> 
 <key>LSRiskCategorySafe</key> 
<dict> 
 <key>LSRiskCategoryExtensions</key> 
<array> 
 <string>pkg</string> 
 </array> 
 </dict> 
 </dict> 
</plist>

I hope that helps :) Please be careful when altering system files like this, and always test :)

Thanks for the reply. The fix makes sense, but we're still stuck with the problem of the enrollment package being flagged as insecure before the machine is enrolled. I daresay JAMF needs to change the way the .pkg is signed.

Totally understandable. I think the issue is more what Safari thinks is a "Safe" file, I'm not sure it has much to do with signed or unsigned. So what this does is say, "Hey Safari, this file format is cool. If you find something terrible in the file, block it, but otherwise, we're all good here."

As we know all to well, these types of problem usually boil down to Apple -vs- 3rd Party Vendor. I'd like to know (wouldn't we all) whether this boils down to a problem with Safari or the JSS. I'm inclined to think Safari. Key to this is the difference between Safari's check of the .pkg and OS X's check. They obviously differ, but how?