Uploaded image for project: 'Directory Studio'
  1. Directory Studio
  2. DIRSTUDIO-1140

Apple Sierra shows corrupted app when launching Studio

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M12
    • Fix Version/s: 2.0.0-M13
    • Component/s: studio-apacheds
    • Labels:
      None

      Description

      After downloading and launching Apache Directory Studio 2.0.0 M12 on MacOS X Sierra, I am presented with a panel that says:

      "ApacheDirectoryStudio.app" is damaged and can't be opened. You should move it to the Trash.

      The cause of this issue is because of Sierra's enhanced security related to... resource fork, Finder information, or similar detritus not allowed and code signing.

      This may or may not be related to code signing specifically, but is more likely related to the version of Xcode used to create this app version. Here's the security issue:

      This is a security hardening change that was introduced with iOS 10, macOS Sierra, watchOS 3, and tvOS 10.

      Code signing no longer allows any file in an app bundle to have an extended attribute containing a resource fork or Finder info.

      To find the offending attributes, use:

      xattr -lr /Applications/ApacheDirectoryStudio.app

      To fix the app and allow it to function, these attributes must be stripped with:

      xattr -cr /Applications/ApacheDirectoryStudio.app

      Better, the next time someone compiles the app for release on MacOS X, make sure it doesn't include these offending attributes. I would assume the latest version of Xcode should prevent the creation of these attributes. If not, then the app should be stripped with xattr before package and release.

      1. ADS-Damaged.png
        74 kB
        Brian Wright

        Activity

        Hide
        seelmann Stefan Seelmann added a comment -

        Fixed: http://svn.apache.org/viewvc?rev=1807158&view=rev

        It's not related to Eclipse version which creates the app without offending attributes, but the way we build the DMG: hdiutil makehybrid -hfs-openfolder creates those extended attributes. I found another way at https://porkrind.org/missives/mac-os-x-codesigning-woes/

        Note: I only have an old 2009 Macbook which I cannot upgrade to Sierra so I cannot fully verify, but xattr -lr no longer shows the "com.apple.FinderInfo" attributes.

        Show
        seelmann Stefan Seelmann added a comment - Fixed: http://svn.apache.org/viewvc?rev=1807158&view=rev It's not related to Eclipse version which creates the app without offending attributes, but the way we build the DMG: hdiutil makehybrid -hfs-openfolder creates those extended attributes. I found another way at https://porkrind.org/missives/mac-os-x-codesigning-woes/ Note: I only have an old 2009 Macbook which I cannot upgrade to Sierra so I cannot fully verify, but xattr -lr no longer shows the "com.apple.FinderInfo" attributes.
        Hide
        commorancy0 Brian Wright added a comment -

        Apple has been taking many many pages from Microsoft's playbook in the last several years. This is just one in many. For this reason (and hardware complacency), Apple has been losing computer users to Windows computers that are typically less expensive, give better hardware choices and offer a similar OS experience (not that Windows 10 is by any stretch a perfect experience).

        Personally, I only stick with Mac because of BSD (that and for work reasons). As a systems admin, having native shell scripting and open source compilation at my fingertips is handy. Unfortunately, Apple keeps pushing Darwin farther away from Linux with every MacOS X release making it more and more difficult to justify having a Mac considering that VirtualBox is available to install and run Linux right on your desktop.

        It's issues like this ticket that expose Apple giving the finger not only to developers, but also to the users. I'm not even sure how this solves a security problem. Having resource fork or Finder info in a file is an arbitrary change that formerly worked. It's okay to implement security fixes like this, but not by presenting a banner that tells the user to throw the app in the trash. That's just insane. At least offer the user an explanation and let them choose whether or not to run it. I just don't get Apple's developers sometimes.

        Show
        commorancy0 Brian Wright added a comment - Apple has been taking many many pages from Microsoft's playbook in the last several years. This is just one in many. For this reason (and hardware complacency), Apple has been losing computer users to Windows computers that are typically less expensive, give better hardware choices and offer a similar OS experience (not that Windows 10 is by any stretch a perfect experience). Personally, I only stick with Mac because of BSD (that and for work reasons). As a systems admin, having native shell scripting and open source compilation at my fingertips is handy. Unfortunately, Apple keeps pushing Darwin farther away from Linux with every MacOS X release making it more and more difficult to justify having a Mac considering that VirtualBox is available to install and run Linux right on your desktop. It's issues like this ticket that expose Apple giving the finger not only to developers, but also to the users. I'm not even sure how this solves a security problem. Having resource fork or Finder info in a file is an arbitrary change that formerly worked. It's okay to implement security fixes like this, but not by presenting a banner that tells the user to throw the app in the trash. That's just insane. At least offer the user an explanation and let them choose whether or not to run it. I just don't get Apple's developers sometimes.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Having switched to Sierra lately, I haven't had the opportunity to run the installer on it. Will try that soon. If we just need to run xattr -cr /Applications/ApacheDirectoryStudio.app when we build the installers can be scripted, I just have to check it's not breaking anything for those using older versions of Mac OSX.

        Finally, Apple learned how to piss off users the Microsoft way...

        Show
        elecharny Emmanuel Lecharny added a comment - Having switched to Sierra lately, I haven't had the opportunity to run the installer on it. Will try that soon. If we just need to run xattr -cr /Applications/ApacheDirectoryStudio.app when we build the installers can be scripted, I just have to check it's not breaking anything for those using older versions of Mac OSX. Finally, Apple learned how to piss off users the Microsoft way...
        Hide
        commorancy0 Brian Wright added a comment -

        Hi Emmanuel Lecharny, I was assuming you were using Xcode to build this app, but it makes sense that using a third party base might not keep up with all of Apple's security policies timely. Thanks for looking into this issue.

        Show
        commorancy0 Brian Wright added a comment - Hi Emmanuel Lecharny , I was assuming you were using Xcode to build this app, but it makes sense that using a third party base might not keep up with all of Apple's security policies timely. Thanks for looking into this issue.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        We don't use xcode. It's an eclipse RCP application, and this seems to be a bug in Mars. We have to see if this problem still happens with Neon.

        Show
        elecharny Emmanuel Lecharny added a comment - We don't use xcode. It's an eclipse RCP application, and this seems to be a bug in Mars. We have to see if this problem still happens with Neon.
        Hide
        commorancy0 Brian Wright added a comment -
        Show
        commorancy0 Brian Wright added a comment - Here's the Apple developer link: https://developer.apple.com/library/content/qa/qa1940/_index.html

          People

          • Assignee:
            Unassigned
            Reporter:
            commorancy0 Brian Wright
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development