New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot install on Mac OSX 10.8 (Mountain Lion) - "Google Refine" is damaged and can't be opened. You should move it to the Trash. #590

Closed
tfmorris opened this Issue Oct 15, 2012 · 31 comments

Comments

@tfmorris
Member

tfmorris commented Oct 15, 2012

Original author: eliasdab...@gmail.com (July 30, 2012 23:53:39)

I've just downloaded Google Refine, and trying to install on Mac (running Mountain Lion) It's telling me that it's damaged and should be moved to trash (attached screenshot).

Appreciate help in installing the app.

Original issue: http://code.google.com/p/google-refine/issues/detail?id=591

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From edouard....@gmail.com on August 06, 2012 15:46:17:
Hi,

I'm having exactly the same issue running Mountain Lion...

Someone can help ?

Member

tfmorris commented Oct 15, 2012

From edouard....@gmail.com on August 06, 2012 15:46:17:
Hi,

I'm having exactly the same issue running Mountain Lion...

Someone can help ?

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From erin.s...@gmail.com on August 07, 2012 19:33:44:
Having the same issue, running Mountain Lion

Member

tfmorris commented Oct 15, 2012

From erin.s...@gmail.com on August 07, 2012 19:33:44:
Having the same issue, running Mountain Lion

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From bodna...@gmail.com on August 08, 2012 03:42:17:
I was able to fix this on my wife's laptop by taking the following steps:

  1. Open System Preferences
  2. Open Security & Privacy
  3. Go to the General Tab
  4. Change the "Allow applications downloaded from:" setting to "Anywhere"

This appears to be a security issue with Mountain Lion, but the above steps provide a workaround until it is "fixed" by Google.

Member

tfmorris commented Oct 15, 2012

From bodna...@gmail.com on August 08, 2012 03:42:17:
I was able to fix this on my wife's laptop by taking the following steps:

  1. Open System Preferences
  2. Open Security & Privacy
  3. Go to the General Tab
  4. Change the "Allow applications downloaded from:" setting to "Anywhere"

This appears to be a security issue with Mountain Lion, but the above steps provide a workaround until it is "fixed" by Google.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From tfmorris on August 08, 2012 16:42:25:
issue #602 has been merged into this issue.

Member

tfmorris commented Oct 15, 2012

From tfmorris on August 08, 2012 16:42:25:
issue #602 has been merged into this issue.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From asid...@gmail.com on August 09, 2012 07:20:04:
I fixed this issue on Mountain Lion with changing "Allow applications downloaded from:" setting to "Anywhere" too.

Member

tfmorris commented Oct 15, 2012

From asid...@gmail.com on August 09, 2012 07:20:04:
I fixed this issue on Mountain Lion with changing "Allow applications downloaded from:" setting to "Anywhere" too.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From tfmorris on August 09, 2012 14:59:11:
@bodnarbm - Thanks for diagnosing the problem and reporting back on your fix. Much appreciated!

Apple broke the installer with introduction of the Mountain Lion upgrade and many Java applications were affected. If you search for the misleading error message, you can see the number of people this is affecting as Mountain Lion upgrades are done.

https://www.google.com/search?hl=en&q=%22is+damaged+and+can%27t+be+opened.+You+should+move+it+to+the+Trash.%22

There's a thread on Apple's java-dev list about this misleading error message (which is big part of the problem since it directs attention away from the real error) http://lists.apple.com/archives/java-dev/2012/Jul/msg00106.html

