MacInTouch Amazon link...
Channels
Apple, Troubleshooting, Questions


On a 2015 MacBook Pro, running macOS 10.12.6 Sierra, I installed Security Update 2019-003 (plus Safari 12.1.1 and iTunes Device Support Update).

System/firmware before update:
Model Identifier: MacBookPro11,4​
Boot ROM Version: 189.0.0.0.0
SMC Version (system): 2.29f24​

System/firmware after update:
Model Identifier: MacBookPro11,4​
Boot ROM Version: 192.0.0.0.0
SMC Version (system): 2.29f24​
System Version: macOS 10.12.6 (16G2016)​
Kernel Version: Darwin 16.7.0​
Everything still running OK?
Inquiring minds... hesitant to update until I learn more... especially iTunes!
 


Ric Ford

MacInTouch
Everything still running OK?
Inquiring minds... hesitant to update until I learn more... especially iTunes!
I don't use iTunes (hardly ever), but I was worried about iMazing working, so the first thing I tested was wireless backups, which seem to still be working after the Apple updates.

Haven't noticed any other problems and haven't heard about any.

(I was very cautious with the iOS 12.3 update, but I've now applied that to two phones without incident.)
 


An old 2011 MacBook Pro was running El Capitan [OS X 10.11], and the App Store offered Mojave. I approved. After the installation, the Mac was unbootable.

I then checked the Mojave system requirements at Apple and found that this machine (ID 8,1) can only go as far as High Sierra. Luckily the data was recoverable. I'll do a wipe and clean High Sierra install, then bring the data back. Then it's the slog through the final config for printer, wifi, extra apps, etc.

Thanks a lot, Apple.
 


I've just experienced a very odd bit of behavior with the Mac App Store in Mojave.

I use Deliveries, an excellent package-tracking app. I have version 3.2 installed, and I saw on macupdate.com that 3.2.1 had been released. I opened the Mac App Store, fully expecting it to tell me that an update was available, but there was stony silence. Crickets.

I even clicked on the Updates tab and did Reload Page, thinking that would cause it to check for updates.

I then searched for Deliveries, and the listing that came up had an update button (even though there was still no badge visible anywhere!) The listing also detailed that the update was actually two days old.

Has anyone else seen this behavior? I haven't seen it on earlier versions. I must say, I would prefer that the Mac App Store never existed in the first place, and I really don't like Mojave's redesign of it.
 


You might want to try downloading fresh copies of the old installers. I don't recall how how many Apple installers and updaters were affected, but the security certificate Apple used to sign many of its older packages expired a few years ago, preventing them from working. The workaround was to set the date on your Mac back in time temporarily or to download new versions of the installers/updaters with updated security certificates.
Thanks, JoseHill: A fresh copy of Mac OS X Server 10.6.8 Update Combo Update 1.1 could update Mac OS X 10.6.3, and after installing Security Update 2013-004 Server (Snow Leopard) or Apple Software Installer Update 1.0, then VMware Tools and all other off-line installers worked OK.

It seems Apple has not unpdated all installers, because even freshly downloaded earlier Combos failed. I wonder when the current certificates will expire again.

 


I then searched for Deliveries, and the listing that came up had an update button (even though there was still no badge visible anywhere!) The listing also detailed that the update was actually two days old.
Four days later, the Mac App Store has finally prompted me to update and the update section shows the proper badge. Very strange.
 



I can check expired certificates with pkgutil:
Code:
pkgutil --check-signature MacOSXServerUpdCombo10.6.7.pkg
   Status: signed by a certificate that has since expired

pkgutil --check-signature MacOSXServerUpdCombo10.6.8.pkg
   Status: signed Apple Software
How can I check when the certificate will expire?
 


I can check expired certificates with pkgutil:

How can I check when the certificate will expire?
Double-click the pkg file; it opens in Installer.

Click the icon in the upper-right corner of the Installer window. It looks like a lock or a certificate icon, depending on the Installer version.

A certificate information subwindow (pane? sheet?) scrolls down, showing the package's certificate information, including expiration date.

Under macOS 10.12, tried this with MacOSXServerUpdCombo10.6.7.pkg. Installer said, "This update requires Mac OS X version 10.6" and would not open the package. Opened it in Mac OS X 10.6. Its expiration date is 2019-10-24 06:29:17 UTC.

Spent lots of time web-searching for a way to do this regardless of booted version, but no luck.
 



I found a great tool called SuspiciousPackage which allows you to inspect all kinds of details about software installer packages, including, on the Package Info tab, being able to view the full certificate chain.
Thanks for the info, Simon and Todd. If the installer can be opened in that system version, in the upper-right corner of the Installer window there indeed is an icon. Clicking it shows the package's certificate information, including expiration date.

But I don't know if that info can be trusted, because a recently downloaded MacOSXServerUpdCombo10.6.7.pkg shows expiration date October 24 2019 while
pkgutil --check-signature
reports its certificate as expired.

Also "Suspicious Package" reports MacOSXServerUpdCombo10.6.7.pkg certificate as expired.

By the way, even if the system clock is turned to 1 February 2016, MacOSXServerUpdCombo10.6.7.pkg won't work, because the installer (like many other older Mac OS X 10.6 combo updaters and VMware Tools installer) fails.

That can be fixed by running "Apple Software Installer Update 1.0", which needs Mac OS X 10.6.8 but can be installed via Pacifist in Mac OS X 10.6.3.

But, luckily, MacOSXServerUpdCombo10.6.8 certificate is updated (also its Installer icon reports expiration date October 24 2019 -- can that be correct?) and Software update still works. Maybe Apple forgot to fix the older installers.
 


…a recently downloaded MacOSXServerUpdCombo10.6.7.pkg shows expiration date October 24 2019 while
pkgutil --check-signature
reports its certificate as expired.
Also "Suspicious Package" reports MacOSXServerUpdCombo10.6.7.pkg certificate as expired.
For what it's worth, I rechecked MacOSXUpdCombo10.6.7.pkg with Installer, pkgutil and Suspicious Package. All were unexpired; those that could showed the 2019-10-24 expiration.

Here's the SHA1 checksum on the file I downloaded from Apple:

15b7c47c814c5544332cd8201e9b5c7248bad26a MacOSXUpdCombo10.6.7.dmg
 




That is the unexpired Retail Mac OS X v10.6.7 Update Combo. I had trouble with the Mac OS X Server v10.6.7 Update Combo that, like older Mac OS X 10.6.x Combo Updaters, also seems to have also other installer-related problems:
Oops, inattentive me. So, yes, for MacOSXServerUpdCombo10.6.7.pkg, pkgutil shows "Status: signed by a certificate that has since expired."

Opening with Installer indicates that it's an intermediate certificate ("Apple Software Update Certification Authority") that is expired, which dead horse has been beaten.

Ditto results from Suspicious Package. The "Software Update" certificate attached to the package shows the 2019-10-24 expiration date.

Hopefully, this is an academic exercise, since one would probably apply the 10.6.8 update rather than 10.6.7. Maybe Apple thinks the same thing.

Admittedly, I checked the 10.6.7 updater only because it was the first listed, and I've not fiddled with any other. Since I don't feel I have time to be further exhaustive, I give up now :)
(though I wonder what will happen after Oct. 24).
 


