Many, maybe all, binaries generating "code object is not signed at all" -67062 errors in Console

[1dolla]

Hello :)

First of all, I'm unsure where this report belongs. I was on github, and thought the issue ought to be reported on the "mpbb" repo, but tickets apparently need to be made here. Also, I don't know if this is just on High Sierra, or perhaps on all targets, but either way, this is the thing:

I was trying to debug a wholly unrelated issue, and was befuddled about a seemingly endless stream of "taskgated: MacOS error: -67062" errors.

Google led me to a perl script here: ​https://apple.stackexchange.com/a/411062/35944 . This allows me to get details on which binaries are causing these errors as they occur. The results is that I found that it seems like (not necessarily is so) that none of the binaries I've installed from MacPorts have been signed at all. coreutils, findutils, git, par2, cksfv, zsh, etc. All generate a -67062 error as they're executed.

I know that this isn't a functional problem, as the binaries will run just fine. But the extreme amount of errors generated because of this clutters the log, and makes it really difficult to use the log to debug other issues. I'm thinking it must have some impact on performance as well.

In the StackExchange answer I linked to, the poster also points to the solution: Simply sign the binary with any certificate, even a self-signed one.

I guess could do this myself, but for one, I'd need to then re-sign port binaries after every install and update, and also it seems like it's a bug or bug-like issue with MacPorts, at least on High Sierra binaries, that you might want to know about, so here's the report :)

Thank you for a fantastic software manager, and for your dedication to supporting legacy OSes!

Silas

[ryandesign (Ryan Carsten Schmidt)]

To which log are you referring?

On Apple Silicon, all binaries are signed because they cannot run otherwise. This is accomplished automatically by the compiler, linker, etc. and no extra code was added to MacPorts to accomplish this. On Intel and PowerPC processors, nothing MacPorts installs is signed, unless a port's build system specifically does so, and we were not aware of any negative consequences of that.

[ryandesign (Ryan Carsten Schmidt)]

mpbb just runs MacPorts to install ports. If everything needs to be signed, it would happen in MacPorts base.

[1dolla]

Replying to ryandesign:

To which log are you referring?

On Apple Silicon, all binaries are signed because they cannot run otherwise. This is accomplished automatically by the compiler, linker, etc. and no extra code was added to MacPorts to accomplish this. On Intel and PowerPC processors, nothing MacPorts installs is signed, unless a port's build system specifically does so, and we were not aware of any negative consequences of that.

Sorry, this is on Intel. I navigated to the High Sierra section in the issues tree before searching and eventually clicking "New ticket," so I thought I was creating a High Sierra-specific ticket, but of course it doesn't work like that :)

I was referring to the system log that display in Console. Not sure what this is in other terms, I'm mostly used to Linux logs.

Replying to ryandesign:

mpbb just runs MacPorts to install ports. If everything needs to be signed, it would happen in MacPorts base.

Thank you for moving my ticket.

I tried signing all the MacPorts binaries with a self-signed code signature certificate, and this has gotten rid of the taskgated error messages in Console, but of course this is just a temporary fix on my end.

Thanks again :)

[ryandesign (Ryan Carsten Schmidt)]

If we do need to sign everything on some Intel versions of macOS, then someone would have to write the MacPorts base code to do that. But more than that, we would somehow need to communicate to all MacPorts users on those OS versions that all ports they've installed should be reinstalled, and we would somehow need to cause our automated build system to rebuild all packages on those OS versions. Such a rebuild would be a colossal undertaking that would likely keep our build machines busy for months. (We have almost 40,000 ports in MacPorts now.)

[1dolla]

Replying to ryandesign:

If we do need to sign everything on some Intel versions of macOS, then someone would have to write the MacPorts base code to do that. But more than that, we would somehow need to communicate to all MacPorts users on those OS versions that all ports they've installed should be reinstalled, and we would somehow need to cause our automated build system to rebuild all packages on those OS versions. Such a rebuild would be a colossal undertaking that would likely keep our build machines busy for months. (We have almost 40,000 ports in MacPorts now.)

To the extent that you think it at least in principle would be a good idea to change, perhaps just builds going forward being signed would suffice. I assume I'm the first to report on this (I couldn't find any other)? That should speak to how big of an issue this is with people :)

There's also the question of how this would work when binaries are built on the user's machine. Obviously those can't be signed with a MacPorts certificate, since that part of it would be private...

Perhaps an option in port could handle this, and possibly allow for signing with a local certificate.

Again, if it's even something you consider :)

Either way, thanks for listening to me :)

[ryandesign (Ryan Carsten Schmidt)]

As I said we were not aware that not signing caused a problem on Intel and I have also not attempted to verify your claim that it causes an error in the console log.

It would work on user machines identically to how it works on the buildbot and CI machines: with ad-hoc signing. There is no MacPorts signing certificate that could be used. The only "real" signing we do of anything is the MacPorts installer package signed with Josh's certificate and I recall him previously saying that there's no way he would consent to signing tens of thousands of other people's software with his certificate.

[kencu (Ken)]

I guess step one would be to see if there is any other user with a log full of these errors.

I have never noticed any such errors, myself.

[1dolla]

Just so that you can test for yourselves, I just spent some time (unrelated) setting up Sonoma on a Mac mini (also Intel, the 2018 version). The log messages are different here, but if you wanna check it:

1) Pick a port binary — I chose ffmpeg 2) Open Console.app and start streaming messages 3) Filter for "ffmpeg" 4) Execute ffmpeg in a terminal, e.g. "ffmpeg --help" 5) Watch console output, e.g. "map_with_linking_np: [94862(ffmpeg)]: region 0, not code signed" (Sonoma — on High Sierra the message was the above cited).

Cheers :)