3 Replies
      Latest reply on Sep 24, 2018 7:26 AM by tartempion
      tartempion Level 1 Level 1 (10 points)

        Problem:

         

        I have a command line tool that is codesigned with a valid Developer ID Application certificate/identity (which expires in 2018)

         

        When this command line tool is checked in its build folder with codesign -vvvvvvvvv, everything is OK:

         

        mytool: valid on disk

        mytool: satisfies its Designated Requirement

         

        When this command line tool is checked in its installed location with codesign -vvvvvvvvv, there is a problem:

         

        mytool: invalid signature (code or signature have been modified)

        In architecture: x86_64

         

        Now, the weird part:

         

        - the md5 for the 2 instances are the same

        - the sha-1 for the 2 instances are the same

        - if I rename the instance in the installed location like this:

         

        mv mytool mytool2

         

        and then check with codesign -vvvvvvvv, everything is OK.

         

        If I put back the old name and check it with codesign -vvvvvvvv, same problem about the invalid signature.

         

        Note:

         

        If the running process mytool (in the installed location) is checked with SecCodeCheckValidityWithErrors, an error is returned: -67061.

         

        Of course, this error code is not documented.

         

        Questions:

         

        - What is the error code -67061 supposed to mean? The CFError returned by the function does not explain anything.

        - How can an executable be OK with one name and not with another one from a codesigning perspective? I'm beginning to wonder if the tool is not incorrectly blacklisted by one of the hidden OS lists (but I can't remember right now the locations of these 2 files). At least, it's not by XProtect.

         

        Environment:

         

        Mac OS X 10.8.5

        • Re: Bug in codesign and SecCodeCheckValidityWithErrors?
          tartempion Level 1 Level 1 (10 points)

          Answer to the second question:

           

          If the executable is codesigned and then put inside the MacOS folder of a bundle whose CFBundleExecutable is set to the name of the executable, then the coesign validation will fail if the bundle itself is not codesigned.

           

          I will file a bug report to get error -67061 be properly documented.

            • Re: Bug in codesign and SecCodeCheckValidityWithErrors?
              eskimo Apple Staff Apple Staff (11,825 points)

              Of course, this error code is not documented.

              That’d be errSecCSSignatureFailed, from <Security/CSCommon.h>.

              Just FYI, QA1499 Security Framework Error Codes is a great resource for this sort of thing.

              If the executable is codesigned and then put inside the MacOS folder of a bundle whose CFBundleExecutable is set to the name of the executable, then the coesign validation will fail if the bundle itself is not codesigned.

              Ah, yes.  The exact definition of a bundle has always been a bit fuzzy and code signing has to use various heuristics (guesses) for determine whether something is a bundle or not.

              I will file a bug report to get error -67061 be properly documented.

              Thanks.

              Share and Enjoy

              Quinn “The Eskimo!”
              Apple Developer Relations, Developer Technical Support, Core OS/Hardware
              let myEmail = "eskimo" + "1" + "@apple.com"

                • Re: Bug in codesign and SecCodeCheckValidityWithErrors?
                  tartempion Level 1 Level 1 (10 points)

                  I have a variant of this issue on some OS X versions (10.8, 10.9, maybe 10.10). It does seem to work fine in 10.13++.

                   

                  MyApplication.app is codesigned and is installed in /Applications/MyFolder/

                   

                  MyApplication.app/Contents/MacOS contains a helper tool MyHelperTool which is codesigned too (same certificate)

                   

                  MyApplication.app is running with pid PID_A

                  MyHelperTool is running.

                   

                  MyHelperTool retrieves a SecCodeRef for PID_A and then checks the validity of the SecCodeRef using SecCodeCheckValidityWithErrors.

                   

                  This fails with error errSecCSSignatureFailed.

                   

                  If I move MyApplications.app to /Applications/MyFolder/MySubFolder and the same running instance of MyHelperTool tries to perform the same check operation, the  check succeeds.

                   

                  Question:

                   

                  Are there known bugs/issues in older versions of OS X that prevents an embedded helper tool to check the validity of the running executable of its embedding bundle?