transmission: Potential signing issue with libiconv

[Gandoon (Erik Hedlund)]

This is essentially a follow-up to the now closed ticket #67359. Originally I had some problems building the new Transmission 4, but I had a weird libxml2 error that kept bugging me. That was indeed solved as it seemed to be down to a stale modulemap on my system that frustrated the build.

However, despite a subsequent successful build then a new problem arose: The application crashes immediately with a dyld error message:

Process:               Transmission [14814]
Path:                  /Applications/MacPorts/Transmission.app/Contents/MacOS/Transmission
Identifier:            org.m0k.transmission
Version:               4.0.5 (14714.4.0.5)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Transmission [14814]
User ID:               502

Date/Time:             2024-04-30 14:23:55.259 +0200
OS Version:            Mac OS X 10.15.7 (19H2026)
Report Version:        12
Anonymous UUID:        * * *


Time Awake Since Boot: 12000 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x5] Code Signature

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: /opt/local/lib/libiconv.2.dylib
  Referenced from: /Applications/MacPorts/Transmission.app/Contents/MacOS/Transmission
  Reason: no suitable image found.  Did find:
	/opt/local/lib/libiconv.2.dylib: code signature in (/opt/local/lib/libiconv.2.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
	/opt/local/lib/libiconv.2.dylib: stat() failed with errno=1
 .
 .
 .

There is no problem when building Transmission with code directly from the GitHub repository, so I am suspecting there may be something funny going on with MacPorts' libiconv. As suggested in #67359, I start this new ticket for the libiconv issue, in case this is something that should and can be fixed on the MacPorts side.

[ryandesign (Ryan Carsten Schmidt)]

There's nothing funny going on with libiconv. The files it installs are unsigned, just like almost all other ports.

[kencu (Ken)]

although I have no idea why you are seeing this code sign issue….my first thought would be to uninstall and then reinstall libiconv.

If I saw the same error again, I’d rebuilt it from source.

And if that didn’t help, I would ask again here in this ticket for ideas.

[Gandoon (Erik Hedlund)]

Replying to ryandesign:

There's nothing funny going on with libiconv. The files it installs are unsigned, just like almost all other ports.

Then I am at a loss with respect to the transmission @4.0.5_0 issue. It builds but refuses to run according to the above. I am beginning to think that it is a lost cause trying to get the MacPorts build to run on this system. The prior version, @3.00_1 used to not complain about anything and run just fine but now it segfaults on start.

I did a port -v -n upgrade --force libiconv and a port -v -n upgrade --force transmission, in that order (I have build from source set as a default) and the results are the same. I further did a port -v uninstall libiconv && port -v clean --all libiconv and subsequent rebuild – Transmission still suffers the same dyld crash.

I can't see what else I could do easily. As I mentioned, I built Transmission, the originating issue, from the GitHub repository and it works just fine. Maybe I should just give up on the Transmission port?

[kencu (Ken)]

my insights into troubleshooting codesigning issues is not strong.

this is not AFAIK a systemic macports issue. more likely something local on your machine.

next thing I would do is uninstall libiconv and transmission, then reboot, then reinstall them.

and if that didn’t work I would completely blow out macports, remove all traces of it, then reinstall macports and then transmission.

sounds drastic maybe, but takes 10 minutes rather than the hundreds of hours you’ve spent already.

[kencu (Ken)]

while you’re doing that, do a cleanup. empty out /usr/local so nothing is in there. Remove any code you added to your shell startup files. Make sure your Xcode and CLTs are the last ones available for your system. Get rid of any hacks or symlinks you put anywhere for SDKs, etc.

clean house.

[Gandoon (Erik Hedlund)]

Replying to kencu:

my insights into troubleshooting codesigning issues is not strong.

this is not AFAIK a systemic macports issue. more likely something local on your machine.

next thing I would do is uninstall libiconv and transmission, then reboot, then reinstall them.

and if that didn’t work I would completely blow out macports, remove all traces of it, then reinstall macports and then transmission.

sounds drastic maybe, but takes 10 minutes rather than the hundreds of hours you’ve spent already.

That may be a bit optimistic as I am building from source on a ten year old machine with an OS several years old (still running Catalina for compatibility reasons). ;)

