unzip identifier is not unique?

Question

Created Aug ’25

Replies 4

Boosts 1

Participants 2

In Swift I'm using unzip by launching a Process to unzip a file. I added a launchRequirement to the process in order to make sure the executable is code signed by Apple and the identifier is com.apple.unzip. After testing out my code on another machines (both physical and virtual), I found out that in some the identifier is actually com.apple.zipinfo, which broke the SigningIdentifier requirement.

It's safe to assume that /usr/bin/unzip can be trusted since it's in a System Integrity Protection (SIP) location, but I'm wondering why this executable has different identifiers?

Answered by DTS Engineer in 853288022

So, in terms of what you should do, I think that a simplified LWCR makes sense here, namely to just check for a validation category of .platform. You’re running these programs via their full path, and if someone manages to replace /usr/bin/unzip with another program that meets the .platform requirement, further checking is unlikely to stop them.

In terms of what Apple should do, we’re still discussing that internally. I may end up filing a bug about this, but I don’t think that’ll affect you. That is, you can follow the above advice regardless of how things pan out on the Apple side.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’25

Accepted Answer

Consider this:

% ls -i /usr/bin/zipinfo /usr/bin/unzip | cat
1152921500312524002 /usr/bin/unzip
1152921500312524002 /usr/bin/zipinfo

unzip and zipinfo have the same inode number, meaning that they are both hard links to the same file. That’s why you’re seeing inconsistent signing identifiers. I suspect that the OS build process is signing one and then signing the other, and you get the identifier for whichever one it did last. That’s curious, and it’s something that I’d like to file a bug about.

Before doing that I’d like to nail down the details as to where you see which behaviour. I tested this locally and I always see com.apple.zipinfo:

% codesign -d -v /usr/bin/unzip
…
Identifier=com.apple.zipinfo
…

This was on macOS 14.x, macOS 15.5, and macOS 26.0 beta. Where are you seeing com.apple.unzip?

As to what you should do in your app, you can craft an LWCR that supports either identifier:

let lwcr = try LaunchCodeRequirement.allOf {
    ValidationCategory(.platform)
    anyOf {
        SigningIdentifier("com.apple.unzip")
        SigningIdentifier("com.apple.zipinfo")
    }
}

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

apinho-lp OP

Aug ’25

Thank you for the detailed response Quinn! I'm seeing com.apple.unzip on macOS 15.6.

0

Answer 3

DTS Engineer OP

Apple

Aug ’25

Thanks for that info.

I saw your post first thing on the forums this morning, so I started the update process for a VM. And now I’m almost done with the forums and the VM has finished upgrading and, lo!, I see the same thing you do.

And now I’m off to ask about this internally.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 4

DTS Engineer OP

Apple

Aug ’25

Recommended

So, in terms of what you should do, I think that a simplified LWCR makes sense here, namely to just check for a validation category of .platform. You’re running these programs via their full path, and if someone manages to replace /usr/bin/unzip with another program that meets the .platform requirement, further checking is unlikely to stop them.

In terms of what Apple should do, we’re still discussing that internally. I may end up filing a bug about this, but I don’t think that’ll affect you. That is, you can follow the above advice regardless of how things pan out on the Apple side.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1