This Apple support document describes Gatekeeper and how to configure it so Refine works (the procedure described in Comment 3 http://support.apple.com/kb/HT5290

This Oracle article discusses Mountain Lion and Java problems in general https://blogs.oracle.com/talkingjavadeployment/entry/java_applications_and_gatekeeper

Lastly, a potential solution is described here http://lists.apple.com/archives/java-dev/2012/Jul/msg00136.html

I don't have a Mac to test it on, but it might change the misleading "damaged" error message to a more reasonable "your app is unsigned, do you want to run it."

All in all, I'm pretty pissed off at the amount of time and money Apple is costing both developers and users.

Member

tfmorris commented Oct 15, 2012

From tfmorris on August 09, 2012 14:59:11:
@bodnarbm - Thanks for diagnosing the problem and reporting back on your fix. Much appreciated!

Apple broke the installer with introduction of the Mountain Lion upgrade and many Java applications were affected. If you search for the misleading error message, you can see the number of people this is affecting as Mountain Lion upgrades are done.

https://www.google.com/search?hl=en&q=%22is+damaged+and+can%27t+be+opened.+You+should+move+it+to+the+Trash.%22

There's a thread on Apple's java-dev list about this misleading error message (which is big part of the problem since it directs attention away from the real error) http://lists.apple.com/archives/java-dev/2012/Jul/msg00106.html

This Apple support document describes Gatekeeper and how to configure it so Refine works (the procedure described in Comment 3 http://support.apple.com/kb/HT5290

This Oracle article discusses Mountain Lion and Java problems in general https://blogs.oracle.com/talkingjavadeployment/entry/java_applications_and_gatekeeper

Lastly, a potential solution is described here http://lists.apple.com/archives/java-dev/2012/Jul/msg00136.html

I don't have a Mac to test it on, but it might change the misleading "damaged" error message to a more reasonable "your app is unsigned, do you want to run it."

All in all, I'm pretty pissed off at the amount of time and money Apple is costing both developers and users.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From tfmorris on September 25, 2012 13:26:44:
issue #622 has been merged into this issue.

Member

tfmorris commented Oct 15, 2012

From tfmorris on September 25, 2012 13:26:44:
issue #622 has been merged into this issue.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From tfmorris on September 25, 2012 13:59:39:
@dfhuynh - Do you think you can test this fix for 2.6?

Member

tfmorris commented Oct 15, 2012

From tfmorris on September 25, 2012 13:59:39:
@dfhuynh - Do you think you can test this fix for 2.6?

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Oct 15, 2012

Member

From tfmorris on September 26, 2012 14:47:28:
issue #621 has been merged into this issue.

Member

tfmorris commented Oct 15, 2012

From tfmorris on September 26, 2012 14:47:28:
issue #621 has been merged into this issue.

@gaurav

This comment has been minimized.

Show comment
Hide comment
@gaurav

gaurav Mar 16, 2013

It sounds like the easiest fix might be for a core OpenRefine developer to create a self-signed certificate (Keychain Access -> Certificate Assistant -> Create a certificate) and sign the .app with it at release. This changes the error message to the standard unsigned-app error, which you can override by right-clicking and clicking "Open". Unfortunately, this would have to be done by someone who is directly involved in release, since it'd be a bad idea to put that certificate into the repository so that the signing could be incorporated into the build process.

gaurav commented Mar 16, 2013

It sounds like the easiest fix might be for a core OpenRefine developer to create a self-signed certificate (Keychain Access -> Certificate Assistant -> Create a certificate) and sign the .app with it at release. This changes the error message to the standard unsigned-app error, which you can override by right-clicking and clicking "Open". Unfortunately, this would have to be done by someone who is directly involved in release, since it'd be a bad idea to put that certificate into the repository so that the signing could be incorporated into the build process.

@emgee3

This comment has been minimized.

Show comment
Hide comment
@emgee3

emgee3 Jul 23, 2013

I can confirming that the workaround noted at http://lists.apple.com/archives/java-dev/2012/Jul/msg00136.html does indeed work. Download the referenced script and run on Applications/Google Refine.app/Contents/MacOS/JavaApplicationStub and the error changes to unsigned application.

emgee3 commented Jul 23, 2013

I can confirming that the workaround noted at http://lists.apple.com/archives/java-dev/2012/Jul/msg00136.html does indeed work. Download the referenced script and run on Applications/Google Refine.app/Contents/MacOS/JavaApplicationStub and the error changes to unsigned application.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Jul 24, 2013

Member

@emgee3 Thanks for testing. We'll go with some variant of this for 2.6.

Ruby unsigning script referenced above - http://snipt.org/kto/ (code copied below)
C unsigning program - http://www.woodmann.com/collaborative/tools/index.php/Unsign

#!/usr/bin/env ruby
#Deactivates any embedded code signatures in a Mach-O binary.

module MachO
  class Unsign
    def self.unsign(filename)
      File.open(filename, "r+") do |f|
        Unsign.new(f).headers
      end
    end

    attr_accessor :headers

    protected

    FatHeader = Struct.new(:cpu_type, :cpu_subtype, :offset, :size, :align, :mach)
    MachHeader = Struct.new(:cpu_type, :cpu_subtype, :filetype, :ncmds, :sizeofcmds, :flags, :reserved, :cmds)
    LoadCommand = Struct.new(:cmd, :cmdsize)

    def initialize(f)
      @f = f
      @headers = process
    end

    def debug(message)
      puts message if ENV["DEBUG"]
    end

    def word_type
      @big_endian ? 'N' : 'V'
    end

    def patch_code_signature(lc)
      # just change LC_CODE_SIGNATURE to a high value that will be ignored by the loader
      debug "PATCHING LC_CODE_SIGNATURE"
      @f.seek(-8, IO::SEEK_CUR)
      @f.write([0xff, lc.cmdsize].pack("#{word_type}2"))
      lc
    end

    def process_mach
      len = @x86_64 ? 7 : 6
      header = MachHeader.new(*@f.read(len*4).unpack("#{word_type}#{len}"))
      debug "MACH HEADER: #{header.inspect}"
      header.cmds = (1..(header.ncmds)).collect do
        lc = LoadCommand.new(*@f.read(8).unpack("#{word_type}2"))
        debug "LOAD COMMAND: #{lc.inspect}"

        lc = case lc.cmd
        when 0x1d then patch_code_signature(lc)
        else lc
        end

        @f.seek(lc.cmdsize - 8, IO::SEEK_CUR)

        lc
      end
      header
    end

    def process_fat
      num_arches, = @f.read(4).unpack("N")
      arches = (1..num_arches).collect do
        FatHeader.new(*@f.read(20).unpack("N5"))
      end
      debug "FAT HEADER: #{arches.inspect}"
      arches.each do |arch|
        @f.seek(arch.offset)
        arch.mach = process
      end
      arches
    end

    def process
      magic, = @f.read(4).unpack("N")
      debug "MAGIC: 0x%08x" % magic
      case magic
      when 0xcafebabe then @big_endian, @x86_64 = false, false; process_fat
      when 0xfeedface then @big_endian, @x86_64 = true,  false; process_mach
      when 0xcffaedfe then @big_endian, @x86_64 = false, true;  process_mach
      when 0xcefaedfe then @big_endian, @x86_64 = false, false; process_mach
      else raise "unknown magic: 0x%08x" % magic
      end
    end
  end
end

#command line driver
if __FILE__ == $0
  if ARGV.empty?
    $stderr.puts "usage:  #{$0} filename ..."
    exit 1
  end

  ARGV.each do |filename|
    puts "removing signatures from: #{filename}"
    MachO::Unsign::unsign(filename)
  end
end
Member

tfmorris commented Jul 24, 2013

@emgee3 Thanks for testing. We'll go with some variant of this for 2.6.

Ruby unsigning script referenced above - http://snipt.org/kto/ (code copied below)
C unsigning program - http://www.woodmann.com/collaborative/tools/index.php/Unsign

#!/usr/bin/env ruby
#Deactivates any embedded code signatures in a Mach-O binary.

module MachO
  class Unsign
    def self.unsign(filename)
      File.open(filename, "r+") do |f|
        Unsign.new(f).headers
      end
    end

    attr_accessor :headers

    protected

    FatHeader = Struct.new(:cpu_type, :cpu_subtype, :offset, :size, :align, :mach)
    MachHeader = Struct.new(:cpu_type, :cpu_subtype, :filetype, :ncmds, :sizeofcmds, :flags, :reserved, :cmds)
    LoadCommand = Struct.new(:cmd, :cmdsize)

    def initialize(f)
      @f = f
      @headers = process
    end

    def debug(message)
      puts message if ENV["DEBUG"]
    end

    def word_type
      @big_endian ? 'N' : 'V'
    end

    def patch_code_signature(lc)
      # just change LC_CODE_SIGNATURE to a high value that will be ignored by the loader
      debug "PATCHING LC_CODE_SIGNATURE"
      @f.seek(-8, IO::SEEK_CUR)
      @f.write([0xff, lc.cmdsize].pack("#{word_type}2"))
      lc
    end

    def process_mach
      len = @x86_64 ? 7 : 6
      header = MachHeader.new(*@f.read(len*4).unpack("#{word_type}#{len}"))
      debug "MACH HEADER: #{header.inspect}"
      header.cmds = (1..(header.ncmds)).collect do
        lc = LoadCommand.new(*@f.read(8).unpack("#{word_type}2"))
        debug "LOAD COMMAND: #{lc.inspect}"

        lc = case lc.cmd
        when 0x1d then patch_code_signature(lc)
        else lc
        end

        @f.seek(lc.cmdsize - 8, IO::SEEK_CUR)

        lc
      end
      header
    end

    def process_fat
      num_arches, = @f.read(4).unpack("N")
      arches = (1..num_arches).collect do
        FatHeader.new(*@f.read(20).unpack("N5"))
      end
      debug "FAT HEADER: #{arches.inspect}"
      arches.each do |arch|
        @f.seek(arch.offset)
        arch.mach = process
      end
      arches
    end

    def process
      magic, = @f.read(4).unpack("N")
      debug "MAGIC: 0x%08x" % magic
      case magic
      when 0xcafebabe then @big_endian, @x86_64 = false, false; process_fat
      when 0xfeedface then @big_endian, @x86_64 = true,  false; process_mach
      when 0xcffaedfe then @big_endian, @x86_64 = false, true;  process_mach
      when 0xcefaedfe then @big_endian, @x86_64 = false, false; process_mach
      else raise "unknown magic: 0x%08x" % magic
      end
    end
  end
end

#command line driver
if __FILE__ == $0
  if ARGV.empty?
    $stderr.puts "usage:  #{$0} filename ..."
    exit 1
  end

  ARGV.each do |filename|
    puts "removing signatures from: #{filename}"
    MachO::Unsign::unsign(filename)
  end
end

@ghost ghost assigned tfmorris Aug 7, 2013

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Aug 7, 2013

Member

Starting with 2.6-alpha1 kits are signed with a self-signed certificate. The OS X Gatekeeper will ask if you want to trust an application from an unknown developer, but it won't whine about things being "damaged."

Member

tfmorris commented Aug 7, 2013

Starting with 2.6-alpha1 kits are signed with a self-signed certificate. The OS X Gatekeeper will ask if you want to trust an application from an unknown developer, but it won't whine about things being "damaged."

@tfmorris tfmorris closed this Aug 7, 2013

@sparkica

This comment has been minimized.

Show comment
Hide comment
@sparkica

sparkica Aug 8, 2013

Contributor

In case there is no option to 'Open' the application on the warning dialog, control clicking it helps. I guess this depends on the computer's gatekeeper settings.

Contributor

sparkica commented Aug 8, 2013

In case there is no option to 'Open' the application on the warning dialog, control clicking it helps. I guess this depends on the computer's gatekeeper settings.

@kinjal

This comment has been minimized.

Show comment
Hide comment
@kinjal

kinjal Aug 24, 2013

I still encountered this error (2.5). The workaround worked. But one more step is to reset the security settings to what it was after you run the app once. Subsequent executions will be allowed and your system will still be protected.

kinjal commented Aug 24, 2013

I still encountered this error (2.5). The workaround worked. But one more step is to reset the security settings to what it was after you run the app once. Subsequent executions will be allowed and your system will still be protected.

@acdha

This comment has been minimized.

Show comment
Hide comment
@acdha

acdha Aug 28, 2013

If you don't want to deal with installing a third-party utility just to run 2.5, the following process works:

  1. Replace the existing signature with an ad-hoc self-signature: codesign -f -s - /Applications/Google\ Refine.app/Contents/MacOS/JavaApplicationStub
  2. Open /Applications, control-click on the Google Refine icon and choose Open
  3. Now the warning dialog will have an Open option in addition to Cancel

After the first time, simply opening the app normally works.

acdha commented Aug 28, 2013

If you don't want to deal with installing a third-party utility just to run 2.5, the following process works:

  1. Replace the existing signature with an ad-hoc self-signature: codesign -f -s - /Applications/Google\ Refine.app/Contents/MacOS/JavaApplicationStub
  2. Open /Applications, control-click on the Google Refine icon and choose Open
  3. Now the warning dialog will have an Open option in addition to Cancel

After the first time, simply opening the app normally works.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris
Member

tfmorris commented Aug 28, 2013

@herrernst

This comment has been minimized.

Show comment
Hide comment
@herrernst

herrernst Sep 17, 2013

Removing the com.apple.quarantine extended attribute should be enough:
xattr -rd com.apple.quarantine Google\ Refine.app/
Works for me having gatekeeper set to "Mac App Store and identified developers".

herrernst commented Sep 17, 2013

Removing the com.apple.quarantine extended attribute should be enough:
xattr -rd com.apple.quarantine Google\ Refine.app/
Works for me having gatekeeper set to "Mac App Store and identified developers".

@berkeleymalagon

This comment has been minimized.

Show comment
Hide comment
@berkeleymalagon

berkeleymalagon Oct 1, 2013

Confirming that herrernst's xattr call does the trick for me on OSX 10.8.5.

berkeleymalagon commented Oct 1, 2013

Confirming that herrernst's xattr call does the trick for me on OSX 10.8.5.

@felixrabe

This comment has been minimized.

Show comment
Hide comment
@felixrabe

felixrabe May 13, 2014

@tfmorris - OpenRefine 2.6-beta.1 on OS X 10.9.2 still gives me the dialog:

“OpenRefine.app” is damaged and can’t be opened. You should move it to the Trash.

@herrernst's tip WORKS, and I just also launch OpenRefine in that command:

xattr -rd com.apple.quarantine /Applications/OpenRefine.app && open /Applications/OpenRefine.app

@acdha's tip for 2.6 does NOT WORK (it worked for Google Refine 2.5 though):

Felixs-MacBook-Air:~ fr$ codesign -f -s - /Applications/OpenRefine.app/Contents/MacOS/JavaAppLauncher
/Applications/OpenRefine.app/Contents/MacOS/JavaAppLauncher: replacing existing signature
/Applications/OpenRefine.app/Contents/MacOS/JavaAppLauncher: code object is not signed at all
In subcomponent: /Applications/OpenRefine.app/Contents/PlugIns/jdk1.7.0_25.jdk

felixrabe commented May 13, 2014

@tfmorris - OpenRefine 2.6-beta.1 on OS X 10.9.2 still gives me the dialog:

“OpenRefine.app” is damaged and can’t be opened. You should move it to the Trash.

@herrernst's tip WORKS, and I just also launch OpenRefine in that command:

xattr -rd com.apple.quarantine /Applications/OpenRefine.app && open /Applications/OpenRefine.app

@acdha's tip for 2.6 does NOT WORK (it worked for Google Refine 2.5 though):

Felixs-MacBook-Air:~ fr$ codesign -f -s - /Applications/OpenRefine.app/Contents/MacOS/JavaAppLauncher
/Applications/OpenRefine.app/Contents/MacOS/JavaAppLauncher: replacing existing signature
/Applications/OpenRefine.app/Contents/MacOS/JavaAppLauncher: code object is not signed at all
In subcomponent: /Applications/OpenRefine.app/Contents/PlugIns/jdk1.7.0_25.jdk

@tfmorris tfmorris reopened this May 26, 2014

@k5rola

This comment has been minimized.

Show comment
Hide comment
@k5rola

k5rola Nov 25, 2014

I've had the same issue installing Google Refine 2.5 on OS X Yosemite, Version 10.10.1
@acdha's tip fixed it.

k5rola commented Nov 25, 2014

I've had the same issue installing Google Refine 2.5 on OS X Yosemite, Version 10.10.1
@acdha's tip fixed it.

@thayneclark

This comment has been minimized.

Show comment
Hide comment
@thayneclark

thayneclark Dec 23, 2014

@acdha's tip worked for me with OpenRefine 2.5 on OS X 10.9.5.

thayneclark commented Dec 23, 2014

@acdha's tip worked for me with OpenRefine 2.5 on OS X 10.9.5.

@akanik

This comment has been minimized.

Show comment
Hide comment
@akanik

akanik Feb 9, 2015

@herrernst xattr worked like a charm. Thanks!

akanik commented Feb 9, 2015

@herrernst xattr worked like a charm. Thanks!

@BurgosNY

This comment has been minimized.

Show comment
Hide comment
@BurgosNY

BurgosNY Feb 17, 2015

@acdha tip also worked for me. I'm on Yosemite (10.10.2). Thanks!

BurgosNY commented Feb 17, 2015

@acdha tip also worked for me. I'm on Yosemite (10.10.2). Thanks!

@sbecainfo

This comment has been minimized.

Show comment
Hide comment
@sbecainfo

sbecainfo Mar 5, 2015

thanks @acdha, also worked for me on Yosemite!

sbecainfo commented Mar 5, 2015

thanks @acdha, also worked for me on Yosemite!

@tongzz

This comment has been minimized.

Show comment
Hide comment
@tongzz

tongzz Mar 21, 2015

thanks @acdha, your method works.

For people who are non-techies like me, open your Terminal on your Mac and type in the command codesign -f -s - /Applications/Google\ Refine.app/Contents/MacOS/JavaApplicationStub

Quoting @acdha

Replace the existing signature with an ad-hoc self-signature: codesign -f -s - /Applications/Google\ >Refine.app/Contents/MacOS/JavaApplicationStub
Open /Applications, control-click on the Google Refine icon and choose Open
Now the warning dialog will have an Open option in addition to Cancel
After the first time, simply opening the app normally works.

tongzz commented Mar 21, 2015

thanks @acdha, your method works.

For people who are non-techies like me, open your Terminal on your Mac and type in the command codesign -f -s - /Applications/Google\ Refine.app/Contents/MacOS/JavaApplicationStub

Quoting @acdha

Replace the existing signature with an ad-hoc self-signature: codesign -f -s - /Applications/Google\ >Refine.app/Contents/MacOS/JavaApplicationStub
Open /Applications, control-click on the Google Refine icon and choose Open
Now the warning dialog will have an Open option in addition to Cancel
After the first time, simply opening the app normally works.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Apr 30, 2015

Member

@felixrabe I just double checked the v2.6-beta1 kit on a fresh Mac and didn't have any issue with it. I got a message saying that my security preferences only allow apps from identified developers, but after going to Security Preferences, I was given the option to open it anyway. Nothing about the app being "damaged" as it used to do with 2.5.

Has anyone else had problems with that kit? We're about to generate the final v2.6 kits and I want to make sure that this problem is actually solved.

Member

tfmorris commented Apr 30, 2015

@felixrabe I just double checked the v2.6-beta1 kit on a fresh Mac and didn't have any issue with it. I got a message saying that my security preferences only allow apps from identified developers, but after going to Security Preferences, I was given the option to open it anyway. Nothing about the app being "damaged" as it used to do with 2.5.

Has anyone else had problems with that kit? We're about to generate the final v2.6 kits and I want to make sure that this problem is actually solved.

@herrernst

This comment has been minimized.

Show comment
Hide comment
@herrernst

herrernst Apr 30, 2015

Hi, I've tried both beta1 and rc1, and both did work on Yosemite without given the 'damaged' warning.

herrernst commented Apr 30, 2015

Hi, I've tried both beta1 and rc1, and both did work on Yosemite without given the 'damaged' warning.

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris Apr 30, 2015

Member

@herrernst Thanks very much for the feedback. I wanted to make sure I wasn't imagining things. :-)

If anyone sees this problem with a recent kit (perhaps on a OS X version), please feel free to re-open, but I'm closing for now.

Member

tfmorris commented Apr 30, 2015

@herrernst Thanks very much for the feedback. I wanted to make sure I wasn't imagining things. :-)

If anyone sees this problem with a recent kit (perhaps on a OS X version), please feel free to re-open, but I'm closing for now.

@tfmorris tfmorris closed this Apr 30, 2015

@tfmorris

This comment has been minimized.

Show comment
Hide comment
@tfmorris

tfmorris May 20, 2015

Member

@janemnichols Your comment is a little confusing because you mention OpenRefine, but screen shot shows Google Refine, implying that you were running the older Google Refine 2.5 kit. The problem definitely still exists in 2.5. It's only OpenRefine 2.6 which will have the fix.

Member

tfmorris commented May 20, 2015

@janemnichols Your comment is a little confusing because you mention OpenRefine, but screen shot shows Google Refine, implying that you were running the older Google Refine 2.5 kit. The problem definitely still exists in 2.5. It's only OpenRefine 2.6 which will have the fix.

@tomhundt

This comment has been minimized.

Show comment
Hide comment
@tomhundt

tomhundt Jun 15, 2015

Confirmed @tfmorris 's solution worked for me -- Refine v2.5 (r2407) on vOSX 10.10.3 -- i.e., whereas it had previously complained, upon trying to run it, the app was "damaged" and I ought to trash it, now it opens it. Preferences > Security & Privacy > (click the lock and type password to unlock it, then) Allow apps downloaded from Anywhere. Now it ran when I launched it as usual. It popped up some kind of firewall warning, asking for permission to accept connections (I gave it). Up came a browser window showing the app. That's as far as I've gotten :-)

It says here the OpenRefine versions (which seem to be beta) won't have this "Damaged" issue, but since I'm new to this program I went for the stable release off http://openrefine.org/download.html which got me the same v2.5 Google Refine .dmg file as I got from Google themselves.

tomhundt commented Jun 15, 2015

Confirmed @tfmorris 's solution worked for me -- Refine v2.5 (r2407) on vOSX 10.10.3 -- i.e., whereas it had previously complained, upon trying to run it, the app was "damaged" and I ought to trash it, now it opens it. Preferences > Security & Privacy > (click the lock and type password to unlock it, then) Allow apps downloaded from Anywhere. Now it ran when I launched it as usual. It popped up some kind of firewall warning, asking for permission to accept connections (I gave it). Up came a browser window showing the app. That's as far as I've gotten :-)

It says here the OpenRefine versions (which seem to be beta) won't have this "Damaged" issue, but since I'm new to this program I went for the stable release off http://openrefine.org/download.html which got me the same v2.5 Google Refine .dmg file as I got from Google themselves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment