Today I installed from macports the gdb debugger; following all the documents on the net I've signed GDB with a self signed certificate for code signing.
Despite that gdb don't run with the usual error:
`Unable to find Mach task port for process-id 1217: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))`
If running gdb with sudo it works fine.
Two clues:
When signing I was compelled to sudo, otherwise:
/opt/local/bin/ggdb: replacing existing signature
error: /Applications/Xcode.app/Contents/Developer/Toolchains /XcodeDefault.xctoolchain/usr/bin/codesign_allocate: can't create output file: /opt/local/bin/ggdb.cstemp (Permission denied)
/opt/local/bin/ggdb: the codesign_allocate helper tool cannot be found or used
I verified the signature with:
codesign --verify --verbose=9 /opt/local/bin/ggdb
and the result is:
`/opt/local/bin/ggdb: valid on disk
/opt/local/bin/ggdb: satisfies its Designated Requirement`
and with:
codesign --display --verbose=9 /opt/local/bin/ggdb
Executable=/opt/local/bin/ggdb
Identifier=org.gnu.gdb
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=42012 flags=0x0(none) hashes=1309+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=fcdc413a6e9a46c43dbf5a6bef10dfc9ca859139
CandidateCDHash sha256=299f6ddc02c908d00f2ec0e858cff9ff44732f03
Hash choices=sha1,sha256
-2=9181fb83a0797cdc555934e7e0b1ae35e91cf32040ebf25af11bf5bc1f1c5947
[Lots of hex...]
1307=6720981bf5bd01662bf60c634c900bc93bc5c4628db492f2865f17b7316eb0ef
1308=04de6d07a1d252c0f5b88640956b83a4d77594d7f175929c486434abea1e99c1
CDHash=299f6ddc02c908d00f2ec0e858cff9ff44732f03
Signature size=1745
Authority=gdb-cert
Signed Time=2-giu-2016, 16:11:02
Info.plist entries=4
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=88
Any clue to solve this issue will help a lot!
Thank you.
Related
I'm attempting to add my local IP address to xhost and I get the following error:
dyld: Library not loaded: /opt/X11/lib/libXmuu.1.dylib
Referenced from: /usr/bin/xhost
Reason: no suitable image found. Did find:
/opt/X11/lib/libXmuu.1.dylib: code signature in (/opt/X11/lib/libXmuu.1.dylib) not valid for use in process using Library Validation: mapping process is a platform binary, but mapped file is not
/opt/X11/lib/libXmuu.1.dylib: stat() failed with errno=1
Abort trap: 6
The error occurs even when just calling xhost from the command line. However, I it seems to be installed and in the correct place. The output of which xhost results in /usr/bin/xhost
I'm working on a fresh install of XQuartz and CommandLineTools. I've tried downgrading XQuartz, logging out and back in as well as rebooting after each fresh install. Still no luck.
This appears to be a documented issue, though I can't find any answers for fixes.
Operating System: OSX 10.14.5 on MacBook Pro, 2018
XQuartz Version: 2.7.11
Edit
Output of codesign -vvv -d /usr/bin/xhost:
Executable=/usr/bin/xhost
Identifier=xhost
Format=Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=261 flags=0x0(none) hashes=4+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=ddd40d822185d02bc484aae27ab8a2a832490c9f
CandidateCDHash sha256=5c76bf6e89fc30926f3d38559f9cf813bcf63349
Hash choices=sha1,sha256
CDHash=5c76bf6e89fc30926f3d38559f9cf813bcf63349
Signature size=8928
Authority=Developer ID Application: Apple Inc. - XQuartz (NA574AWV7E)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Oct 7, 2016 at 1:26:16 PM
Info.plist=not bound
TeamIdentifier=NA574AWV7E
Sealed Resources=none
Internal requirements count=1 size=168
For me what worked is specifying the correct path for xhost:
/usr/X11/bin/xhost + 127.0.0.1
(macOS)
I am trying to use productsign to sign a XAR archive containing 2 pkg files created using productbuild . The xar tool is creating the file correctly, but I think the signing is corrupting the content, even though the file obtained is signed.
Some relevant command outputs below (I replaced the sensitive information with INFO):
$ ls .
file1.pkg file2.pkg
$
$ xar -cf '../_file.xar' .
$
$ cd ..
$ /usr/bin/productsign --sign 'Developer ID Installer: INFO' '_file.xar' 'file.xar'
productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: INFO" from keychain /Users/INFO/Library/Keychains/login.keychain
productsign: adding certificate "Developer ID Certification Authority"
productsign: adding certificate "Apple Root CA"
productsign: Wrote signed product archive to file.xar
$
$ /usr/sbin/pkgutil --check-signature 'file.xar'
Package "file.xar":
Status: signed by a certificate trusted by Mac OS X
Certificate Chain:
1. Developer ID Installer: INFO
SHA1 fingerprint: INFO
-----------------------------------------------------------------------------
2. Developer ID Certification Authority
SHA1 fingerprint: INFO
-----------------------------------------------------------------------------
3. Apple Root CA
SHA1 fingerprint: INFO
$ file file.xar
file.xar: xar archive - version 1
$
$ xar -xf file.xar -D /tmp
Error while extracting archive:(file1.pkg): Error decompressing file
$
Is the productsign command intended to work in some other way? I don't understand what is wrong with my approach.
After some testing, I found out xar is using relative paths inside the archive, so in my case there was a problem because I used "../" inside a path name.
Qt4 application with bundle structure like that:
QtCore.framework/
QtCore -> Versions/Current/QtCore
Resources -> Versions/Current/Resources
Versions/
4/
QtCore
Resources/
Info.plist
Current -> 4
codesign --verbose --force --deep --sign "Certificate Name" Test.app
Result: Test.app: signed bundle with Mach-O thin (x86_64) [...]
"Certificate Name" is Comodo code sign certificate
codesign --verify -vvvv Test.app
Test.app: nested code is modified or invalid
codesign --verbose --verify Test.app/Contents/Frameworks/QtCore.framework
Test.app/Contents/Frameworks/QtCore.framework: valid on disk
Test.app/Contents/Frameworks/QtCore.framework: does not satisfy its designated Requirement
p.s. I have tried to sign manually all framework/dylib without option --deep and the same result.
create a folder called A inside versions with same contents of 4, change the symbolic links to the A folder especially current->A
try signing now and it may sign. But the problem may be with the binary, it will use a different framework than A, which you can check with otool -L (take care big L and not small l)
to change it, you need to use install_name_tool
good luck and have fun
I've been trying to use the "codesign" command on Mail.app so that I can modify the info.plist using the "defaults write" command. It used to work, but after I re-installed Yosemite, I get this result when running the command:
/Applications/Mail.app: no identity found
I ran this command:
codesign -f -s /Applications/Mail.app
If anyone could tell me how I could properly run the codesign command on Mail.app so that I can modify the info.plist of Mail.app using the "defaults write" command, that would be nice! Thanks!
You're just missing a parameter here. I can re-codesign an app using --force and specifying exactly which signature I want to use:
$ codesign --force -s "Developer ID Application: Michael Dautermann" Mail.app
Mail.app: replacing existing signature
And if you want to verify that Mail.app is indeed signed, here is what my copy of Mail looks like before I forced my signature onto it:
$codesign --display --verbose=4 Mail.app
Executable=/Applications/Mail.app/Contents/MacOS/Mail
Identifier=com.apple.mail
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=23743 flags=0x0(none) hashes=1179+5 location=embedded
Hash type=sha1 size=20
CDHash=a3920218afa4f082aac98bf486dd797b13fde588
Signature size=4097
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=41
TeamIdentifier=not set
Sealed Resources version=2 rules=15 files=262
Internal requirements count=1 size=64
So we have a certificate that allows us to sign kexts,
but when we run > sudo kextload friendly.kext, it fails
and we sign the kext we want, and to prove it's signed, here's some diagnostic output:
👉 codesign --verify -vvvv friendly.kext
friendly.kext: valid on disk
friendly.kext: satisfies its Designated Requirement
👉 spctl -a -vvvv friendly.kext
friendly.kext: accepted
source=Developer ID
origin=Developer ID Application: Friendly Corporation
/Library/Extensions
👉 codesign -dvvv friendly.kext
Executable=/Library/Extensions/friendly.kext/Contents/MacOS/friendly
Identifier=com.friendly.friendly
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=502 flags=0x0(none) hashes=18+3 location=embedded
Hash type=sha1 size=20
CDHash=a1e2bf8d53ea67c6cfe9fc3d6d2001fe56c838a7
Signature size=8528
Authority=Developer ID Application: Friendly Corporation
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Oct 9, 2014, 11:49:02 AM
Info.plist entries=21
TeamIdentifier=1234567890
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=180
👉 codesign --verify -vvvv friendly.kext
friendly.kext: valid on disk
friendly.kext: satisfies its Designated Requirement
It looks like it's signed properly;
However, when I run > sudo kextutil -v friendly.kext :
Defaulting to kernel file '/System/Library/Kernels/kernel'
Diagnostics for /Library/Extensions/friendly.kext:
Code Signing Failure: code signature is invalid
/Library/Extensions/friendly.kext appears to be loadable (not including linkage for on-disk libraries).
ERROR: invalid signature for com.techsmith.friendly, will not load
I'm thinking either I downloaded the certificate wrong (we definitely got approved for kext signing), although I tried redownloading the certificate once before so that may not be the problem.
Otherwise, it's the way that I'm signing. I'm thinking maybe it has something to do with the permissions I set on the kext before I sign them?
Has anybody seen this problem before?
Thanks in advance!
The kext signing certificate must have the extension "( 1.2.840.113635.100.6.1.18 )" listed - this is what designates it as a kext-enabled certificate. You can easily verify this by viewing it in Keychain Access.app. (it's listed near the bottom, below extension "( 1.2.840.113635.100.6.1.13 )" which I think is used for apps and thus present in all Developer ID certificates)