codesign

Thank for those UUIDs. I asked the notary team for a copy of those submissions, so I could see exactly what the submitted zip archives look like, and that revealed a clear problem. Consider this file listing of your notarytool submission: % unzip -t ok-035482f3-855c-455f-bd60-6be63ceefd61.zip Archive: ok-035482f3-855c-455f-bd60-6be63ceefd61.zip … testing: Wwwwwwww.app/Contents/MacOS/graphviz/bin/gvmap.sh OK testing: __MACOSX/Wwwwwwww.app/Contents/MacOS/graphviz/bin/._gvmap.sh OK … No errors detected in compressed data of ok-035482f3-855c-455f-bd60-6be63ceefd61.zip. Note I’ve redacted stuff using my ‘patented’ ‘first letter’ algorithm [1]. First up, the __MACOSX indicates that you’ve sequestered Mac metadata. That doesn’t make sense in this context. I explain why in Extended Attributes and Zip Archives. However, the real issue is that you have Mac metadata at all! Unpacking the archive I see this: % xattr Wwwwwwww.app/Contents/MacOS/graphviz/bin/gvmap.sh com.apple.cs.CodeDirectory com.apple.cs.CodeRequirements

security -v import bundle.p12 -k login.keychain -T /usr/bin/codesign -P https://1drv.ms/u/c/de13bcdacf228c88/ER4DNppbQQRMlY4tzawZ1s8BNLNcbEnuf54lLUOL1oD-Dg

Any updates on the bug ? Same issue. Sequoia 15.4.1 (24E263) OpenSSL 3.4.0 Steps for repoducing: Create .p12 without password openssl genpkey -algorithm RSA -out private_key.pem openssl req -new -key private_key.pem -out csr.pem openssl x509 -req -days 365 -in csr.pem -signkey private_key.pem -out certificate.pem openssl pkcs12 -export -out bundle.p12 -inkey private_key.pem -in certificate.pem Import .p12 to a keychain import bundle.p12 -k login.keychain -T /usr/bin/codesign -P And voila you've got the bug: security: SecKeychainItemImport: MAC verification failed during PKCS12 import (wrong password?)

It’s really hard to read your post. Please take a look at Quinn’s Top Ten DevForums Tips, which has lots of suggestions for how to work effectively on the forums. Anyway, what I can see is this: [quote='784184021, BenAuerDev, /thread/784184, /profile/BenAuerDev'] Are there known issues with signing Flutter plugin frameworks for notarization? [/quote] I think you might have more luck asking that via the support channel for the third-party tool you’re using. However, my experience is that third-party tooling tends to bend the bundle placement rules outlined in Placing Content in a Bundle, and that causes all sorts of weird problems. [quote='784184021, BenAuerDev, /thread/784184, /profile/BenAuerDev'] Using both codesign --deep [/quote] I strongly recommend against using --deep when signing code. See --deep Considered Harmful. As to what you should do, you can find my general advice in: Creating distribution-signed code for macOS Packaging Mac software for distribution Beyond that, it’s hard to offer sp

I’ve not looked into the installer package side of this in depth but, in general, the transition from SHA1 to SHA256 is driven by the deployment target. If your product supports old releases, the system has to include both hashes to ensure compatibility with those systems. Now, with codesign I’m familiar with how that’s controlled, that is, via various Mach-O load commands. You can dump these using vtool. For installer packages, the productbuild man page described how you set the minimum supported OS version. Are you doing that? And just for testing, try setting it way up, to something silly like macOS 15. If that works, you can then step it back to determine the inflexion point. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

also can confirm that I can take my bosses p12 files and set them up on my computer using this script KEYCHAIN_PATH1=$HOME/Library/Keychains/tmpsed1.keychain-db KEYCHAIN_PASSWORD1=$(openssl rand -base64 12) security create-keychain -p $KEYCHAIN_PASSWORD1 $KEYCHAIN_PATH1 security unlock-keychain -p $KEYCHAIN_PASSWORD1 $KEYCHAIN_PATH1 echo keychain-path=$KEYCHAIN_PATH1 echo keychain-password=$KEYCHAIN_PASSWORD1 #DEV_ID_APPLICATION=$(mktemp) #echo $DEV_ID_APPLICATION #base64 -i app.p12 | base64 -d >$DEV_ID_APPLICATION #cat $DEV_ID_APPLICATION security import app.p12 -f pkcs12 -k $KEYCHAIN_PATH1 -P password -T /usr/bin/codesign -T /usr/bin/security export DEV_ID_INSTALLER=$(mktemp) base64 -i installer.p12 | base64 -d >$DEV_ID_INSTALLER security import installer.p12 -f pkcs12 -k $HOME/Library/Keychains/tmpsed1.keychain-db -P “password” -T /usr/bin/pkgbuild -T /usr/bin/security -T /usr/bin/productbuild rm $DEV_ID_INSTALLER security set-key-partition-list -S apple-tool:,apple: -s -k $KEYCHAIN_PATH1 $K

[quote='837189022, LinuxProg, /thread/782331?answerId=837189022#837189022, /profile/LinuxProg'] It would be very useful for Apple to add a test VM creation CLI to the developer toolkit [/quote] I tend to agree but, given that current reality, I encourage you to explore the raft of third-party options out there [1]. As to your original issue, adding an extension is the right option here. macOS draws a clear distinction between bundled and non-bundle code. This really matters when comes to code signing. See the discussion is Creating distribution-signed code for macOS. That Java runtime is signed as a bundle: % codesign -d -vvv jdk-21.0.7+6-jre Executable=/Users/quinn/Desktop/jdk-21.0.7+6-jre/Contents/MacOS/libjli.dylib Identifier=net.java.openjdk.jre Format=bundle with Mach-O thin (arm64) ^^^^^^ However, the exact definition of what constitutes a bundle is more squishy then it should be. It seems that codesign and Gatekeeper disagree as to whether the file name extension is required, which is

Yeah, this stuff is complex )-: Let me clarify this by example. My go-to suggestion for setting this up is to do what Xcode does. In fact, we have that in the official documentation, namely Signing a daemon with a restricted entitlement. If you follow that process and build the test project with Xcode, you see this: % codesign -d --entitlements - Test782415.app … [Dict] [Key] com.apple.application-identifier [Value] [String] SKMME9E2Y8.com.example.apple-samplecode.Test782415 [Key] com.apple.developer.endpoint-security.client [Value] [Bool] true [Key] com.apple.developer.team-identifier [Value] [String] SKMME9E2Y8 [Key] com.apple.security.get-task-allow [Value] [Bool] true % security cms -D -i Test782415.app/Contents/embedded.provisionprofile | plutil -p - { … Entitlements => { com.apple.application-identifier => SKMME9E2Y8.com.example.apple-samplecode.Test782415 com.apple.developer.endpoint-security.client => 1 com.apple.developer.team-identifier => SKMME9E2Y8 keychain-access-groups =>