I'm testing apple-codesign on Linux, and encountered this error immediately:
Error: binary parsing error: Invalid magic number: 0x504b0304
I have an app bundle which contains Java application with JRE, native launcher and a bunch of jar files. So, I run the command:
rcodesign sign --pem-source ~/path/to/self-signed-cert.pem -vv sipmlejavaFX.app/
Relevant log output:
[2022-07-28T10:44:17Z WARN rcodesign] reading PEM data from /[removed]/self-signed-cert.pem
[2022-07-28T10:44:17Z WARN rcodesign] registering signing key
[2022-07-28T10:44:17Z WARN rcodesign] using time-stamp protocol server http://timestamp.apple.com/ts01
[2022-07-28T10:44:17Z WARN rcodesign] automatically setting team ID from signing certificate: unset
[2022-07-28T10:44:17Z WARN rcodesign] signing siplejavaFX.app/ to simplejavafx.app/
[2022-07-28T10:44:17Z WARN rcodesign::signing] signing bundle at siplejavaFX.app/
[2022-07-28T10:44:17Z WARN rcodesign::bundle_signing] signing 0 nested bundles in the following order:
[2022-07-28T10:44:17Z WARN rcodesign::bundle_signing] signing bundle at siplejavaFX.app/ into simplejavafx.app/
[2022-07-28T10:44:17Z DEBUG goblin::mach] Ctx: Ctx { container: Big, le: Little }
[2022-07-28T10:44:17Z DEBUG goblin::mach] Mach-o header: Header { magic: 0xfeedfacf, cputype: 16777223, cpusubtype: 0x3, filetype: "EXECUTE", ncmds: 11, sizeofcmds: 2360, flags: 0x0, reserved: 0x0 }
....................
[2022-07-28T10:44:17Z INFO rcodesign::bundle_signing] main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
[2022-07-28T10:44:17Z WARN rcodesign::bundle_signing] collecting code resources files
[2022-07-28T10:44:17Z INFO rcodesign::bundle_signing] Contents/Info.plist is the Info.plist file; handling specially
[2022-07-28T10:44:17Z DEBUG rcodesign::code_resources] Info.plist matches exclusion rule ^Info\.plist$
[2022-07-28T10:44:17Z INFO rcodesign::bundle_signing] copying file siplejavaFX.app/Contents/Info.plist -> simplejavafx.app/Contents/Info.plist
[2022-07-28T10:44:17Z DEBUG rcodesign::code_resources] Info.plist doesn't match any rule
[2022-07-28T10:44:17Z DEBUG rcodesign::code_resources] MacOS/cp/045700bcabd5441a50964944f38babbee8fc2e8159179b8cb5e64d18274e3853.jar matches inclusion rule ^(Frameworks|SharedFrameworks|PlugIns|Plug-ins|XPCServices|Helpers|MacOS|Library/(Automator|Spotlight|LoginItems))/
[2022-07-28T10:44:17Z INFO rcodesign::code_resources] sealing Mach-O file MacOS/cp/045700bcabd5441a50964944f38babbee8fc2e8159179b8cb5e64d18274e3853.jar
[2022-07-28T10:44:17Z INFO rcodesign::bundle_signing] signing Mach-O file Contents/MacOS/cp/045700bcabd5441a50964944f38babbee8fc2e8159179b8cb5e64d18274e3853.jar
Error: binary parsing error: Invalid magic number: 0x504b0304
So, it seems rcodesign is trying to sign a jar file and fails with this magic number error. Running hexdump on that jar gives the following output:
0000000 4b50 0403 000a 0800 0008 a916 5350 0000
0000010 0000 0002 0000 0000 0000 0009 0000 454d
0000020 4154 492d 464e 032f 5000 034b 0a04 0000
0000030 0808 1600 50a9 e253 fb21 4469 0000 4200
0000040 0000 1400 0000 4d00 5445 2d41 4e49 2f46
0000050 414d 494e 4546 5453 4d2e f346 cc4d 4ccb
0000060 2d4b d12e 4b0d 2a2d ccce b3cf 3052 33d4
0000070 e5e0 2c72 c92d 4dcf c92c d64c cdf5 294f
0000080 49cd f5d5 cc4b b54d c852 2c4a 4c4b d0ab
0000090 4a4b 4e2c cd75 282d e4a9 e2e5 02e5 5000
00000a0 014b 1402 0a03 0000 0808 1600 50a9 0053
00000b0 0000 0200 0000 0000 0000 0900 0000 0000
00000c0 0000 0000 1000 ed00 0041 0000 4d00 5445
00000d0 2d41 4e49 2f46 4b50 0201 0314 000a 0800
00000e0 0008 a916 5350 21e2 69fb 0044 0000 0042
00000f0 0000 0014 0000 0000 0000 0000 0000 81a4
0000100 0029 0000 454d 4154 492d 464e 4d2f 4e41
0000110 4649 5345 2e54 464d 4b50 0605 0000 0000
0000120 0002 0002 0079 0000 009f 0000 0000
000012e
The first two bytes look like they are in inverted order to what is reported by rcodesign. So, is it possible that this is some kind of endian-ness problem?
Any idea of what might be the problem?
In addition, when I try to sign only the native launcher, I get the following error:
RUST_BACKTRACE=1 rcodesign sign --pem-source ~/local/work/bitshift/xapps/self-signed-cert.pem --code-signature-flags runtime simplejavafx
reading PEM data from /home/vlada/local/work/bitshift/xapps/self-signed-cert.pem
registering signing key
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: unset
signing simplejavafx in place
signing simplejavafx as a Mach-O binary
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.9.0 is not >=10.11.4
setting binary identifier to simplejavafx
parsing Mach-O
signing Mach-O binary at index 0
thread 'main' panicked at 'assertion failed: segment.fileoff == 0 || segment.fileoff == cursor.position()', /home/vlada/.cargo/registry/src/github.com-1ecc6299db9ec823/apple-codesign-0.16.0/src/macho_signing.rs:166:9
stack backtrace:
0: rust_begin_unwind
at /build/rustc-60tkWq/rustc-1.59.0+dfsg1/library/std/src/panicking.rs:498:5
1: core::panicking::panic_fmt
at /build/rustc-60tkWq/rustc-1.59.0+dfsg1/library/core/src/panicking.rs:116:14
2: core::panicking::panic
at /build/rustc-60tkWq/rustc-1.59.0+dfsg1/library/core/src/panicking.rs:48:5
3: rcodesign::macho_signing::create_macho_with_signature
4: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
6: core::iter::adapters::process_results
7: rcodesign::macho_signing::MachOSigner::write_signed_binary
8: rcodesign::signing::UnifiedSigner::sign_path_in_place
9: rcodesign::command_sign
10: rcodesign::main_impl
11: rcodesign::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Not sure if the two problems are connected.
I'm testing
apple-codesignon Linux, and encountered this error immediately:I have an app bundle which contains Java application with JRE, native launcher and a bunch of jar files. So, I run the command:
Relevant log output:
So, it seems rcodesign is trying to sign a jar file and fails with this magic number error. Running hexdump on that jar gives the following output:
The first two bytes look like they are in inverted order to what is reported by rcodesign. So, is it possible that this is some kind of endian-ness problem?
Any idea of what might be the problem?
In addition, when I try to sign only the native launcher, I get the following error:
Not sure if the two problems are connected.