write special slots for count actually requested - #90
Conversation
`codesign.Config` includes an `NSpecialSlots` which is computed by `codesign.Sign`, but `codesign.createCodeDirectory` always writes exactly 7 or 2 special-slot hashes depending on the presence of entitlements. Sometimes (e.g. for libraries) we need to write 3 to conform with apple tooling; supplying 7 will result in a warning from Apple about incorrectly signing in entitlements, but supplying only 2 results in a validation failure due to lack of sealed resources.
|
Thanks for this, and thanks again for the past fixes you’ve sent over. I appreciate the context here; the 3-slot case makes sense and the direction looks right. I took a closer look before merging and found one edge case we should handle first. The new writer builds a fixed list of 7 known special slots, but when re-signing an existing binary we can inherit more than 7 special slots from the parsed CodeDirectory. This repo already knows about slots 8-11 for launch/library constraints, so with one of those signatures the new slice can panic instead of returning an error or preserving the extra slots. I don’t think this invalidates the PR; it just needs a small guard/follow-up before merge. Either preserving/writing the known slots beyond 7, or returning a normal unsupported-slot error before slicing, would make this much safer. A small regression test for the 3-slot resource-directory case plus a |
2 participants
codesign.Configincludes anNSpecialSlotswhich is computed bycodesign.Sign, butcodesign.createCodeDirectoryalways writes exactly 7 or 2 special-slot hashes depending on the presence of entitlements. Sometimes (e.g. for libraries) we need to write 3 to conform with apple tooling; supplying 7 will result in a warning from Apple about incorrectly signing in entitlements, but supplying only 2 results in a validation failure due to lack of sealed resources.