Signing from scratch seems to currently be broken #17
Comments
|
Another thing I forgot to mention is that I've also modified Signable diff --git a/isign/signable.py b/isign/signable.py
index 6cc2e14..fc2c522 100644
--- a/isign/signable.py
+++ b/isign/signable.py
@@ -82,7 +82,12 @@ class Signable(object, metaclass=ABCMeta):
self.f.seek(codesig_offset)
codesig_data = self.f.read(arch['lc_codesig'].data.datasize)
# log.debug("codesig len: {0}".format(len(codesig_data)))
- else:
+ codesig = Codesig(self, codesig_data)
+ if len(codesig.get_blobs('CSMAGIC_ENTITLEMENT')) == 0:
+ log.debug('Existing LC_CODE_SIGNATURE missing entitlements')
+ codesig = None
+
+ if codesig == None:
log.info("signing from scratch!")
self.sign_from_scratch = True
entitlements_file = self.bundle.get_entitlements_path() # '/path/to/some/entitlements.plist'since I was seeing that even my binaries that haven't been explicitly signed before do still have an LC_CODE_SIGNATURE command but I think it's somehow incomplete for what isign expects. It's able to parse it fine but a missing CSMAGIC_BLOBWRAPPER results in this failure: |
|
Hmm, I just found this pull request against the saucelabs repo that's still open that might help here: sauce-archives#97 |
|
Although it looks like @ryu2's changes are actually merged in this fork it looks like it has maybe bitrotted somewhat. It looks like it uses a version of the construct module < 2.8 and the online reference manual no longer documents that version - making it a little awkward to debug. The construct module has then had multiple really-major API breaks for 2.8 and then again for 2.9, including renaming all the integer types and switching to a field-name/type syntax magic. I took a stab at forward porting but basically gave up for now. Atm I feel like it would almost be easier to re-write this with Python's built in struct parsing api. Based on the history it looks like the construct API is not stable and therefore this feature is currently built on quick sand :/ |
|
Experimenting with @ryu2's fork and cherry picking my own recent changes I can get it to sign my package from scratch, but then the limitation for me is that the fork is missing the sha256 updates that are in this fork. |
|
I bit the bullet and dug into this further and got something that's at least much closer to working but unfortunately still not quite working :/ At least it no longer has any exceptions and comparing Here's what I've experimented with: It's a very messy commit with lots piled together but in case I do run out of energy it might be useful for someone else. |
|
Hi @rib I checked out your WIP branch and after a few tweaks to Here's the diff: Thanks for doing this! |
|
@ur0 this is a python3 fork. We use |
|
@rib this is an awesome write-up. I am currently debugging your PR. |
|
@rib I can merge the |
|
@ur0 i'm not sure about the setup.py change since as far as I saw there was no 2.5.5 version I could install for constructor (via pip) but there was a 2.5.5-reupload. Also it really does depend on biplist so not sure about removing that depends from the list. (I suppose you happen to already have it installed?) @subho007 actually this branch ended up reverting the python3 porting because I was initially having problems that seemed python3 related, so this branch depends on python 2 again. I think I indirectly figured out the python3 issue while I was debugging this so maybe could revisit this at some point and keep the python3 support. |
|
@rib turns out that |
|
Is anyone still working on this? I couldn't get @rib's branch to work. I added a codesig=None there to trigger the sign-from-scratch code path, then I got this: |
If I've cross-compiled a binary via clang + ld64 (without using XCode) then the code path for signing from scratch doesn't seem to be working currently.
The first issue I hit was that makesig.py doesn't have a line like:
(so any log.xyz() calls result in an exception)
I guess it implies that no one else is trying to do this and maybe the code has bitrotted? :/
Then I git an issue that I guess was introduced with the python3 port maybe being more fussy about strings/binary data and currently have a hack like:
I currently get this output running with
--verboseThe text was updated successfully, but these errors were encountered: