User Profile

Thanks for that information! TL;DR - So far in my testing it appears that all of our installer packages that we care about actually have the trusted timestamp, and they do appear to be able to install properly on older OS versions even if the Developer ID Installer cert used to sign them has since expired. Yay! The TL part: Finally circling back to this, I had to do some digging to understand the details of exactly how we handle our software archives for users. The concerning thing in the linked post was some ambiguity over where the trusted timestamp would apply to older macOS versions... as one of the main reasons for our software archive is to allow folks who are stuck on an older (no longer officially supported by us) macOS version. We provide a chart of which build versions should work with which macOS versions (i.e. versions of our software that we tested/validated with a given OS version). We don't officially support all of these old OS versions; with the current release we only support back to 10.14. But we provide the old builds for people on older OS versions. The software archive chart looks something like so: macOS version / Tested software versions macOS Monterey / v10.0.0 and higher macOS 11 Big Sur / v9.13.1 and higher macOS 10.15 Catalina / v9.11.1 and higher macOS 10.14 Mojave / v9.8.0 and higher macOS 10.13 High Sierra / v9.4.0 through v9.14.5 macOS 10.12 Sierra / v9.0.0 through v9.13.0 OS X 10.11 El Capitan / v8.5 through v9.9.0 OS X 10.10 Yosemite / v8.0 through v9.5.0 OS X 10.9 Mavericks / v7.0 through v9.0.0 [This list actually continues to even older versions! But those generally pre-date when we switched to installer .pkgs, prior to that we were using VISE, and the installer was a standalone .app. Back then things were not even signed too. I doubt there is anyone still using OS versions that old, but the installers for our stuff that works on those OS's are there if necessary... in any case, software and OS versions that old are not affected by this particular issue.] Obviously this includes a huge number of installer .pkgs. Rather than check all of them, I picked some representative old builds, including one of the oldest .pkg versions that was signed (the Developer ID Installer cert used to sign it had already expired), and tested these builds on Mavericks and Mojave. I also checked pkgutils --check-signature on the installers on those versions. The short answer is, even the super-old pkg signed with the now-expired cert seems to work. Catalina pkgutil reports a trusted timestamp. Mavericks/Mojave reports "signed by a certificate trusted by Mac OS X". This seems to be the equivalent on an older OS for saying the trusted timestamp is there, and indeed seems to trigger the identical check used for Developer ID signed apps, i.e. it allows the install since the .pkg was valid when it was signed. For that case (now-expired cert) the lock icon in the installer reports that the cert has expired, but still says it's valid. I was kind of surprised to see that such an old installer .pkg reported it was signed with the trusted timestamp, we're talking like 2014 timeframe. Back then I believe our build machines were running Maverics, so those packages were signed with a pretty old version of productsign. But it appears it must have supported the the trusted timestamp thing even back then. So the net result is that it does appear that all of the installer packages in our software archives that we care about actually do work properly. This is good because while we could pretty easily re-sign the installers, for the ones that are notarized we'd have to re-notarize them. And notarization is a problem for a subset of those installers because they were notarized during the early days of notarization when certain now-hard requirements (that we didn't satisfy at the time) were temporarily relaxed before being enforced later, so those installers will fail notarization. But bottom line, it seems like we don't need to do that, so yay! This post was also quite helpful: https://eclecticlight.co/2022/02/08/why-do-installer-packages-expire-but-apps-dont-signing-certificate-and-notarization-oddities/