FYI: Xprotect/Gatekeeper and Safari 6.1

[JPDyson]

Safari 6.1 seems to require the presence of the Gatekeeper Xprotect manifest (/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist). If your previous approach to preventing Apple from disabling Java via this mechanism included deleting the file entirely, or preparing one with preferred versions, you'll need to update it. The manifest itself has changed considerably; the better approach seems to be to manage via mcx what sites are allowed to always run (that mechanism is still working for me, at least for Java and our Network Connect urls).

[JPDyson]

Additional note: A symptom of not having a current manifest is that plugins will be marked as "unsafe" in Preferences - Security - Manage Website Settings... even if they're current versions. It seems that "innocent until proven guilty" is out the window here; plugins require positive identification as "safe".

[rtrouton]

For those interested in managing XProtect instead of disabling it, my solution for managing XProtect's ability to block the Java plug-in continues to work on 10.9:

http://derflounder.wordpress.com/2013/02/24/managing-java-browser-plug-in-settings-for-apples-xprote...

[JPDyson]

Indeed; since your script only modified the lines that apply to Java, when a new manifest is created, the other keys remain unmodified. I contend that this is managing the problem at the wrong end, and has perhaps an even worse side-effect: no matter what version of Java a client is running, this method will permit it to be used by Safari for ALL sites (not just your trusted sites).

Rather than disabling xprotect, or modifying its manifest, white-listing trusted sites via managed preferences seems like the most secure and simple approach. You maintain functionality of the currently-deployed version on your trusted sites, while allowing xprotect to enforce minimum safe versions on others (and you don't have to have a launchdaemon constantly un-doing what xprotect is doing, creating a race condition).

[charles_hitch]

You can also now manage Xprotect settings via Server 3.0 under Software Update.

[nessts]

all i see under software update is URL for update server.

[JPDyson]

Indeed; I don't see this under Software Updates either. I couldn't tell if he meant under the Software Updates config in the Server.app (not there) or in Config Profiles (not there either). @charles.hitch Can you clarify?

[JPDyson]

Like I said above, the old WhiteListedBlockedPlugins still works, but the new ManagedPluginPolicies dict allows for specifying not just whether it should run, but if indeed it should run "Unsafe" (un-sandboxed) for certain URL's as well. I've addressed a particular application for this (Juniper Network Connect) here:

https://jamfnation.jamfsoftware.com/discussion.html?id=8789

[charles_hitch]

I haven't been able to look yet, but the way Apple told me they implemented it is that its configured under Software Update in Server.app. ie You have to be running the Software Update Service.

[nessts]

oh so its like the customize setup assistant feature they announced, you probably have to have apple do that for you. :)

[nessts]

Or call it vapor ware like I do.

[JPDyson]

There is, in fact, an update called XProtectPlistConfigData (at least, on my Net/SUS 2 appliance) released on 8 October; appears they're letting us release these as we see fit.