(though I wonder what will happen after Oct. 24).
After October 24, all software update packages signed with the current certificates will stop working.

I just checked, and all the Combo updaters still being distributed for Mac OS X 10.6.8, OS X 10.7.5, 10.8.5, 10.9.5, 10.10.5, 10.11.6, macOS 10.12.6, 10.13.6, and 10.14.5 [and] are signed with intermediate and Software Update certificates that expire on Oct. 24, 2019.

Apple will need to reissue all the packages signed by new certificates. The last time this happened for the Software Update certificate was in 2012. But then, it happened again in 2015, when the intermediate Software Update Certification Authority certificate expired. At least this time, both the Software Update and intermediate authority certificates are coordinated to both expire on Oct. 24, 2019, so we won't have a bifurcation of package updates.

I'm sure Apple will reissue even older packages, like Mac OS X 10.6.8, because those are being actively served by the Software Update server and will fail if not updated.

I just checked some more, and it looks like even the Install macOS packages, like Install macOS Mojave 14.5.02 created on Mac 13, 2019, are signed with the certs that expire on Oct. 24. So everything will have to be reissued.

Odds on whether Apple remembers to do it before the certs actually expire? Last time, they posted new packages only 3-5 days before the cert expiration.
 



Is there a way to determine the build number from the Install macOS Mojave14.6.app prior to installing? I downloaded (but did not install) 10.14.6 from the App Store a few days ago and hope it is the most recent build.
From the Terminal:
  • hdiutil attach -readonly -noverify '/[path-if-not-in-current-directory]/Install macOS Mojave.app/Contents/SharedSupport/BaseSystem.dmg'
  • defaults read '/Volumes/macOS Base System/System/Library/CoreServices/SystemVersion.plist'
  • hdiutil detach '/Volumes/macOS Base System'
You can leave off -noverify if you want to check the disk image integrity, but it adds time and is not particularly pertinent to checking the build number. You can also 'cat' instead of 'defaults read', but the latter's output is slightly better formatted.
 


Wow... what a [mess]. I mean, for me, I save the installers (OS X 10.10 through macOS 10.14), because I deal with updating Macs.

Not all can be on Mojave, but most should be on High Sierra. Every once in a while I come across an orphan Mac that is on Yosemite, but I prefer a subtle OS upgrade, not a leap to Mojave (some user apps break... like Dragon Speak dictation).

The date trick used to work... but no more.

Funny, many Windows 7/8 machines I've updated work well on Windows 10.
 


