Can you explain why this critical/blocking hardware is hosted outside the 
Eclipse Foundation, creating more/new issues and delays? Our automated 
builds don't play well with filing bugs (for signing and DMG creation) and 
wait for resolution ;-). Ah, and BTW, our latest Photon M2 candidate build 
just failed again:


From:   Mikaël Barbero <>
To:     "Eclipse platform release engineering list." 
<>, Eclipse Packaging Project 
Cc:     Webmaster <>, Cross project issues 
Date:   07.09.2017 14:07
Subject:        [platform-releng-dev] Issue with the macOS bundle signing, 
dmg packaging and signing
Sent by:

(cross-posting to platform-releng, epp-dev and cross-projects)


Recently, we've been facing a lot of issues with the services we provide 
for macOS: UI testing, macOS .app bundles signing and DMG files creation 
and signing. It has been a combination of hardware, software and network 
failures and these issues have already impacted some projects, delaying 
their milestones/releases and consuming a lot of time from their teams. 

Since the beginning of the week, we've setup a new machine to run UI tests 
from the Hudson shared instance ( This 
machine is not hosted on our infra, and thus not everything that was 
possible can be done on the new machine (most notably, it's not possible 
to access machines inside the Eclipse VLAN). We still need to figure out 
if we want to make it possible, or if we want to set this fact as a 

We've also successfully deployed and tested the signing and dmg packaging 
services on a similar machine. Unfortunately, we can't switch the current 
unreliable services to these new ones as they are also hosted outside of 
the Eclipse VLAN. As you may know, the services are insecure webapps (read 
plain HTTP) without any sort of authentication. We were using the fact 
that the services were running inside the VLAN to "protect" them. Only 
Eclipse projects and committers were both trusted to use the service by 
having access to the VLAN via their Hudson/Jenkins instance. 

Opening the new services on a machine directly connected to the internet 
would let anyone sign a macOS application with the Eclipse certificate. 
This is something we want to avoid at all cost as it would ruin all the 
trust one can have in this certificate. So we are working hard to add a 
authentication layer and run the service on top of HTTPS to be able to 
provide these services reliably from the new machines. But it takes some 

As we don't want these issues to delay the release of Oxygen.1 or any 
project that uses these services, we come here with an temporary plan:

If you need to sign a macOS app and/or create a signed DMG for it, just 
open a bug against CBI / signing service and we will do it for you. You 
will need to give us the path on to the .tar.gz of 
the macOS application you want us to sign / package on You will probably have to deactivate the usage of 
the CBI maven plugins (eclipse-macsigner-plugin and eclipse-dmg-packager) 
if you use Tycho. The output of the product build should then be a simple 
tar.gz of your .app Eclipse product.

If you have any question, feel free to open a bug against CBI or just ask 
it here.

Thanks for your patience.


Mikaël Barbero - Eclipse Foundation
IT Services - Release Engineering
? (+33) 642 028 039
? @mikbarbero
[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] 
platform-releng-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit

Reply via email to