Re: [rt.cpan.org #129312] Code signing for OSX

Sat Apr 27 08:00:20 2019: Request 129312 was acted upon.
Transaction: Correspondence added by [email protected]
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #129312] Code signing for OSX
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: [email protected]
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=129312 >


Hmm, I couldn’t see anything in the acrhive - do you have a link? I may look into this as PAR::Packer .exes will become an issue on OSX in the future if this isn’t solved given that codesigning will become mandatory.

PK

> On 25 Apr 2019, at 6:53 pm, claudio claudio via RT <[email protected]> wrote:
>
> Thu Apr 25 12:53:32 2019: Request 129312 was acted upon.
> Transaction: Correspondence added by [email protected]
> Queue: PAR-Packer
> Subject: Re: [rt.cpan.org #129312] Code signing for OSX
> Broken in: (no value)
> Severity: (no value)
> Owner: Nobody
> Requestors: [email protected]
> Status: new
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=129312 >
>
>
> I've done a lot of research in the last few weeks on the topic (and asked a
> similar question here, see archive to see the interesting insights that
> came out). The short answer is that executable created with PAR::Packer can
> NOT be codesigned out-of-the-box on OSX (I have no problems to codesign it
> on Windows though). I virtually met a guy that has written a small
> application that can modify the executable so that it can be codesigned on
> OSX. Unfortunately, it is not open source and a fee is required.
>
> <https://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virenfrei.
> www.avg.com
> <https://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Am Do., 25. Apr. 2019 um 18:34 Uhr schrieb Philip Kime via RT <
> [email protected]>:
>
>> Thu Apr 25 12:34:17 2019: Request 129312 was acted upon.
>> Transaction: Ticket created by [email protected]
>> Queue: PAR-Packer
>> Subject: Code signing for OSX
>> Broken in: (no value)
>> Severity: (no value)
>> Owner: Nobody
>> Requestors: [email protected]
>> Status: new
>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=129312 >
>>
>>
>> Has anyone managed to codesign PAR::Packer executables on OSX? I believe
>> that in OSX 10.15, this will start to be mandatory for mainstream binaries
>> and since I provide a binary for a major opens-source software distribution
>> (TeXLive/MacTeX), I will need to codesign the packed binaries.
>>
>> PK
>> --
>> Dr Philip Kime
>>

--
Dr Philip Kime

Sat Apr 27 09:50:29 2019: Request 129312 was acted upon.
Useful link, thank you. It is interesting that Mr Schupp mentions that strip would remove the appended parts but this highlights part of the issue with codesign I think as it give an error:

strip: the __LINKEDIT segment does not cover the end of the file (can't be processed) in:…

So it does indeed look like the appended parts need to be made into real MACH-O segments.

PK

> On 27 Apr 2019, at 2:28 pm, claudio claudio via RT <[email protected]> wrote:
>
> <URL: https://rt.cpan.org/Ticket/Display.html?id=129312 >
>
> Hi, you are right. It was in the mailing list [email protected] : you find it
> here: https://www.nntp.perl.org/group/perl.par/
> PS: You are right about the urgency of the issue as it will become
> mandatary anytime soon.
>
> Welle
>
>
>
> Am Sa., 27. Apr. 2019 um 14:00 Uhr schrieb Kime Philip via RT <
> [email protected]>:
--
Dr Philip Kime

Sat Apr 27 10:33:53 2019: Request 129312 was acted upon.
I can get part of the way so far. I can manually fix the binary headers which makes codesign at least run but this breaks PAR. This is expected I suppose and we need to make some more modifications …

> codesign -s "Code Signing Test" -v b
b: signed Mach-O thin (x86_64) [b]

> ./b
format error: can't find EOCD signature
at /loader/HASH(0x7fcef88aa428)/Archive/Zip/Archive.pm line 723.
Archive::Zip::Archive::_findEndOfCentralDirectory(Archive::Zip::Archive=HASH(0x7fcef88e1a88), IO::File=GLOB(0x7fcef8d6af98)) called at /loader/HASH(0x7fcef88aa428)/Archive/Zip/Archive.pm line 596
Archive::Zip::Archive::readFromFileHandle(Archive::Zip::Archive=HASH(0x7fcef88e1a88), IO::File=GLOB(0x7fcef8d6af98), "/Users/philkime/Desktop/NB/./b") called at -e line 373
eval {...} called at -e line 41
__par_pl::BEGIN() called at -e line 614
eval {...} called at -e line 614
: at -e line 373.
--
Dr Philip Kime

Sat Apr 27 10:47:12 2019: Request 129312 was acted upon.
Hmm, I sense a problem here. In the linked comments from Mr Schupp, he states that the PAR signature can be located in the last 128K of the binary. However, it seems that codesign, at least with the cert etc. I am using, adds about 180K to the binary and so the signature can’t be found in the last 128K. Would that account for the error I noted below?

PK
--
Dr Philip Kime

Sat Apr 27 14:26:26 2019: Request 129312 was acted upon.
I now have an OSX C program which which I can contribute which fixes the two issues preventing code signing. It only works with 64-bit non-fat Mach-O binaries but since, I believe, this is what is allowed by Apple for distributions that uses code-signing, I don’t see a problem with this. I can generalise it if necessary. See sample output:


> codesign -v -s "Code Signing Test" --force --timestamp --options=runtime ppbinary
ppbinary: main executable failed strict validation

> pp_codesign_fix ppbinary
Correcting __LINKEDIT
Old File Size: 5836
New File Size: 17888447
Old VM Size: 8192
New VM Size: 17888447
Correcting LC_SYMTAB
Old String Table Size: 1848
New String Table Size: 17884459

> codesign -v -s "Code Signing Test" --force --timestamp --options=runtime ppbinary
ppbinary: signed Mach-O thin (x86_64) [ppbinary]


However, the signed binary is broken for PAR:

> ./ppbinary
at /loader/HASH(0x7fb593093028)/Archive/Zip/Archive.pm line 723.
Archive::Zip::Archive::_findEndOfCentralDirectory(Archive::Zip::Archive=HASH(0x7fb593801888), IO::File=GLOB(0x7fb593511598)) called at /loader/HASH(0x7fb593093028)/Archive/Zip/Archive.pm line 596
Archive::Zip::Archive::readFromFileHandle(Archive::Zip::Archive=HASH(0x7fb593801888), IO::File=GLOB(0x7fb593511598), "/Users/philkime/Desktop/NB/./ppbinary") called at -e line 373
Compare the file sizes before and after codesigning:

BEFORE: 21107903
AFTER: 21291136

Difference is ~180K which is all appended after the PAR signature.


Can Mr Schupp or someone familiar with this comment on whether this looks like the 128K PAR signature limit needs to be relaxed further or is this a different problem?

Sat Apr 27 18:37:38 2019: Request 129312 was acted upon.
Looking into this further, I am fairly sure that Archive::Zip::ChunkSize needs to be increased in par.pl and also the 128k limit for the PAR signature also needs to be increased. Doubling both to 256k would likely be appropriate. All tests for PAR::Packer pass if I do this but I still get the same error after codesigning so I am missing something as Archive::Zip still fails to find the EOCD marker for some reason, even with the increased window size which does (I have checked) include the EOCD marker once the ChunkSize has been modified.

--
Dr Philip Kime

Sun Apr 28 08:08:23 2019: Request 129312 was acted upon.
I believe that I now have a fix for this. See:

https://github.com/rschupp/PAR-Packer/pull/14

There is a contributed small program which is run on the pp exe and edits it in-place. This makes codesigning work. There is a also a small fix for par.pl required in PAR::Packer to allow unpacking of codesigned exes. With these two elements in place, in my tests, I can codesign and run a pp binary.

PK

Mon Apr 29 04:55:56 2019: Request 129312 was acted upon.
Transaction: Correspondence added by RSCHUPP
Thanks Phil! See my comments on the PR, it's almost ready to
be merged and I'll do a release of PAR::Packer then.

Cheers, Roderich

Tue Mar 10 12:13:59 2020: Request 129312 was acted upon.
Transaction: Correspondence added by [email protected]
On Sun Mar 08 18:57:51 2020, KWALZER wrote:
> Anyone know if this ticket adds support for code signing
> (Authenticode/signtool) on Windows? I'm currently shipping a full
> installation of Strawberry Perl with my app because of code signing
> requirements, but would love to use pp again.


It doesn't - it was just for OSX codesigning but it was just to fix issues that prevented codesigning - have you tried codesigning pp exes on Windows? It might work ...