I've filed FB22826737 requesting an improvement to this message. An update about this issue. Apple has addressed this in a Beta version of the upcoming macos 27 release. I was notified on the feedback assistance issue asking me to verify the fix. I verified it on a macos 27 Beta3 and it has indeed been addressed. Specifically, on a pre-existing signed binary which has a timestamp mismatch in the signature, when using "codesign" to replace the signature with an "adhoc" one, "codesign" no longer prints the timestamp mismatch warning and no longer exits with a non-zero exit code. The signature is successfully replaced on the binary. Thank you for addressing this so quickly and also for being responsive on the feedback ticket.

It's been more than a year and I still miss the ability to view the activity/profile of specific "DTS Engineer"s in this forum. Is this something that can be considered, please?

maybe the timestamp difference message should be a warning and the tool should exit with an exit code of zero? Agreed. Again, I’d appreciate you filing a second bug about that. Filed FB22826836 for this one, under "Developer Technologies & SDKs" -> "macOS" -> "Something else not on this list".

This gives the wrong impression that the timestamp difference is on host H2 … while in reality the tool is merely reporting the difference that was present in the previous signature (on host H1). Ah, yeah, I can see how that’d happen and also how it’s super confusing. I think you should file a bug against codesign for better diagnostics here; please post your bug number, just for the record. Done. I've filed FB22826737 requesting an improvement to this message. I couldn't find the exact category to file this under (couldn't locate codesign tool in any of the categories). So I used "Developer Technologies & SDKs" -> "macOS" -> "‌Something else not on this list". I hope that's fine.

Thank you Quinn for these additional details. In the meantime, we have been able to make some progress here. To recap, the error message we have been investigating is the following one when codesign command is executed on a host, let's say H2, to do "adhoc" signing of some binary: $> /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app /home/me/FooBarCalculator.app: replacing existing signature /home/me/FooBarCalculator.app: signed app bundle with Mach-O thin (arm64) [Hello] /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock codesign then exits with a non-zero exit code and thus errors out. Our investigation so far shows that the message about timestamps differing turns out to be misleading. What we have been able to narrow down is that, if on some host H1, a binary (FooBarCalculator.app in this case) was signed with a (valid) identity and if for whatever reason, during codesigning there was a timestamp difference, then that difference gets embedded in the signed binary. This part is fine, because you already explained how the timestamp values get stamped within the signature and are stored in the 2 fields. Of course, it's a different matter that we should investigate why that timestamp difference happened during signing. What's confusing and what has been causing us trouble is that when that signed binary is then copied/downloaded over to some other host (H2 in this case) and when we try to "adhoc" sign that binary using codesign tool (for some specific reasons), then the tool when running on host H2 tries to replace the signature (which is understandable). During that replacement, it notices that the previous signature on that binary has the timestamp difference (embedded in that signature) and thus writes out that "timestamps differ by 185 seconds - check your system clock". This gives the wrong impression that the timestamp difference is on host H2 and happened when the "adhoc" signing was going on, while in reality the tool is merely reporting the difference that was present in the previous signature (on host H1). It might have been slightly more useful if the message included the timestamps that mismatch (like it does when codesign -dvvv is used). So something like the following would have been more useful: /home/me/FooBarCalculator.app: timestamp mismatch: Timestamp=12 May 2026 at 4:18:27 PM, internal time 12 May 2026 at 4:15:22 PM (185 seconds apart) Those actual timestamps might have given us hints that the message is about the existing signature. What's more interesting is that even if codesign reports this message and exits with a non-zero exit code (implying an error), it goes ahead and updates the binary with an adhoc signature. It's not clear if it should be doing that. If it's indeed OK to update the binary with the adhoc signature after reporting this error, then maybe the timestamp difference message should be a warning and the tool should exit with an exit code of zero? P.S: Investigation is still going on to understand why the original binary which was signed using a valid identity ended up having the timestamp difference. But that issue is a bit more easier to investigate, because we can now actually check the timestamp on the right host(s) and check the timestamp authority server in use, when the codesigning is in progress.

Oh, there is one thing I can add. In this bug you asked whether we can reproduce the problem, and I can confirm that, yes, we can. Thank you Quinn, that's what I was interested about. I wish at some point the feedback assistant issues will receive answers to basic questions like these. Thank you very much for taking a look.

Thank you Quinn, this is helpful. I just read up the contents of the header file you note and the comments on those fields are clear. So I suspect that the Mac doing the signing has a clock that’s way of sync with reality, so these two values end up significantly different, and thus this problem. I read through the linked TN3161: Inside Code Signing: Certificates | Apple Developer Documentation and it says that it contacts timestamp.apple.com for getting a secure timestamp. Is there a tool that I could use to directly issue a similar request against that server and see what it returns? That might help us debug this on many of these hosts where this happens intermittently. As far as I can see, there's no option/flag in codesign which would allow us to print verbose logs showing it communicating with the timestamp authority server. One other question, that doc also says: Don’t confused the Timestamp and Signed Time fields. The latter is not secured by the Apple timestamp service. Rather, codesign sets this field based on your Mac’s current time. I think it corresponds to the kSecCodeInfoTime field we are discussing here. Would you happen to know, what API the codesign tool uses in its implementation to obtain the host's current time?

Hello Quinn, would it be possible to take a look at FB21686886 and see if it's being investigated? That issue has forced us to disable several tests in our testsuite to prevent those failures. Disabling those tests means that it has reduced coverage for some of the APIs these tests were testing. I have asked on that feedback issue (more than once) whether the issue has been reproduced with the inputs provided so far and/or if any further inputs are needed, but I haven't heard back on it.

Thank you Quinn, I've now created FB22455033

Once you’re done, please post your bug number, just for the record. Thank you Quinn, I've now filed FB21686886. And thanks, as always, for your efforts here. Your test suite is certainly doing its bit to keep us honest (-: I'm happy to help :) The OpenJDK testsuite is indeed vast. One of our bigger challenges in recent times has been trying to get a resolution for several stability issues/regressions with BSD socket APIs on macos. I'm glad that these dev forums exist and there are knowledgeable engineers from Apple who regularly respond and provide help. That helps stay motivated to investigate these issues and report them. Feedback assistant tool on the other hand is a bit of a disappointment - lack of any response and visibility on the filed issues there for several months/years even for basic questions makes it a bigger challenge to take such reported issues to a proper resolution. Hopefully that tool/process will see some improvement in future. Thanks again for the help.

After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached) Looks like I forgot to attach that file (at least I can't see it attached in this thread) and I can't edit the original post. So attaching it here: sockbufspaceerr.c

I don't have knowledge of the xnu kernel code, nor do I have an easy/quick way to debug/investigate this issue myself. However, a very brief look at the socket code seems to suggest that when a socket fd is closed using "close(fd)", like in that reproducer, the necessary decrement of memory accounting doesn't seem to be happening. Very specifically, it looks like the sodealloc(...) in bsd/kern/uipc_socket.c seems to be responsible to "releasing"/decrementing the memory accounting counter here https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L797. Looking at the soclose_locked(...) function in that same file, it calls sofree(so) here https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L1332. The implementation of sofree(struct socket *so) then calls sofreelastref(so, 0) https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L7315. The second param there is dealloc and is being passed a value of 0 indicating "don't deallocate". So the implementation of sofreelastref(...), then skips the deallocation call to sodealloc(...) https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L1074 - the one which is responsible for decrementing the memory accounting counter. Like I said, I have zero knowledge of this code, so it's possible that I maybe looking at completely unrelated code. If so do let me know (that will help me in future when looking into such issues).

Thank you Quinn.

For now, I will just write up these steps and share here. For future reference, I've now written it up here https://jaitechwriteups.blogspot.com/2025/10/boot-custom-macos-kernel-on-macos-apple.html It's been a very long time since I've done this, but the main thing I remember is that you need to be very careful to ensure that you've exactly matched up versions so that "everything" is the same exact version (kernel source, KDK, developer tools, etc.). Thank you Kevin for that hint. I suspected it wouldn't be straightforward. It's still on my TODO list to experiment with that and hopefully get it to work in the coming weeks. If it does, then it will help in a big way in debugging (and reporting) some of the issues we have been running into recently.

OK, so this is the part I haven't explained as well as I should. You don't actually need to build the kernel, as you already have a development build of the kernel in the KDK. That's what "kernel.development.t6020" and "kernel.kasan.t6020" installed by the KDK in /System/Library/Kernels "are" That was it - I built a kext collection using this pre-shipped kernels in the KDK and I was then able to boot this "custom" kext collection without any issues. I used the kernel.development variant for my test. Upon boot I even verified that it was indeed using the development variant of the kernel: $> sysctl kern.osbuildconfig kern.osbuildconfig: development Thank you very much Kevin for this very valuable help. I have several other things to read and try out (including hopefully building a trivially modified kernel version from xnu sources and booting it), but this initial step had blocked me for several months to even think of these additional experiments. For now, I will just write up these steps and share here. Thank you again.