I am somewhat hesitant to do anything too drastic as I aim to get a fresh machine as soon as my economy allows it, and this machine will have to so serve me until I can secure the job that solves that issue. I guess I will continue to mainly patch the cracks as they present themselves. I can live with a non-essential port being somewhat broken for now, as long as the rest works as intended.

[kencu (Ken)]

why are you building everything from source again? The buildbot spews out fully prebuilt binaries for you to make this easy.

Up to you how you spend your time ... personally, I am always very reluctant to spend time building things on a system that I cannot trust. It is just too much time wasted chasing dragons that should not exist.

MacPorts (and all software building) really only works right on a clean, stock, pristine system with no warts. If I sense inconsistencies like I do in your setup, I get very concerned.

[jmroot (Joshua Root)]

The error indicates that the Transmission binary is signed (and using the hardened runtime?), which means it's not allowed to load any unsigned libraries. The fix is to either not sign Transmission, or sign all the libs it links with (it looks like even ad-hoc signing will suffice).

[jmroot (Joshua Root)]

I see the Portfile does this:

# Hardened Runtime on 10.14 is not compatible with AdHoc signing
if {${os.major} == 18} {
    xcode.build.settings-append \
                ENABLE_HARDENED_RUNTIME=NO
}

Perhaps this just needs to be extended to 10.15, and possibly later OS versions?

[ryandesign (Ryan Carsten Schmidt)]

The binary of transmission 4.0.5_0 for x86_64 macOS 12 that I received from our packages server opened fine and did not complain about libiconv. (But I am using macOS 12 on an unsupported Mac via OpenCore Legacy Patcher; I am not certain whether that affects or possibly even disables the hardened runtime.)

Before receiving the binary that worked fine, I got this strange message:

transmission is known to fail. Try to install anyway? [y/N]: y

[jmroot (Joshua Root)]

Replying to ryandesign:

Before receiving the binary that worked fine, I got this strange message:

transmission is known to fail. Try to install anyway? [y/N]: y

That would be because this port inadvisably sets known_fail based on xcodeversion, which is presumably not new enough on the machine that generated the PortIndex.

[kencu (Ken)]

Replying to ryandesign:

Before receiving the binary that worked fine, I got this strange message:

transmission is known to fail. Try to install anyway? [y/N]: y

I got that too when I tried to build this on 10.15 this morning to see what was going on here.

Turns out it gives this error if you don't have a full Xcode installation.

That error should probably be improved.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

That would be because this port inadvisably sets known_fail based on xcodeversion, which is presumably not new enough on the machine that generated the PortIndex.

Ah, that must be it.

Replying to kencu:

Turns out it gives this error if you don't have a full Xcode installation.

I do have a full Xcode installation.

[kencu (Ken)]

Replying to ryandesign:

Replying to kencu:

Turns out it gives this error if you don't have a full Xcode installation.

I do have a full Xcode installation.

It also gives this same error if you don't have one, though.

[Gandoon (Erik Hedlund)]

Replying to kencu:

Replying to ryandesign:

Replying to kencu:

Turns out it gives this error if you don't have a full Xcode installation.

I do have a full Xcode installation.

It also gives this same error if you don't have one, though.

It was interesting to see the recent input. Inspired by it, I tried setting:

# Hardened Runtime on 10.14 is not compatible with AdHoc signing
if {${os.major} == 19} {
    xcode.build.settings-append \
                ENABLE_HARDENED_RUNTIME=NO
}

in the portfile to make it catch my MacOS 10.15. This threw the same "This will fail" message before proceeding to building. After telling it to go ahead anyway, it did build as expected and the application starts and works as intended. The only thing is that one has to explicitly allow network connections when starting the application.

So as for my issue, I consider this matter solved. For the port in general, I expect the easiest solution is to extend the portfile to include something along the lines of:

if {${os.major} == 18 || ${os.major} == 19}

Thank you all.