Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 468103

Summary:	[MacOS] Eclipse Installer.app should be signed
Product:	[Tools] Oomph	Reporter:	Mikaël Barbero <mikael.barbero>
Component:	Release Engineering	Assignee:	Eike Stepper <stepper>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	1.1.0
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X
Whiteboard:

Description Mikaël Barbero

2015-05-23 05:43:37 EDT

Eclipse Installer (Mars RC1) can't be started with standard security settings on OS X. 

$ spctl -a -t exec -vvvv Eclipse\ Installer.app/
Eclipse Installer.app/: rejected
source=no usable signature

In the pom of your product, you would put this in the <build> section:

<plugin>
  <groupId>org.eclipse.cbi.maven.plugins</groupId>
  <artifactId>eclipse-macsigner-plugin</artifactId>
  <version>1.1.2</version>
  <executions>
    <execution>
      <id>sign</id>
      <phase>package</phase>
      <goals>
        <goal>sign</goal>
      </goals>
      <configuration>
        <signFiles>
          <signFile>${project.build.directory}/products/org.eclipse.oomph.setup.installer.product/macosx/cocoa/x86_64/Eclipse Installer.app</signFile>
        </signFiles>
      </configuration>
    </execution>
  </executions>
</plugin>

Comment 1 Eike Stepper

2015-05-26 05:02:40 EDT

Hi Mikael,

We used to sign the Mac app with the following shell script:

      echo "  Signing oomph.app"
      zip -r -q unsigned.zip oomph.app
      rm -rf oomph.app
      curl -o signed.zip -F filedata=@unsigned.zip http://build.eclipse.org:31338/macsign.php
      unzip -qq signed.zip
      rm -f signed.zip

Until the whole Mac app layout redesign started. Now I added the script back and the build fails:

	Repackaging org.eclipse.oomph.setup.installer.product-macosx.cocoa.x86_64.zip
  	Signing oomph.app
	zip error: Nothing to do! (try: zip -r -q unsigned.zip . -i oomph.app)
	
Is this macsign.php supposed to work as before? Do you see an obvious mistake in our usage?

Comment 2 Eike Stepper

2015-05-26 05:07:09 EDT

Oh, wait. I might have to adjust the app name...

Comment 3 Eike Stepper

2015-05-26 05:21:14 EDT

Now it fails like this:

Repackaging org.eclipse.oomph.setup.installer.product-macosx.cocoa.x86_64.zip
  Signing Eclipse Installer.app
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0 43.3M    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  2 43.3M    0     0    2  912k      0  17.0M  0:00:02 --:--:--  0:00:02 18.5M
 19 43.3M    0     0   19 8464k      0  7308k  0:00:06  0:00:01  0:00:05 7334k
 35 43.3M    0     0   35 15.4M      0  7685k  0:00:05  0:00:02  0:00:03 7703k
 59 43.3M    0     0   59 25.6M      0  8572k  0:00:05  0:00:03  0:00:02 8584k
 83 43.3M    0     0   83 35.9M      0  8899k  0:00:04  0:00:04 --:--:-- 8909k
100 43.3M    0    21  100 43.3M      4  9265k  0:00:04  0:00:04 --:--:-- 9177k
[signed.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of signed.zip or
        signed.zip.zip, and cannot find signed.zip.ZIP, period.

Comment 4 Mikaël Barbero

2015-05-26 05:29:14 EDT

The proper command is curl -o signed.zip -F file=@unsigned.zip http://build.eclipse.org:31338/macsign.php (the server now check for a part named file explicitly). Open the erroneous zip file you will see a message about that ;)

Comment 5 Eike Stepper

2015-05-26 05:50:58 EDT

Ok, that worked better.

For Windows we still use "-F filedata=..." in two places and that never complained. Should we change that to "-F file=...", too?

Comment 6 Eike Stepper

2015-05-26 06:46:32 EDT

Fixed in master:

ac328549bc06d8ab9722e3d9680702cd25b0d626
63a47e61f872e1ca07fb0c090304d412e558fff1
d6719a0af4b92b0312c2a6ff84345f7788219d80
a415f16a78f2f25c77f4a8734b3a6e04e269cf55
adeff2b546f002cbb4ffa1c91d15fd3e521ed3cb
bfa916ddddc78295a7ee87942ff7d4a333266a3c

Comment 7 Mikaël Barbero

2015-05-26 08:02:58 EDT

(In reply to Eike Stepper from comment #5)
> Ok, that worked better.
> 
> For Windows we still use "-F filedata=..." in two places and that never
> complained. Should we change that to "-F file=...", too?

Windows still uses the old signing infrastructure which doesn't care about the part name (it just takes the first one, so it could be anything). The windows signing infrastructure will be updated shortly after Mars so you will have to change it to "file" at that time. You can do it preemptively now if you want as it will also works with the current version ;)