The date trick used to work... but no more.
Would you be a little more specific about the "date trick" no longer working? I don't recall exactly which OS it was, but I am certain I've used the date trick at least once in the last year when I didn't have access to broadband and had to use an old installer to rescue an old system.

That said, I do expect that the date trick will grow increasingly difficult as time goes on, especially for updates (as opposed to clean installations). Now that so much software is signed against certificates, using the date trick to set the clock back to install older software can throw enormous numbers of security warnings and notifications.

I wouldn't be surprised if we soon find ourselves in situations where systems won't function at all if the system date is set outside of a valid certificate range.
 


Funny, many Windows 7/8 machines I've updated work well on Windows 10.
I know that not all Windows 7 machines work well (or at all) with current releases of Windows 10, but I confess to having been impressed with how well machines that are quite old can run it.

Just for kicks, I installed Win10 on a 2006 Dell with 4 GB RAM that originally shipped with XP. It's certainly no speed demon, but it is surprisingly adequate for running basic office software and web browsing. The only thing I had to do to get it to work well as to replace the original video card with an entry level card I bought for $20. It also runs surprisingly well, albeit with some glitches, on an original 2006 MacBook.

I don't love everything about Win10 (actually quite prefer Win7), but Microsoft deserves credit for building a mainstream OS that works on such basic hardware.
 


From the Terminal:
  • hdiutil attach -readonly -noverify '/[path-if-not-in-current-directory]/Install macOS Mojave.app/Contents/SharedSupport/BaseSystem.dmg'
  • defaults read '/Volumes/macOS Base System/System/Library/CoreServices/SystemVersion.plist'
  • hdiutil detach '/Volumes/macOS Base System'
You can leave off -noverify if you want to check the disk image integrity, but it adds time and is not particularly pertinent to checking the build number. You can also 'cat' instead of 'defaults read', but the latter's output is slightly better formatted.
Thanks! Looks like I got the latest version:
Code:
 ProductBuildVersion = 18G95;
 


That said, I do expect that the date trick will grow increasingly difficult as time goes on, especially for updates (as opposed to clean installations). Now that so much software is signed against certificates, using the date trick to set the clock back to install older software can throw enormous numbers of security warnings and notifications.
Not having access to broadband does the trick quite nicely, in combination with setting the system clock back to within 2 years of the release date of any particular update.

If you do have broadband, you will need to pull the plug or deactivate the Wifi to prevent phoning home from revealing your system clock trick.
 


Not having access to broadband does the trick quite nicely, in combination with setting the system clock back to within 2 years of the release date of any particular update. If you do have broadband, you will need to pull the plug or deactivate the Wifi to prevent phoning home from revealing your system clock trick.
The potential issue for updates (as opposed to clean installations) is that certificates don't just have expiration dates; they have "not valid before" dates, too.

As a result, especially if the intention is to install older software on top of an already working system, it's conceivable to run into a situation where the installer certificate's expiration date precedes the "not valid before" date of the system software already installed on the system, leading to unexpected behavior.

For example, a future version of macOS may have a "not valid before" date of April 1, 2023. An attempt to set the system clock to, say, September 5, 2019 to accommodate an old app installer might then result in a wide range of problems, even without a network connection.

It's not a stretch to imagine scenarios where a future firmware iteration won't allow the system to boot into the OS if there is an attempt to set the system clock earlier than a certain "not valid before" date. I'm just speculating, of course, but I fully expect that we will start seeing this sort of thing on many platforms. (Perhaps it's already the case on some systems, and I just haven't run into it yet.)
 


I don't think that the "not valid before" check would work in the wild. If a machine loses power and has the clock reset to 0 (bad motherboard battery, etc.), that timestamp would probably be well before the validity date of the certificate. So the system could never startup enough to get the correct time.

Of course, there could be stages of startup that would limit features until the clock gets set to a reasonable value. Your definition of reasonable may vary with Apple's definition :)
 


Is there a secret Apple download link for Mojave now? I haven’t been tracking the Catalina release date, and never got around to downloading Mojave from the App Store, because I was waiting for it to be fully baked. Apple grudgingly provided a way to get Sierra after High Sierra came out, so I am hoping something similar exists for Mojave.
Wow, I didn't realize that a search for macOS Mojave on the App Store would turn up nothing. Luckily I downloaded the latest installer. But what happens if I have to restore my system from the recovery partition? Will it force me to Catalina?
 


Apple seems to provide direct App Store links to all installers since El Capitan here:
I've not tried it myself except to confirm that the Mojave link does indeed open the App Store to a page with the current version of Mojave (10.14.6). So, no need for a combo updater to update (these are still listed at sites such as osxdaily.com).
While the Mojave installer was on the App Store yesterday, I just this morning tried to download the earlier macOS versions (Sierra and High Sierra) from the App Store using those links and the Software Update panel opened but then could not find the older OS versions.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts