Is the New Security Update Working on My Computers?

steveBinLA wrote:

Jun 18 12:06:26 myMBP XProtectUpdater[29]: NSURLConnection error: Error Domain=NSURLErrorDomain Code=-1009 UserInfo=0x100106ea0 "This computer’s Internet connection appears to be offline." Underlying Error=(Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo=0x100124f60 "This computer’s Internet connection appears to be offline.")

Jun 18 12:06:27 myMBP com.apple.launchd[1] (com.apple.xprotectupdater[29]): Exited with exit code: 255

Well at least this solves one mystery for me. The 255 exit code many have seen is actually a -1009 error in your case.

I would also be very curious to know from someone for whom the automatic updates work how they are connected to the internet? Are you using DHCP for local address assignment? Or do you have a fixed address? Or is there some special configuration that might be turned on very early in the boot cycle? As I reported in a previous post, I have tried a hardwired ethernet connection to my Airport Extreme Base Station, with DHCP address assignment.

You may have already tried this, but I can't tell from this whether or not you have tried a fixed address. I thought you said once before that you set your IP manually in the network prefs and that didn't make any difference. There is one other setting that could help and that's to assign a fixed IP to the MAC address of your computer. Use Airport Utility->Manual Setup->Internet->DHCP, click the + beneath the "DHCP Reservations" box and reserve the IP for your computers' MAC address.

MadMacs0 wrote:

steveBinLA wrote:

I would also be very curious to know from someone for whom the automatic updates work how they are connected to the internet? Are you using DHCP for local address assignment? Or do you have a fixed address? Or is there some special configuration that might be turned on very early in the boot cycle? As I reported in a previous post, I have tried a hardwired ethernet connection to my Airport Extreme Base Station, with DHCP address assignment.

You may have already tried this, but I can't tell from this whether or not you have tried a fixed address. I thought you said once before that you set your IP manually in the network prefs and that didn't make any difference. There is one other setting that could help and that's to assign a fixed IP to the MAC address of your computer. Use Airport Utility->Manual Setup->Internet->DHCP, click the + beneath the "DHCP Reservations" box and reserve the IP for your computers' MAC address.

Thanks much for the suggestion, but I've been (perhaps too) cautious about disturbing my home network. If my wife were to lose her iPad connection, she would be quite displeased. I did try the hardwired ethernet, but did not change the DHCP address setting. I was hoping someone for whom updates were working could comment on what their connection was, without anyone having to change anything. I would guess that, like me, few people deviate from the Apple defined defaults, so if my Airport/DHCP configuration is the problem then it really is a problem that Apple needs to fix.

pcbjr wrote:

I have 5 Intel Macs (3 iMacs and 2 MBPs) at two different locations, and not a single one has ever auto updated. On two of them I am using "Safe Download Version" with (so far) no Keychain issues; on the other 3, I am toggling (so I can compare what is going on).

I have long had a theory that if the initial attempt to update the defs at load (after startup or restart) the daily auto-update is disabled. The experiences related by the two of you would seem to bear that out, but I think we need a few controlled observations before concluding that.

I am not savvy enough to run scripts, nor do I have time to do so on 5 computers located in two different offices and at home.

Unfortunately a bit of information using the Terminal app is required to do this. Certainly not with all your computers, but with at least one or two.

First you would need to restart your computer then use the Console app to view your system and/or console logs to see what, if anything they say about the XProtectUpdater process failing with exit code 255. That confirms that the initial update did not take place.

Next you need to know what version of the defs is installed on your computer. You can use either the AppleScript tool or the widget that have been previously discussed, run this command in the Termainal app

defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version

Next, use the following Terminal commmand:

sudo launchctl list

enter your admin password at the prompt and hit return. Then find "xprotect" and tell us what the number in the 2nd column is. If the update succeeded, it should be "0" and if it failed I would expect it to be 255. If you don't find the process listed at all then, it isn't going to run, period.

the last step would be to wait 24 hours to see if it auto-updates (by running the version check again).

MadMacs0 wrote:

baltwo wrote:

copy these lines into the AppleScript Editor app window, save as an application, and then double-click it to update the XProtect database.

do shell script "sudo /usr/libexec/XProtectUpdater" with administrator privileges

set a to do shell script "defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version"

set b to do shell script "defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta LastModification"

display dialog "Safe Download definitions are at version " & a & "," & return & "last updated on " & b

Doesn't get any simpler than that.

I'm getting way behind here, but I need to comment on this one first.

I don't know where you got the idea that this script would update the XProtect database, but it does not. It's a good script and I do recommend it to anybody that finds a need to know what database is currently on there computer, but that's all it does. If you think it's out-of-date, you must still toggle the preference pane in order to update it.

I'm sorry, my previous answer, shown above, is totally wrong and it should be deleted. This script absolutely will attempt to update the defs and in the best case will disable the daily automatic update until you restart the computer.

In the worst case, it will delete your login keychain. I received another confirmation of this again today in another forum. The user was able to restore his keychain from backup then immediately ran a script similar to the above causing the keychain to immediately disappear again.

I do not advise the use of the first line of the above script to anybody. It's not that much harder to simply toggle the Security prefs pane box and if you must verify that it was successful, run the rest of the AS or use the Terminal command to see what version you have.

steveBinLA wrote:

Thanks much for the suggestion, but I've been (perhaps too) cautious about disturbing my home network. If my wife were to lose her iPad connection, she would be quite displeased. I did try the hardwired ethernet, but did not change the DHCP address setting. I was hoping someone for whom updates were working could comment on what their connection was, without anyone having to change anything. I would guess that, like me, few people deviate from the Apple defined defaults, so if my Airport/DHCP configuration is the problem then it really is a problem that Apple needs to fix.

Just to give you a bit of confidence, I made that change myself before I wrote it up and my wife's iPad is still connecting perfectly.

I realized that I forgot to ask if the AEBS is acting as the DHCP server or is it your modem? I am guessing that since you are using the default settings for your AEBS (something I have never done) then it must be the former.

I will be the first to agree that this is an Apple problem that they need to fix, but I thought we were trying to help folks work through the issue until they do. Who knows, it might even help Apple better understand the issue.

Really? On my machine, this line updates the database.

do shell script "sudo /usr/libexec/XProtectUpdater" with administrator privileges

The latest update is version 20 and I've not cycled the prefPane setting. BTW, I saw your follow-up and can only advise that I've not had the keychain mucked with since I created it on June 6. I don't have any idea what the other application might do, so I've not used it.

pcbjr wrote:

1:50 PM, EDT, Sunday, June 19th.

What version are we at now?

Version 20:

baltwo wrote:

Really? On my machine, this line updates the database.

do shell script "sudo /usr/libexec/XProtectUpdater" with administrator privileges

The latest update is version 20 and I've not cycled the prefPane setting. BTW, I saw your follow-up and can only advise that I've not had the keychain mucked with since I created it on June 6. I don't have any idea what the other application might do, so I've not used it.

The other application, as well as issuing that line in the Terminal app shuts down your daily auto-update. For some, but not all users there is strong evidence that it did damage to their keychains.

The only manual update method recommended by Apple is to toggle the "Automatically update safe downloads list" box in the Security Systems Preference pane.

MadMacs0 wrote:

The only manual update method recommended by Apple is to toggle the "Automatically update safe downloads list" box in the Security Systems Preference pane.

Have a reference? The only published KB article is http://support.apple.com/kb/HT4650 and it's silent on any manual update method.

I read that too, but I think it was another user who was told that by AppleCare tech support who reported it to this forum of that instruction..

I also just checked mine, using the quicklook at the xprotect plist, and I am still at 13. Did the toggle, now at 20. I have restarted several times since version 13, but no updates have occured since then. I am on an AEBS, however. It's possible, like others have stated, that the wifi network isn't stabalized yet when this is suppose to run after startup so that check fails (the code 255?). As long as the toggle method works, it's easy enough to do for now..

Thanks for the feedback. No wireless or wifi stuff here, so that's not the issue on my end. AFAICT, the autoupdating mechanism isn't working. I've filed a bug report on the lack of autoupdating..

baltwo wrote:

Thanks for the feedback. No wireless or wifi stuff here, so that's not the issue on my end. AFAICT, the autoupdating mechanism isn't working. I've filed a bug report on the lack of autoupdating..

Although wifi could be an issue if you have a marginal signal, the reports I've read indicate it to be some other factor involved in obtaining internet access, such as the DHCP process. This must take place regardless of whether you are wired or wireless and when delayed beyond the attempt at load by the the XProtectUpdater to check for updates will cause it to fail. What I would be interested in knowing is whether or not this initial failure also shuts down the autoupdating mechanism.

I am predicting that the 10.6.8 updater will correct this, as it's possible the reason it's not working for us now is that Apple needed to get it out to deal with the current threat (probably due to the overwhelming support calls) and this new mechanism might have been something "pulled" from the upcoming 10.6.8 release that needed the rest of the 10.6.8 components to work as expected....just a thought.